AI-Assisted Development Toolkit

A comprehensive template repository providing AI instruction files, prompts, and rules for AI-assisted development workflows. This toolkit helps teams establish consistent AI coding practices across projects.

Purpose

This repository serves as a template source for AI development instructions that can be copied into your projects. It provides:

• Cursor IDE rules (.cursor/rules/) for AI behavior configuration
• Cursor commands (.cursor/commands/) for custom AI workflows
• GitHub Copilot instructions (.github/copilot-instructions.md)
• GitHub prompts (.github/prompts/) for reusable prompt templates
• AGENTS.md files for AI agent context
• Native Codex setup using AGENTS.md, .agents/skills/, and an optional comment-only .codex/config.toml
• Skills recommendations from skills.sh for enhanced AI capabilities

Repository Structure

/
├── src/
│   ├── repo/           # Templates for single repositories
│   │   ├── .codex/     # Optional native Codex config (comment-only)
│   │   ├── .cursor/    # Cursor IDE configuration
│   │   │   ├── agents/ # Custom agent templates (subagents)
│   │   │   ├── rules/  # IDE behavior rules
│   │   │   ├── commands/ # Custom AI commands
│   │   │   ├── skills/ # Additional skills (README placeholder)
│   │   │   └── mcp.json # MCP server configuration template
│   │   ├── .github/    # GitHub Copilot instructions
│   │   │   ├── agents/ # Custom agent templates (subagents)
│   │   │   ├── instructions/ # Context instructions
│   │   │   ├── prompts/ # Reusable prompts
│   │   │   └── skills/ # Additional skills (README placeholder)
│   │   ├── .agents/    # Pre-installed universal skills
│   │   │   ├── rules/  # Agent behavior rules (ponytail, etc.)
│   │   │   └── skills/ # Bundled skills (TDD, debugging, etc.)
│   │   ├── docs/       # Documentation structure templates
│   │   ├── factory/    # Opt-in factory pipeline (README, .gitignore)
│   │   ├── templates/  # Reusable document templates
│   │   ├── AGENTS.md   # AI agent context template
│   │   └── README.md   # Project README template
│   │
│   └── monorepo/       # Templates for monorepos
│       ├── .codex/     # Optional native Codex config (comment-only)
│       ├── .cursor/    # Root-level Cursor config
│       │   ├── agents/ # Custom agent templates (subagents)
│       │   ├── rules/  # IDE behavior rules
│       │   ├── commands/ # Custom AI commands
│       │   ├── skills/ # Additional skills (README placeholder)
│       │   └── mcp.json # MCP server configuration template
│       ├── .github/    # Root-level GitHub config
│       │   ├── agents/ # Custom agent templates (subagents)
│       │   ├── instructions/ # Context instructions
│       │   ├── prompts/ # Reusable prompts
│       │   └── skills/ # Additional skills (README placeholder)
│       ├── .agents/    # Pre-installed universal skills
│       │   ├── rules/  # Agent behavior rules (ponytail, etc.)
│       │   └── skills/ # Bundled skills (TDD, debugging, etc.)
│       ├── apps/       # App-specific templates
│       ├── packages/   # Package-specific templates
│       ├── docs/       # Documentation structure templates
│       ├── factory/    # Opt-in factory pipeline (README, .gitignore)
│       ├── templates/  # Reusable document templates
│       └── AGENTS.md   # Monorepo agent context
│
├── .cursor/            # This toolkit's own Cursor config
├── .github/            # This toolkit's own GitHub config
├── .opencode/          # This toolkit's own OpenCode config
│   └── plugins/        # Other local OpenCode plugins (Ponytail is installed globally)
├── hooks/              # Claude Code / Copilot activation hooks (ponytail, etc.)
└── AGENTS.md           # This toolkit's agent context

Usage

For Single Repositories

Step 1: Copy the templates

cp -r src/repo/.cursor /path/to/your/project/
cp -r src/repo/.github /path/to/your/project/
cp -r src/repo/.agents /path/to/your/project/
cp -r src/repo/.claude /path/to/your/project/ # Shared snippet sources
cp -r src/repo/.codex /path/to/your/project/  # Optional Codex config
cp src/repo/AGENTS.md /path/to/your/project/

The .agents/skills/ folder contains pre-installed universal skills that are ready to use immediately (see Bundled Universal Skills).

Step 2: Run the Bootstrap Command

Open your project in Cursor IDE or VS Code with GitHub Copilot, then run:

• Cursor IDE: Use the /bootstrap command
• GitHub Copilot: Use the bootstrap.prompt.md prompt (/bootstrap)
• Codex: Ask it to read and follow .claude/prompt-snippets/bootstrap.md as a task document (manual copies have no .nitm/BOOTSTRAP.md). Do not use /bootstrap as a native Codex command.

The bootstrap process will:

1. Analyze your project's structure, dependencies, and configuration files
2. Infer template variables (framework, language, package manager, etc.)
3. Prompt you for any values it couldn't detect
4. Automatically update all {{PLACEHOLDER}} values in your AI instruction files

Step 3: Review and Customize

After bootstrapping, review the generated files and add any project-specific patterns to AGENTS.md.

For Monorepos

Step 1: Copy the templates

cp -r src/monorepo/.cursor /path/to/your/project/
cp -r src/monorepo/.github /path/to/your/project/
cp -r src/monorepo/.agents /path/to/your/project/
cp -r src/monorepo/.claude /path/to/your/project/ # Shared snippet sources
cp -r src/monorepo/.codex /path/to/your/project/  # Optional Codex config
cp src/monorepo/AGENTS.md /path/to/your/project/
# Optionally copy app/package templates
cp -r src/monorepo/apps/app-template /path/to/your/project/apps/
cp -r src/monorepo/packages/package-template /path/to/your/project/packages/

The .agents/skills/ folder contains pre-installed universal skills that are ready to use immediately (see Bundled Universal Skills).

Step 2: Run the Bootstrap Command

Open your project in Cursor IDE or VS Code with GitHub Copilot, then run:

• Cursor IDE: Use the /bootstrap command
• GitHub Copilot: Use the bootstrap.prompt.md prompt (/bootstrap)
• Codex: Ask it to read and follow .claude/prompt-snippets/bootstrap.md as a task document (manual copies have no .nitm/BOOTSTRAP.md). Do not use /bootstrap as a native Codex command.

The bootstrap process will:

1. Analyze your monorepo workspace, including all apps and packages
2. Detect frameworks, ports, and deployment platforms for each app
3. Infer package scopes and descriptions
4. Prompt you for any missing information
5. Create AGENTS.md files for each app with framework-specific patterns
6. Update all {{PLACEHOLDER}} values throughout the monorepo

Step 3: Review and Customize

After bootstrapping:

• Review root AGENTS.md for overall project context
• Check each apps/*/AGENTS.md for app-specific patterns
• Add any custom conventions or patterns unique to your project

CLI (npx)

Scaffold AI agent config into any repo, then hand off to your AI agent to finish setup (replace {{PLACEHOLDER}}s, calibrate native instructions). The CLI scaffolds config for all supported harnesses (Claude Code, GitHub Copilot, Cursor, OpenCode, Codex) by default, so you normally don't need --env. Scaffolding does not prove a harness is installed or active: bootstrap uses actual runtime information or asks which harnesses you use. install aborts if files already exist — use --force to overwrite, or patch to add only missing files.

# Scaffold AI config into the current repo (auto-detects repo vs monorepo)
# Aborts if files already exist — use --force to overwrite, or `patch` to add missing
npx nitm-ai-dev-toolkit install

# Force a template type
npx nitm-ai-dev-toolkit install --monorepo
npx nitm-ai-dev-toolkit install --repo

# Optional: scaffold only one harness (e.g. you only use Cursor)
npx nitm-ai-dev-toolkit install --env cursor
npx nitm-ai-dev-toolkit install --env codex

# Print the relevance plan, then add files that apply and update unchanged ones (edited files are kept)
npx nitm-ai-dev-toolkit patch

# Inspect the install (read-only): missing files, retired paths, files that do not apply, placeholders
npx nitm-ai-dev-toolkit doctor

# Upgrade to the latest published version: applies the same plan as patch, keeps your edits
npx nitm-ai-dev-toolkit upgrade

# Also runs `install --force`, which overwrites locally changed files with the latest templates (back up customisations first).
# `patch` never overwrites a locally changed file, with or without --force.
npx nitm-ai-dev-toolkit upgrade --force

# Preview install/patch/upgrade without writing (exits 1 on conflicts)
npx nitm-ai-dev-toolkit patch --dry-run

# Limit to some harnesses or features (saved to .nitm/toolkit.json; --exclude "" clears it)
npx nitm-ai-dev-toolkit patch --exclude copilot,cursor
npx nitm-ai-dev-toolkit patch --only claude,gh-cli

# Pin an exact version (resolved and printed before anything runs)
npx nitm-ai-dev-toolkit upgrade 5.0.1
npx nitm-ai-dev-toolkit upgrade [email protected]
npx nitm-ai-dev-toolkit upgrade --version 5.0.1 --dry-run

# Scaffold the oh-my-opencode-slim starter (delegates to `npx nitm-opencode-starter install`)
npx nitm-ai-dev-toolkit omo-slim-starter install

• --dry-run (install, patch, upgrade) lists adds, overwrites, skips, conflicts and the state files it would write, and writes nothing. Install and patch exit 1 if there are conflicts. upgrade --dry-run runs the pinned version's own dry run, so the target must be 5.0.1 or later.
• --exclude / --only take comma-separated groups. Harnesses: claude, codex, copilot, cursor, opencode. Features: factory, prisma, bkt-cli, gh-cli, glab-cli, acli, linear-cli. Shared files (AGENTS.md, docs/, hooks/, shared skills and snippets) are never excluded. The selection is saved to .nitm/toolkit.json and used by later install, patch and doctor runs; --exclude "" clears it.
• upgrade <version>, upgrade nitm-ai-dev-toolkit@<version> and --version <version> pin an exact version. latest, dist-tags and version ranges are refused. Without a version, the latest published release is used. While .nitm/retired.json has entries or a trackers override, upgrade refuses targets older than 5.2.0.
• State files: install, patch and upgrade write .toolkit-version (the installed package version) and .nitm/manifest.json (hashes of the files the toolkit wrote). doctor reports a .toolkit-version that differs from the package version, and lists stale toolkit files it recognises. It only reports them; it never deletes anything.
• .nitm/BOOTSTRAP.md is rewritten only when its content differs. The previous copy is first saved to .nitm/backups/.

After install, ask your AI agent to read and follow .nitm/BOOTSTRAP.md. Harnesses that supply a toolkit /bootstrap wrapper can also use it; Codex has no native toolkit /bootstrap command. Use doctor to verify the result.

Relevance, retirement and thin wrappers

patch and upgrade do not copy the whole template. They classify each template file against the project, print the plan with a reason for every entry, then write only what applies:

| Class | Meaning | Written? | | -------------- | ---------------------------------------------------------------------------------------------------- | ----------------------- | | add | Missing, and it applies to this project | yes | | update | You never changed it since the toolkit wrote it, and the template changed | yes | | current | Identical to the template | no change | | needs review | Locally changed, or missing while its relevance is undecided | no; never overwritten | | not relevant | Does not apply: another tracker, no Playwright or Prisma setup, an empty MCP template | no | | retired | Listed in .nitm/retired.json | no |

Relevance comes from the project. The git origin host (github.com, gitlab.com, bitbucket.org) names the tracker, and tracker CLI skills follow it (gh-cli, glab-cli, bkt-cli, acli, linear-cli). A trackers list in .nitm/retired.json overrides detection (use [] for none, for example Linear issues on a GitHub repository). Playwright, Prisma and UI files follow the dependencies in package.json at the root and in apps/* and packages/*. When the tracker cannot be detected, tracker skills are held for review and not guessed.

Retire what a project does not use by recording it in .nitm/retired.json. Write the file by hand, after agreeing the reason:

{
  "trackers": ["github"],
  "retired": [
    { "path": ".agents/skills/linear-cli", "reason": "GitHub Issues is the tracker", "date": "2026-10-27" }
  ]
}

A directory path retires every file under it. install and patch never re-add a retired path. upgrade does not either, but only when the target ships this support (5.2.0 or later): while the file has entries or a trackers override, upgrade refuses older targets. doctor lists a retired path as retired rather than missing. Matching is exact and case-sensitive (AGENTS.md is not agents.md). ./, doubled and inner / are normalised, and paths must stay inside the project (.. and absolute paths are refused). The CLI never writes this file. A malformed file stops the command before anything is written.

Harness wrappers (.claude/, .cursor/, .github/, .opencode/) are thin: frontmatter, a title, a link to the snippet in .claude/*-snippets/, at most five key points, and optionally one short summary line. Agent-dispatch tables are activation metadata. Policy lives only in the snippets. doctor and patch list wrappers that inline policy or diverge from their snippet, and propose moving the content into the snippet. They never change those wrappers.

Limits: classification uses file paths and project files only. It does not check whether a skill restates a snippet's policy, and it does not judge the wording inside a wrapper. A pinned upgrade <version> runs that version's patch, so these rules apply once that version is published.

Native OpenCode V2 (toolkit 4.0.0)

Toolkit 4.0.0 and later require OpenCode V2 (major >=2) for OpenCode use; oh-my-opencode-slim >=3.0.0 requires OpenCode >=2.0.7. All repo/monorepo bootstrap, patch, and upgrade flows run opencode --version before changes, accepting an optional leading v. V1 must stop before OpenCode customization/migration or marking toolkit 4.0.0: upgrade OpenCode or remain on toolkit 3.x. A missing CLI or unparseable version stops OpenCode steps and version marking until the user confirms/installs a supported version. Confirm harness use from runtime evidence or ask; scaffold directories are not proof. Other-harness-only setup is unaffected.

The external nitm-opencode-starter is a separate package, not automatically upgraded.

With user approval, merge this reproducible registration without replacing user/global plugins:

{ "plugins": ["[email protected]"] }

The toolkit root deliberately omits plugins to inherit user/global registrations. Both target templates register opencode-mem and @tarquinen/opencode-dcp@latest in their local plugins arrays; opentmux remains commented as V1-only. The OpenCode Ponytail plugin (@dietrichgebert/ponytail) is installed globally by the operator; neither the toolkit root nor the templates register it. The local ponytail.mjs files are removed from the toolkit root and both templates; no local API port or bridge replaces them.

For existing targets, back up and obtain approval before removing only known obsolete toolkit .opencode/plugins/ponytail.js, .mjs, or .ts copies. Preserve unrelated local plugins. Never add the Ponytail plugin to project config; if it is not installed globally, tell the operator to install it globally, without editing or overwriting global plugins. Native local plugins are discovered automatically. Slim's separate strict schema keeps its own prompt, permission, and variant: do not host-migrate plugin-owned fields. The root's no-plugins policy is specific to this toolkit repository, not target templates.

| Setting | Native V2 form | | --- | --- | | Agents | agents, JSON system (Markdown body for file agents), model provider/model#variant | | Permissions | Ordered permissions with action, resource, effect; shell/subagent actions; last match wins | | Commands | commands; delegated commands use subagent | | Plugins | plugins; options use { "package": "…", "options": {} } | | Skills | Directory-path array, e.g. [".agents/skills"], not Markdown globs | | MCP | mcp.servers; disabled inverts legacy enabled; timeout.catalog/timeout.execution |

Follow official V2 migration, config, agents, and plugins docs. The published https://opencode.ai/config.json schema may describe V1; it is not native V2 validation authority.

Runtime limits: Ambient AGENTS.md works. Config instructions entries load only when the runtime injects them (OpenChamber does; other hosts may not), so do not rely on them: write explicit "Read and follow" wrappers regardless. @refs are ordinary text, not automatic attachments: agents must read referenced snippets explicitly. Do not set a temperature; the current runner does not send one. Plugin/runtime integration has not been tested. Preserve lsp: true, but V2 currently exposes no LSP tools or diagnostics: use project lint/typecheck/compiler commands.

--env opencode includes minimal shared references for wrappers and AGENTS-linked standards without activating other harnesses. Merge, don't clobber: back up V1, preserve models/providers and user/global plugins, and ask before changes. Native-converted files are incompatible with V1. Activate on the next run/restart, then check behavior with the installed V2 runtime. doctor checks scaffold files/placeholders, not runtime behavior; do not substitute a V1 API/schema fetch or claim checks that were not run.

Native Codex

• --env codex includes .codex/, .agents/, and shared context, plus .github/instructions/ solely to supply the standards linked from AGENTS.md. The shared .claude/rules-snippets/ standards are installed in every scope, so those standards' wrapper source content is present too. It does not install other harness command, agent, or config directories. These reference files neither establish Copilot/Claude use nor load automatically as Codex rules; other harness scopes are unchanged.
• Codex reads AGENTS.md and discovers .agents/skills/*/SKILL.md natively. Monorepos can use more-specific nested AGENTS.md files for app/package guidance. Linked standards are references to read as needed, not automatically loaded Claude/Copilot rules.
• The optional .codex/config.toml is deliberately comment-only: it preserves the user's inherited defaults. Codex loads project config only after the user explicitly trusts the project; the toolkit does not grant trust or set model/provider, approval, sandbox, security, or feature overrides.
• For manual copies without .nitm/, provide .claude/prompt-snippets/bootstrap.md to Codex directly. For incremental AI-guided merges, provide .claude/prompt-snippets/bootstrap-patch.md as a task document; the CLI patch command only adds missing files.
• Codex MCP configuration uses native [mcp_servers.name] TOML in Codex config, not .mcp.json. No MCP servers are activated by the Codex template. Configure only user-approved servers using the native docs; do not copy credentials or activate other harness hooks automatically.
• Existing .claude/agents/, .github/agents/, and .opencode/agents/ formats are tool-specific, not Codex custom agents. This toolkit does not translate their frontmatter or permissions into Codex configuration. Use only delegation capabilities actually available in your running harness.

Official Codex docs: basic configuration · configuration reference · AGENTS.md · skills · MCP.

Placeholder Reference

Templates use {{PLACEHOLDER}} syntax for values you need to customize. The bootstrap command will automatically detect and fill most of these values.

Common Placeholders

| Placeholder | Description | Example | | ------------------------- | ------------------------- | --------------------------------------------------------------------- | | {{PROJECT_NAME}} | Your project name | my-awesome-app | | {{PROJECT_DESCRIPTION}} | Brief project description | A web app for... | | {{LANGUAGE}} | Primary language | TypeScript, PHP, C#, Python, Ruby, Go, Rust, Java | | {{FRAMEWORK}} | Primary framework | Next.js, Laravel, Blazor, Django, Rails, Spring Boot | | {{PACKAGE_MANAGER}} | Package manager | npm, composer, dotnet, pip, bundler, go, cargo, maven | | {{FILE_EXTENSION}} | File extension | ts, php, cs, py, rb, go, rs, java | | {{DEV_PORT}} | Development server port | 3000, 8000, 5000 | | {{DEV_PORT_FLAG}} | Flag or env var that sets the dev port | --port 3000, PORT=3000 | | {{DEPLOY_PLATFORM}} | Deployment target | Vercel, AWS, Azure, Heroku | | {{DATABASE}} | Database/ORM | Prisma, Eloquent, EF Core, SQLAlchemy, ActiveRecord | | {{TEST_FRAMEWORK}} | Testing framework | Vitest, PHPUnit, xUnit, pytest, RSpec, JUnit | | {{ISSUE_TRACKER}} | Issue tracking system | Jira, Linear, GitHub Issues | | {{PM_URL}} | Issue tracker base URL | https://yourorg.atlassian.net, https://linear.app/myteam | | {{PROJECT_KEY}} | Project/team key | PROJ, ENG | | {{PM_ISSUE_KEY}} | Issue key format | PROJ-###, #42, ENG-### | | {{DEFAULT_BRANCH}} | Default git branch | main, master | | {{RUNTIME_VERSION}} | Runtime version | Node 20, PHP 8.3, .NET 8, Python 3.12 | | {{REPO_URL}} | Repository URL | https://github.com/org/repo | | {{SRC_DIR}} | Source directory | src, app, lib | | {{TEST_DIR}} | Test directory | tests, test, spec | | {{STYLING}} | Styling solution | Tailwind, CSS Modules, SCSS | | {{NODE_VERSION}} | Node.js version | 20, 22 | | {{LICENSE_TYPE}} | License identifier | MIT, Apache-2.0, ISC | | {{SRC_STRUCTURE}} | Source folder structure | components/, lib/, utils/ |

Command Placeholders

| Placeholder | Description | Example | | --------------------- | -------------------- | --------------------------------------------------- | | {{INSTALL_COMMAND}} | Install dependencies | npm install, composer install, dotnet restore | | {{SETUP_COMMAND}} | Install command | npm install, composer install, dotnet restore | | {{DEV_COMMAND}} | Run dev server | npm run dev, php artisan serve, dotnet watch | | {{BUILD_COMMAND}} | Build for production | npm run build, dotnet publish | | {{TEST_COMMAND}} | Run tests | npm test, ./vendor/bin/phpunit, dotnet test | | {{LINT_COMMAND}} | Run linting | npm run lint, ./vendor/bin/pint |

Monorepo-Specific Placeholders

| Placeholder | Description | Example | | --------------------------- | -------------------------- | ------------------------------------------------------- | | {{APP_NAME_1}} | First app name | web, frontend | | {{APP_NAME_2}} | Second app name | api, server | | {{APP_1_DESCRIPTION}} | First app description | Web frontend | | {{APP_2_DESCRIPTION}} | Second app description | API server | | {{APP_1_FRAMEWORK}} | First app framework | Next.js, Vue | | {{APP_2_FRAMEWORK}} | Second app framework | Express, Hono | | {{APP_1_DEV_PORT}} | First app dev port | 3000 | | {{APP_2_DEV_PORT}} | Second app dev port | 8787 | | {{PACKAGE_NAME_1}} | First package name | ui, shared | | {{PACKAGE_NAME_2}} | Second package name | utils, types | | {{PACKAGE_1_DESCRIPTION}} | First package description | Shared UI components | | {{PACKAGE_2_DESCRIPTION}} | Second package description | Utility functions | | {{BUILD_SYSTEM}} | Monorepo build tool | Turborepo, Nx, MSBuild, Gradle, Cargo | | {{MONOREPO_CONFIG}} | Config file name | turbo.json, nx.json, *.sln, settings.gradle.kts | | {{APP_DIR}} | Apps directory | apps, src, services, Modules | | {{PACKAGES_DIR}} | Packages directory | packages, libs, internal, pkg | | {{PACKAGE_SCOPE}} | Package scope/namespace | @my-org, MyCompany, my_package | | {{DOCS_APP}} | Docs app name | docs, documentation, storybook | | {{DOCS_CONTENT_DIR}} | Docs app content path | content/docs/, pages/, src/content/ | | {{APP_3}} | Third app name | web, marketing, landing | | {{PROJECT_STRUCTURE}} | Full project structure | (Generated tree diagram) |

Factory Placeholders

Used by the opt-in factory (.agents/skills/factory/SKILL.md and .agents/skills/factory/roles/*.md).

| Placeholder | Description | Example | | --------------------------- | ------------------------------------------------------------------------------------------- | ------------------------ | | {{DEFAULT_BRANCH}} | Branch factory jobs start from and merge into | main, master | | {{FACTORY_PORT_BASE}} | Base dev-server port. Job n uses base + 10n for the builder, +1 for ux, and +2 for ui | 5100 | | {{APPROVAL_MODE}} | human stops at awaiting-human; auto merges on approval | human, auto | | {{FACTORY_REVIEW_LENSES}} | Review lenses to run. ux and ui need browser tooling | code, security | | {{FACTORY_FEATURE_PATHS}} | Comma-separated feature documentation paths; repo default is docs/features, monorepo default is apps/*/docs/features, docs/features | docs/features | | {{MERGE_MODE}} | local merges locally (default); push-mr pushes and opens a merge request | local, push-mr |

Supported Ecosystems

The bootstrap command supports the following language ecosystems:

| Ecosystem | Config Files | Frameworks | Monorepo Build Systems | | ------------------------- | ------------------------------------ | --------------------------------------------------------- | ------------------------------- | | JavaScript/TypeScript | package.json, tsconfig.json | Next.js, Nuxt, React, Vue, Angular, Express, Hono, NestJS | Turborepo, Nx, Lerna, Yarn/pnpm | | PHP | composer.json, artisan | Laravel, Symfony, CodeIgniter, Slim | Laravel Modules, Symfony Flex | | .NET (C#/F#) | *.csproj, *.sln | Blazor, ASP.NET Core, MAUI, WPF | MSBuild, dotnet CLI | | Python | pyproject.toml, requirements.txt | Django, Flask, FastAPI, Starlette | uv, Poetry, Hatch, PDM | | Ruby | Gemfile, *.gemspec | Rails, Sinatra, Hanami | Packwerk (Shopify) | | Go | go.mod, go.work | Gin, Echo, Fiber, Chi | Go Workspaces | | Rust | Cargo.toml | Actix, Axum, Rocket, Warp | Cargo Workspaces | | Java/Kotlin | pom.xml, build.gradle.kts | Spring Boot, Quarkus, Micronaut | Gradle multi-project, Maven |

File Descriptions

AGENTS.md

The primary context file for AI agents. Contains:

• Project overview and tech stack
• Directory structure
• Coding standards and patterns
• API patterns and examples
• Testing guidelines

.cursor/rules/*.mdc

Cursor IDE behavior rules:

• agent-conduct.mdc - Agent behavior and conduct guidelines
• coding-standards.mdc - Language and framework standards
• project-context.mdc - Project documentation requirements
• version-control.mdc - Git and commit conventions
• what-to-avoid.mdc - Anti-patterns and deprecated practices
• api-server.mdc - API server patterns
• component-structure.mdc - Vue Composition API patterns
• core-libraries.mdc - Core library usage
• environment-tooling.mdc - Environment and tooling configuration
• logging.mdc - Structured logging standards
• logging-comments.mdc - Logging and code comment conventions
• prisma-migrations.mdc - Prisma database migrations
• server-client-separation.mdc - Server/client code separation
• subagent-workflow.mdc - Subagent orchestration patterns
• testing-quality.mdc - Testing standards and quality
• ui-accessibility.mdc - UI and accessibility guidelines

.cursor/commands/*.md

Custom Cursor commands for workflows:

• bootstrap.md - Start here! Analyze project and customize templates
• specify.md - Create feature specifications
• plan.md - Generate implementation plans
• implement.md - Execute implementation tasks
• implement-feature.md - Feature implementation workflow
• implement-fixes.md - Bug fix implementation workflow
• review.md - Code review workflow
• review-pr.md - Pull request review workflow
• commit-push.md - Git commit and push workflow
• constitution.md - Project constitution and principles
• tasks.md - Task management workflow
• assign-tasks.md - Task assignment workflow
• create-skill.md - Create custom AI skills
• playwright-test.md - Playwright test generation
• release-notes.md - Release notes generation

.github/prompts/*.prompt.md

Reusable prompts for GitHub Copilot:

• bootstrap.prompt.md - Start here! Analyze project and customize templates
• commit-push.prompt.md - Conventional commit workflow
• review.prompt.md - Code review checklist
• review-pr.prompt.md - Pull request review
• review-staged.prompt.md - Review staged changes
• implement-feature.prompt.md - Feature implementation
• implement-fixes.prompt.md - Bug fix implementation
• specify.prompt.md - Feature specification
• plan.prompt.md - Implementation planning
• tasks.prompt.md - Task management
• assign-tasks.prompt.md - Task assignment workflow
• create-skill.prompt.md - Create custom AI skills
• playwright-test.prompt.md - Playwright test generation
• release-notes.prompt.md - Release notes generation

.github/instructions/*.instructions.md

GitHub Copilot instruction files:

• project-context.instructions.md - Architecture overview
• patterns.instructions.md - Coding patterns
• workflows.instructions.md - Development workflows
• documentation.instructions.md - Documentation standards for features and fixes
• agent-conduct.instructions.md - Agent behavior and conduct guidelines
• coding-standards.instructions.md - Language and framework coding standards
• deployment.instructions.md - Deployment patterns and configuration
• logging.instructions.md - Structured logging standards
• subagent-workflow.instructions.md - Subagent orchestration patterns
• testing.instructions.md - Testing standards and quality

.github/agents/*.agent.md & .cursor/agents/*.agent.md

Custom agent templates for subagent orchestration (identical files in both directories):

• feature-builder.agent.md - Coordinator — Orchestrates end-to-end feature development
• tdd.agent.md - Coordinator — Test-driven development with red-green-refactor cycle
• planner.agent.md - Worker — Breaks features into implementation tasks
• implementer.agent.md - Worker — Writes production code with TDD
• reviewer.agent.md - Worker — Multi-perspective code review
• researcher.agent.md - Worker — Read-only codebase analysis
• red.agent.md - Worker — Writes failing tests (TDD red phase)
• green.agent.md - Worker — Writes minimal code to pass tests (TDD green phase)
• refactor.agent.md - Worker — Improves code quality while keeping tests green
• admin-portal.agent.md - Domain — Admin portals with RBAC, dashboards, and reporting
• api-specialist.agent.md - Domain — API architecture, documentation, and developer experience
• backend-architect.agent.md - Domain — APIs, databases, and server-side architecture
• documenter.agent.md - Domain — Codebase analysis and comprehensive documentation
• frontend-developer.agent.md - Domain — User interfaces, components, and frontend performance

See Custom Agents & Subagents for detailed usage.

docs/* (Documentation Structure)

Documentation folders for tracking features and fixes:

• docs/features/ - Feature documentation with specs and plans
• docs/fixes/ - Fix documentation with monthly logs and complex fix folders
• docs/architecture/ - Architecture Decision Records (ADRs)
• docs/api/ - API specifications
• templates/ - Reusable documentation templates

Monorepo Note: In monorepos, app-specific docs live in apps/{app}/docs/ and root docs/ is only for monorepo-wide concerns. See monorepo documentation.instructions.md for details.

Documentation Best Practices

Feature Documentation:

• Create folder: docs/features/{{ISSUE_ID}}-FEATURE-NAME/
• Include spec.md (functional specification) and plan.md (implementation plan)
• Use /spec and /plan commands for automatic generation

Fix Documentation:

• Simple fixes: Add to monthly log docs/fixes/{YYYY-MM}.md
• Complex fixes: Create folder docs/fixes/{{ISSUE_ID}}-FIX-NAME/ with spec and plan
• Use Keep a Changelog format

Decision Tree: Is fix complex (multi-file, architectural)? → Folder. Otherwise → Monthly log.

See documentation.instructions.md for comprehensive guidelines.

Custom Agents & Subagents

This toolkit includes 14 custom agent templates that enable subagent-based workflows — a coordinator agent delegates subtasks to specialized worker agents, each with isolated context and specific tools.

Subagents are supported by both VS Code (GitHub Copilot) and Cursor IDE. Agent files are placed in:

• .github/agents/ — GitHub Copilot custom agents
• .cursor/agents/ — Cursor custom agents

Both directories contain identical agent files. The toolkit ships both so agents work regardless of your IDE.

Official Docs: VS Code Subagents · Cursor Subagents

How Subagents Work

Subagents provide context isolation — each subagent runs independently, sees only what the coordinator passes, and returns a focused result. This prevents context pollution and keeps each agent focused.

┌─────────────────────────────────┐
│      Feature Builder            │  ← Coordinator agent
│      (orchestrates workflow)    │
├─────────┬───────────┬───────────┤
│         │           │           │
▼         ▼           ▼           ▼
Planner  Implementer  Reviewer   Researcher
(plan)   (code)       (review)   (read-only)
         │
    ┌────┴────┐
    ▼         ▼
  Tests    Production
  first    code

The coordinator decides when to delegate. You don't need to manually invoke subagents — just describe the task:

• "Use the Feature Builder to implement user authentication"
• "Run the TDD agent for this API endpoint"
• "Use a subagent to research the codebase authentication patterns"

Included Agents

| Agent | Type | Tools | user-invocable | Purpose | | ---------------------- | ----------- | ---------------------------- | ---------------- | --------------------------------------------- | | Feature Builder | Coordinator | agent, edit, search, read | true | Orchestrates end-to-end feature development | | TDD | Coordinator | agent, edit, search, read | true | Red-green-refactor cycle coordination | | Planner | Worker | read, search, edit, terminal | false | Break down features into implementation tasks | | Implementer | Worker | read, search, edit, terminal | false | Write production code following TDD | | Reviewer | Worker | read, search, terminal | false | Multi-perspective code review | | Researcher | Worker | read, search | true | Read-only codebase analysis | | Red | Worker | read, search, edit, terminal | false | Write failing tests (TDD red phase) | | Green | Worker | read, search, edit, terminal | false | Write minimal code to pass tests (TDD green) | | Refactor | Worker | read, search, edit, terminal | false | Improve code quality, keep tests green | | Admin Portal | Domain | read, search, edit, terminal | true | Admin portals with RBAC and dashboards | | API Specialist | Domain | read, search, edit, terminal | true | API architecture, docs, and DX | | Backend Architect | Domain | read, search, edit, terminal | true | APIs, databases, and server architecture | | Documenter | Domain | read, search, edit, terminal | true | Codebase analysis and documentation | | Frontend Developer | Domain | read, search, edit, terminal | true | UI components and frontend performance |

Coordinator agents (Feature Builder, TDD) appear in the agents dropdown and orchestrate worker agents. Worker agents (user-invocable: false) are only accessible as subagents — they don't appear in the dropdown. Domain agents (Admin Portal, API Specialist, Backend Architect, Documenter, Frontend Developer) are user-invocable specialists for specific development domains. Researcher is both user-invocable and usable as a subagent.

Orchestration Patterns

Coordinator → Worker (Feature Builder)

The Feature Builder agent manages the full lifecycle:

1. Research → Researcher subagent analyzes codebase patterns
2. Plan → Planner subagent creates implementation tasks
3. Implement → Implementer subagent writes code (per task)
4. Review → Reviewer subagent checks quality (per task)
5. Iterate → Implementer fixes review issues
6. Verify → Final test run

TDD Red-Green-Refactor

The TDD agent coordinates the classic cycle using the agents frontmatter to restrict which subagents are available:

---
agents: ["Red", "Green", "Refactor"]
---

1. Red → Red subagent writes failing tests
2. Green → Green subagent writes minimal code to pass
3. Refactor → Refactor subagent improves quality

Multi-Perspective Review

You can prompt for parallel review:

"Review this PR through multiple perspectives simultaneously: correctness, security, code quality, and architecture."

The main agent will dispatch independent subagents for each perspective, then synthesize findings.

Agent Frontmatter Reference

Agent files use YAML frontmatter to configure behavior:

---
name: MyAgent # Agent name (required)
description: "When to use..." # Discovery description (required)
tools: ["read", "search", "edit"] # Allowed tools
agents: ["Worker1", "Worker2"] # Restrict which subagents can be used
user-invocable: true # Show in agents dropdown (default: true)
disable-model-invocation: false # Prevent use as subagent (default: false)
model: ["Claude Sonnet 4", "GPT-4o"] # Preferred models (optional)
---

| Property | Default | Description | | -------------------------- | ------- | --------------------------------------------------- | | name | — | Agent name used in dropdown and subagent invocation | | description | — | How the agent is discovered and when it's invoked | | tools | all | Restrict available tools per agent | | agents | * | Restrict which subagents this agent can invoke | | user-invocable | true | Whether it shows in the agents dropdown | | disable-model-invocation | false | Whether other agents can invoke this as a subagent | | model | — | Preferred model(s) for the agent |

Creating Custom Agents

To add project-specific agents:

1. Create a .agent.md file in .github/agents/ and/or .cursor/agents/
2. Add YAML frontmatter with name, description, and tools
3. Write instructions in the markdown body
4. For worker-only agents, set user-invocable: false
5. For coordinator agents, list allowed subagents in agents

Example — Documentation Writer agent:

---
name: Doc Writer
description: "Write and update project documentation. Create READMEs, API docs, and changelogs."
tools: ["read", "search", "edit"]
user-invocable: true
---

# Documentation Writer

Write clear, accurate project documentation following the project's conventions.

## Process

1. Read existing documentation and code
2. Identify what needs documenting
3. Write documentation following project patterns
4. Cross-reference with code to ensure accuracy

Nested Subagents

By default, subagents cannot spawn further subagents (prevents infinite recursion). To enable nested delegation for divide-and-conquer patterns:

• VS Code: Enable chat.subagents.allowInvocationsFromSubagents in settings
• Cursor: Supported by default with a maximum nesting depth

Integration with Skills

The bundled skills complement custom agents:

• subagent-driven-development — Full workflow for executing plans via subagent dispatch with two-stage review
• dispatching-parallel-agents — Patterns for parallel agent coordination on independent problems
• writing-plans — Creating the plans that Feature Builder and TDD agents execute
• test-driven-development — The TDD methodology that Red/Green/Refactor agents implement

Factory (opt-in, v5)

The factory is an opt-in pipeline for feature-sized work. One orchestrator takes a feature through spec → plan gate → build → review → approve → merge. Each job belongs to a feature folder, docs/features/<KEY>-<slug>/ (or docs/features/<slug>/ before a ticket exists), which holds spec.md and, for large work, a slim tasks.md. Job state lives under factory/jobs/<NNN-slug>/, and each job builds in its own git worktree on branch factory/<id> (or in place on the job's branch, when you ask for --in-place).

It runs alongside Feature Builder and TDD and does not replace them. Nothing runs until you invoke /factory. Quick fixes stay direct.

• Agents: planner (spec and plan), implementer (build, repair, and rework), and reviewer (the code, security, ux, and ui lenses, and approval, each in the mode its dispatch names). The native agents ship for Claude Code, GitHub Copilot, Cursor, and OpenCode. Each role's Factory rules are in .agents/skills/factory/roles/. Codex runs those briefs directly.
• Setup and reference: src/repo/factory/README.md (the monorepo copy is in src/monorepo/factory/). The installer copies factory/ into your project.

| Command | What it does | | --- | --- | | /factory <feature request> | Intake: reads the project and the features it touches, asks only the glaring questions, then asks you to continue or change the answers. Nothing is created before you continue | | /factory start <KEY \| slug \| job-id> | Pick up an existing feature folder by ticket key or slug, or resume its open job (for example one waiting at a gate). Add --in-place only for a new job | | /factory approve <job-id> | Merge a job waiting for you (awaiting-human or needs-human); on a merged job, move its tickets to Done | | /factory rework <job-id> <note> | Restart the builder with your note and a fresh retry budget | | /factory status [--all] | Summarize open jobs (read-only). Closed jobs are hidden unless --all | | /factory watch [--all] | Show the status table here, then print the command to run the live view in your terminal (read-only). Closed jobs are hidden unless --all | | /factory archive [--all] [--dry-run] | Move closed jobs (merged or abandoned) from factory/jobs/ to factory/archive/. By default only jobs not updated for 7 days move. --dry-run moves nothing. Open jobs never move | | /factory prune [--all] [--abandoned] [--dry-run] | Permanently delete closed jobs from factory/jobs/ and factory/archive/, after one confirmation. By default only merged jobs (same 7-day age rule as archive; --all drops the age limit). --abandoned also deletes abandoned jobs. Open jobs and docs/features/ are never touched |

Two gates are mandatory. Every job stops at awaiting-spec after the spec, and at awaiting-plan after the plan. At the spec gate you confirm the spec or request changes. At the plan gate you review the tasks, the size, the tracking proposal, and the build mode, then confirm or request changes. Leave either gate for later with /factory start <job-id>. Nothing is ticketed or built before you confirm the plan.

The builder also writes qa.md. It lists how to run the feature, numbered manual checks tied to the acceptance criteria, and what the automated tests do not cover. The orchestrator shows it before approval as suggested checks. It is not a gate.

The approval gate is on by default. With {{APPROVAL_MODE}} set to human, an approved job stops at awaiting-human until you run /factory approve <job-id>. Set {{APPROVAL_MODE}} to auto to merge on approval instead. The approver still escalates changes to auth, payments, migrations, and similar high-risk areas. Merges are local, and the factory never pushes.

Check jobs from a terminal:

npx nitm-ai-dev-toolkit factory status [--all]        # one-shot table of open jobs (--all: closed too)
npx nitm-ai-dev-toolkit factory watch [--all]         # live view: ↑/↓ to select, Enter to open, q to quit
npx nitm-ai-dev-toolkit factory archive [--all] [--dry-run]   # move closed jobs to factory/archive/
npx nitm-ai-dev-toolkit factory prune [--all] [--abandoned] [--dry-run]   # list merged jobs to delete; add --yes to delete them

status and watch read factory/jobs/*/job.json, write nothing, and hide closed jobs unless --all is passed. archive moves closed jobs and touches no git state. prune permanently deletes merged jobs from both folders, after you confirm. Pass --abandoned to delete abandoned jobs too. Neither touches open jobs or docs/features/. The factory's placeholders are listed under Factory Placeholders.

AI Agent Skills

Enhance your AI agents with specialized capabilities using the Agent Skills open format. Skills are folders of instructions, scripts, and resources that agents can discover and use to perform tasks more accurately and efficiently.

Skills Resources

| Resource | Description | | --------------------------------------------- | ----------------------------------------------------------------------------------------- | | agentskills.io | Official specification, documentation, and integration guides for the Agent Skills format | | skills.sh | Community skills directory with leaderboard and one-command installation |

How Skills Work

Skills use progressive disclosure to manage context efficiently:

1. Discovery: Agents load only the name and description of each skill
2. Activation: When a task matches a skill's description, the agent reads full instructions
3. Execution: The agent follows instructions, loading referenced files or code as needed

Skill Structure

At its core, a skill is a folder containing a SKILL.md file:

my-skill/
├── SKILL.md        # Required: instructions + metadata
├── scripts/        # Optional: executable code
├── references/     # Optional: documentation
└── assets/         # Optional: templates, resources

Installing Skills

Install skills from skills.sh using the -a or --agent flag to specify your AI agent:

# For a single agent
npx -y skills add -a cursor <owner/repo> --skill <confirmed name> --agent github-copilot cursor

# For multiple agents (use multiple -a flags)
npx -y skills add -a cursor -a github-copilot <owner/repo> --skill <confirmed name> --agent github-copilot cursor

Agent Detection

The skills CLI automatically detects which agents you have installed when you run any command. If you don't specify the -a flag, you'll be prompted to select from your detected agents.

Supported agents include:

• Cursor, GitHub Copilot, Windsurf, Cline, Continue, Aider, Zed, Roo Code, and 35+ more
• See full list of supported agents

Agent-Specific Installation Examples

# For GitHub Copilot only
npx -y skills add -a github-copilot <owner/repo> --skill <confirmed name> --agent github-copilot cursor

# For Cursor only
npx -y skills add -a cursor <owner/repo> --skill <confirmed name> --agent github-copilot cursor

# For Windsurf only
npx -y skills add -a windsurf <owner/repo> --skill <confirmed name> --agent github-copilot cursor

# For Cline only
npx -y skills add -a cline <owner/repo> --skill <confirmed name> --agent github-copilot cursor

# For both Cursor and GitHub Copilot
npx -y skills add -a cursor -a github-copilot <owner/repo> --skill <confirmed name> --agent github-copilot cursor

Important: Always specify the agent(s) explicitly using -a <agent-name> to install only for the agents you actively use. You can specify multiple agents using multiple -a flags. This prevents creating unnecessary configurations for unused agents.

Skills are installed to {.cursor|.agents|.github}/skills/ and automatically available to your selected AI agent(s).

Bundled Universal Skills

This toolkit includes 33 pre-installed universal skills in the .agents/skills/ folder. These skills are copied automatically when you set up your project and require no additional installation.

| Skill | Description | | ---------------------------------- | ---------------------------------------------------------------------------------------------------- | | test-driven-development | TDD practices with red-green-refactor workflow. Write failing test first, then minimal code to pass. | | systematic-debugging | Structured debugging methodology. Find root cause before attempting fixes—no guessing. | | verification-before-completion | Quality checks before claiming work is done. Evidence before assertions, always. | | writing-plans | Creating clear implementation plans before coding. | | executing-plans | Following through on implementation plans systematically. | | factory | Opt-in spec-to-merge feature pipeline with review lenses and an approval gate. | | requesting-code-review | Best practices for requesting code reviews from teammates. | | receiving-code-review | Responding constructively to review feedback. | | brainstorming | Structured ideation and problem-solving sessions. | | writing-skills | Creating effective SKILL.md files for custom skills. | | using-superpowers | Meta-skill for leveraging the full skill system. | | using-git-worktrees | Git worktree workflows for parallel development. | | dispatching-parallel-agents | Coordinating multiple AI agents on related tasks. | | subagent-driven-development | Breaking complex tasks into subagent-manageable chunks. | | finishing-a-development-branch | Completing and merging development branches cleanly. | | logging | Structured logging standards, log levels, and observability patterns. | | project-documentation | README files, code comments, ADRs, and changelog best practices. | | ponytail | Forces the laziest solution that actually works — YAGNI, stdlib, native, one-line, minimum. | | ponytail-audit | Whole-repo audit for over-engineering. Scans entire codebase for what to delete, simplify, replace. | | ponytail-debt | Harvests ponytail: comments into a tracked debt ledger so shortcuts don't rot into neglect. | | ponytail-gain | Displays ponytail's benchmarked impact scoreboard: less code, less cost, more speed. | | ponytail-help | Quick-reference card for all ponytail modes, skills, commands, and deactivation. | | ponytail-review | Code review focused exclusively on over-engineering: finds what to delete in a diff. | | orient-to-recent-work | Build a compact mental model of recent project activity (CHANGELOG, recent commits) before any non-trivial task. Auto-loaded at session start. | | acli | Atlassian CLI wrapper for Jira and Confluence operations from the terminal. | | code-simplifier | Simplifies code for clarity without changing behavior. Use for readability and maintainability. | | debugger | Structured debugging methodology with systematic root cause analysis. | | gh-cli | GitHub CLI reference for issues, PRs, repos, and workflow management. | | issue-tracker | Issue tracker integration patterns for Jira, Linear, and GitHub Issues. | | linear-cli | Linear CLI reference for issue management and project tracking. | | security-reviewer | Security-focused code review patterns for finding vulnerabilities. | | bkt-cli | Bitbucket CLI (bkt) command reference for repo and monorepo templates. | | glab-cli | GitLab CLI (glab) command reference for repo and monorepo templates. |

These skills are ready to use immediately after copying the templates. No npx -y skills add -a <agent> <owner/repo> --skill <confirmed name> --agent github-copilot cursor commands needed.

The ponytail skill bundle is an integrated optional skill set from DietrichGebert/ponytail that adds YAGNI/stdlib/native/one-line/minimum discipline to your AI agents. It includes 6 skills, 6 commands, 7 activation hooks, and ambient agent rules. OpenCode uses the author's upstream @dietrichgebert/ponytail package, installed globally by the operator, not a bundled local plugin. See native setup; scaffolding alone does not establish activation. The Claude Code hooks in hooks/*.json use ${CLAUDE_PLUGIN_ROOT} and are plugin-only: they fire only when installed through the Ponytail plugin, not from project settings.

Additional Recommended Skills

Beyond the bundled skills, these additional skills complement this toolkit for specific use cases:

Note: All install commands in the tables below should include the -a <agent> flag to specify your AI agent. For example:

• npx -y skills add -a github-copilot obra/superpowers --skill <confirmed name> --agent github-copilot cursor (for GitHub Copilot only)
• npx -y skills add -a cursor obra/superpowers --skill <confirmed name> --agent github-copilot cursor (for Cursor only)
• npx -y skills add -a cursor -a github-copilot obra/superpowers --skill <confirmed name> --agent github-copilot cursor (for both Cursor and GitHub Copilot)

Tip: If you omit the -a flag, the CLI will automatically detect your installed agents and prompt you to choose.

Development Workflow Skills (External)

If you want the original obra/superpowers skills (which the bundled skills are derived from), or additional workflow skills:

| Skill | Install Command | Description | | -------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------- | | Superpowers workflow skill | npx -y skills add obra/superpowers --skill <confirmed name> --agent github-copilot cursor | One named workflow skill from the original source |

Security & Quality Skills

| Skill | Install Command | Description | | -------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------- | | Semgrep | npx -y skills add trailofbits/skills --skill <confirmed name> --agent github-copilot cursor | Static analysis patterns | | Property-Based Testing | npx -y skills add trailofbits/skills --skill <confirmed name> --agent github-copilot cursor | Testing with property-based approaches | | Code Review | npx -y skills add skillcreatorai/Ai-Agent-Skills --skill <confirmed name> --agent github-copilot cursor | Comprehensive code review guidance | | Logging Best Practices | npx -y skills add boristane/agent-skills --skill <confirmed name> --agent github-copilot cursor | Structured logging patterns |

Frontend Skills

| Skill | Install Command | Description | | ------------------------------- | -------------------------------------------------------------------------------------- | ------------------------------- | | Vercel React Best Practices | npx -y skills add vercel-labs/agent-skills --skill vercel-react-best-practices --agent github-copilot cursor | React patterns and optimization | | Web Design Guidelines | npx -y skills add vercel-labs/agent-skills --skill <confirmed name> --agent github-copilot cursor | UI/UX design principles | | Frontend Design | npx -y skills add anthropics/skills --skill <confirmed name> --agent github-copilot cursor | General frontend patterns | | TailwindCSS Setup | npx -y skills add expo/skills --skill <confirmed name> --agent github-copilot cursor | Tailwind configuration |

Framework-Specific Skills

| Skill | Install Command | Description | | --------------- | ------------------------------------------------------------------------------------------------- | ------------------------- | | Vue | npx -y skills add onmax/nuxt-skills --skill vue --agent github-copilot cursor | Vue.js best practices | | Nuxt | npx -y skills add onmax/nuxt-skills --skill nuxt --agent github-copilot cursor | Nuxt framework patterns | | Nuxt UI | npx -y skills add onmax/nuxt-skills --skill <confirmed name> --agent github-copilot cursor | Nuxt UI component library | | Better Auth | npx -y skills add better-auth/skills --skill <confirmed name> --agent github-copilot cursor | Aut