nitm-ai-dev-toolkit 3.0.15

package/src/monorepo/.claude/rules-snippets/patterns.md

@@ -0,0 +1,134 @@
+## Workspace Conventions
+
+### Package Naming
+
+- Apps: Direct name (e.g., `web`, `api`, `docs`)
+- Packages: Scoped (e.g., `@{{PROJECT_NAME}}/ui`, `@{{PROJECT_NAME}}/utils`)
+
+### Import Paths
+
+```typescript
+// From shared packages
+import { Button } from "@{{PROJECT_NAME}}/ui";
+
+// Internal app imports
+import { Component } from "@/components";
+import { utils } from "~/utils";
+```
+
+## Turbo Tasks
+
+### Task Dependencies
+
+```json
+{
+	"tasks": {
+		"build": {
+			"dependsOn": ["^build"],
+			"outputs": ["dist/**"]
+		},
+		"dev": {
+			"cache": false,
+			"persistent": true
+		}
+	}
+}
+```
+
+### Running Tasks
+
+```bash
+# All workspaces
+{{PACKAGE_MANAGER}} build
+
+# Specific workspace
+{{PACKAGE_MANAGER}} build --filter={{APP_NAME_1}}
+
+# Workspace and dependencies
+{{PACKAGE_MANAGER}} build --filter={{APP_NAME_1}}...
+```
+
+## SRP and reuse-first principle
+
+- **Before implementing new functionality, review existing patterns** in shared packages (`{{UTILS_PATH}}`, `{{HELPERS_PATH}}`, `{{COMPOSABLES_PATH}}`) for capabilities that already solve the problem.
+- **Prefer extending existing utilities** over creating new ones or duplicating logic inline — a new solution is only warranted when the existing one genuinely cannot accommodate the use case.
+- **Never duplicate state or behavior** that an existing utility already manages (e.g., loading flags, error state, async wrappers). Inline duplication violates SRP and makes behavior inconsistent across the monorepo.
+- When in doubt, extend the existing pattern and keep consumers (components, controllers, handlers) thin.
+- Reusable logic belongs in a shared `packages/` module, not copied across apps.
+
+## Shared Configuration
+
+### ESLint
+
+```javascript
+// packages/config/eslint/base.js
+module.exports = {
+	extends: ["eslint:recommended"],
+};
+
+// apps/{{APP_NAME_1}}/eslint.config.js
+import base from "@{{PROJECT_NAME}}/config/eslint";
+export default [...base];
+```
+
+### TypeScript
+
+```json
+// packages/config/typescript/base.json
+{
+  "compilerOptions": {
+    "strict": true
+  }
+}
+
+// apps/{{APP_NAME_1}}/tsconfig.json
+{
+  "extends": "@{{PROJECT_NAME}}/config/typescript"
+}
+```
+
+## Adding New Packages
+
+1. Create directory in `packages/` or `apps/`
+2. Add `package.json` with proper scope
+3. Update monorepo config if needed
+4. Add to consuming packages
+
+## Adding Dependencies
+
+```bash
+# To specific app/package
+{{PACKAGE_MANAGER}} add <package> --filter={{APP_NAME_1}}
+
+# To root workspace
+{{PACKAGE_MANAGER}} add -D <package> -w
+
+# Internal package dependency
+{{PACKAGE_MANAGER}} add @{{PROJECT_NAME}}/{{PACKAGE_NAME_1}} --filter={{APP_NAME_1}}
+```
+
+## Code Sharing Patterns
+
+### Shared Package Usage
+
+```typescript
+// packages/{{PACKAGE_NAME_1}}/src/index.ts
+export { Component } from "./Component";
+export type { ComponentProps } from "./types";
+
+// apps/{{APP_NAME_1}}/src/pages/index.tsx
+import { Component } from "@{{PROJECT_NAME}}/{{PACKAGE_NAME_1}}";
+```
+
+### Configuration Sharing
+
+```typescript
+// packages/config/eslint/base.js
+module.exports = {
+	/* shared rules */
+};
+
+// apps/{{APP_NAME_1}}/eslint.config.js
+import base from "@{{PROJECT_NAME}}/config/eslint";
+export default [...base];
+```

package/src/monorepo/.claude/rules-snippets/ponytail.md

@@ -0,0 +1,24 @@
+# Ponytail, lazy senior dev mode
+
+You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
+
+Before writing any code, stop at the first rung that holds:
+
+1. Does this need to be built at all? (YAGNI)
+2. Does the standard library already do this? Use it.
+3. Does a native platform feature cover it? Use it.
+4. Does an already-installed dependency solve it? Use it.
+5. Can this be one line? Make it one line.
+6. Only then: write the minimum code that works.
+
+Rules:
+
+- No abstractions that weren't explicitly requested.
+- No new dependency if it can be avoided.
+- No boilerplate nobody asked for.
+- Deletion over addition. Boring over clever. Fewest files possible.
+- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
+- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path.
+
+Not lazy about: input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test.

package/src/monorepo/.claude/rules-snippets/prisma-migrations.md

@@ -0,0 +1,6 @@
+- {{DATABASE_SYNC_RULE}}
+- Create migrations with descriptive names.
+- Apply migrations to development database before committing.
+- Maintain corresponding model definitions for database entities.
+- Update affected services after schema changes.
+- Run tests after schema modifications.

package/src/monorepo/.claude/rules-snippets/project-context.md

@@ -0,0 +1,8 @@
+
+- Review project documentation before generating code or suggestions.
+- Check `docs/` directory for architecture and design decisions.
+- Update documentation for new features or architectural changes.
+- Reference AGENTS.md for project overview, agent conduct rules, and skills.
+- Reference `.claude/rules-snippets/` for detailed standards (coding, testing, deployment, logging, etc.).
+- Follow agent conduct rules: ask for clarification on ambiguous requirements before proceeding.
+- Check app-specific AGENTS.md files for per-app patterns and conventions.

package/src/monorepo/.claude/rules-snippets/server-client-separation.md

@@ -0,0 +1,5 @@
+- Never import server-only code in client components.
+- Use API endpoints to expose server functionality to clients.
+- Create shared types for cross-boundary use.
+- Use appropriate data fetching patterns for the framework.
+- Mark server-only modules clearly (e.g., `.server.{{LANGUAGE_EXTENSION}}`).

package/src/monorepo/.claude/rules-snippets/subagent-workflow.md

@@ -0,0 +1,134 @@
+# Subagent Workflow
+
+## 🛑 BEFORE STARTING: Orchestration Checkpoint
+
+**READ THIS SECTION FIRST if you are about to start work.** This instruction file is loaded automatically for multi-step tasks, meaning:
+
+1. **You are likely handling 2+ of:** research, planning, implementation, testing, review, validation
+2. **You MUST answer:** Does this task involve independent subtasks or multiple domains?
+3. **If YES:** Use a coordinator agent (Feature Builder, TDD, or other) instead of single-agent execution
+4. **If NO (single focused task):** Document why you're using a single agent, then proceed
+
+### Signs You Should Use Orchestrator-First
+
+- ✅ Multiple files across different directories
+- ✅ Planning phase + implementation phase
+- ✅ Multiple independent reviewable chunks
+- ✅ Different domain areas (backend + frontend + docs)
+- ✅ Test coverage needed alongside changes
+- ✅ Architecture decisions before coding
+- ✅ Direct code review feedback (no implementation)
+- ✅ Research task (no code changes)
+
+### Signs Single Agent Is OK
+
+- ✅ Single file edit
+- ✅ Quick typo/syntax fix
+- ✅ Small documentation update
+
+**When in doubt, use orchestrator-first.** It is lower-cost than sequential agent work and provides better code review isolation.
+
+---
+
+## Orchestrator-First Principle
+
+**Default to using a coordinator agent for non-trivial work.** Coordinators break complex tasks into focused subtasks and dispatch specialized subagents with context isolation.
+
+## When to Use Orchestrator + Subagents
+
+- Features spanning multiple files or domains
+- Tasks requiring planning → implementation → review cycles
+- Work that benefits from domain specialization (backend, frontend, API)
+- Any task with 2+ independent subtasks
+
+## When to Use a Single Agent Directly
+
+- Quick one-file fixes or small edits
+- Research questions that don't require code changes
+- Ad-hoc code reviews (invoke Reviewer directly)
+- Simple documentation updates
+- Domain-specific advice without implementation
+
+## Available Coordinators
+
+| Coordinator         | Purpose                                      | Dispatches                                                                                                                  |
+| ------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| **Feature Builder** | End-to-end feature development orchestration | Planner, Implementer, Reviewer, Researcher, Backend Architect, Frontend Developer, API Specialist, Admin Portal, Documenter |
+| **TDD**             | Red-green-refactor cycle coordination        | Red, Green, Refactor                                                                                                        |
+
+## Domain Specialist Selection
+
+When dispatching implementation tasks, match the specialist to the domain:
+
+| Domain                             | Specialist             |
+| ---------------------------------- | ---------------------- |
+| API design, databases, system arch | **Backend Architect**  |
+| UI components, state, responsive   | **Frontend Developer** |
+| API contracts, docs, versioning    | **API Specialist**     |
+| Admin dashboards, RBAC, reporting  | **Admin Portal**       |
+| Project documentation              | **Documenter**         |
+| General / cross-cutting            | **Implementer**        |
+
+## Orchestration Patterns
+
+### Sequential (default)
+
+Tasks with dependencies are implemented one at a time in dependency order. Each must pass review before the next begins.
+
+### Parallel
+
+Independent tasks can be dispatched to multiple specialist subagents simultaneously. Use when tasks don't share files or state.
+
+### Parallelization Analysis (REQUIRED before dispatching)
+
+Before executing any task list, the orchestrator MUST run this analysis:
+
+1. **Scan for `[P]` markers** in the task list — these are pre-identified parallel candidates
+   - If no `[P]` markers exist, do **not** assume sequential-only work. Treat all tasks as candidates and infer parallel-safe groups via the independence test.
+2. **Build a dependency graph**: For each task, list which files it reads and writes
+3. **Apply the independence test**:
+   - Tasks that write to **different files** with **no shared state** → parallel-safe
+   - Tasks that share any writable file → sequential (dependency edge)
+   - Tasks where one reads what another writes → sequential (data dependency)
+4. **Group by domain** for specialist routing:
+   - Backend tasks → Backend Architect
+   - Frontend tasks → Frontend Developer
+   - API contract tasks → API Specialist
+   - Documentation tasks → Documenter
+   - Cross-cutting → Implementer
+5. **Dispatch decision**:
+   - **3+ independent tasks** → Use `dispatching-parallel-agents` skill, one agent per task
+   - **2 independent tasks** → Parallel dispatch (simpler coordination)
+   - **All tasks dependent** → Sequential with `subagent-driven-development` skill
+   - **Mixed** → Dispatch independent group in parallel, then continue sequential chain
+
+```
+Example: 5 tasks → T001 (setup) → T002 [P] (backend API) + T003 [P] (frontend UI) + T004 [P] (docs) → T005 (integration tests)
+         Dispatch: T001 sequential → T002+T003+T004 parallel → T005 sequential
+```
+
+## Quality Gates
+
+- Every implementation must pass **Reviewer** before proceeding
+- Every plan must pass **Reviewer** before final acceptance during a commit or before implementation begins
+- Coordinators should not skip review even for "simple" changes
+- If a reviewer requests changes, the original specialist fixes them and re-review occurs
+
+## Skills Integration
+
+These skills complement subagent workflows:
+
+| Skill                            | When to Use                                      |
+| -------------------------------- | ------------------------------------------------ |
+| `writing-plans`                  | Creating implementation plans before execution   |
+| `subagent-driven-development`    | Executing plans with fresh subagent per task     |
+| `executing-plans`                | Following through on plans in a separate session |
+| `dispatching-parallel-agents`    | Multiple independent problems to solve           |
+| `requesting-code-review`         | Structured review between implementation stages  |
+| `receiving-code-review`          | Responding constructively to review feedback     |
+| `verification-before-completion` | Quality checks before claiming work done         |
+| `finishing-a-development-branch` | Completing work after all tasks pass review      |
+| `orient-to-recent-work`          | Build context from recent project activity       |
+| `brainstorming`                  | Structured ideation when scope is fuzzy          |
+| `systematic-debugging`           | Structured root cause investigation              |
+| `using-superpowers`              | Leveraging the full skill system                 |

package/src/monorepo/.claude/rules-snippets/testing-quality.md

@@ -0,0 +1,5 @@
+- Ensure lint, test, and build pass before committing.
+- Use {{TEST_FRAMEWORK}} for unit/component tests.
+- Use {{E2E_FRAMEWORK}} for end-to-end tests.
+- Place tests alongside implementation files or in `tests/` directory.
+- Aim for meaningful test coverage of business logic.

package/src/monorepo/.claude/rules-snippets/testing.md

@@ -0,0 +1,42 @@
+## Commands
+
+```bash
+# All tests
+{{PACKAGE_MANAGER}} test
+
+# Specific app/package tests
+{{PACKAGE_MANAGER}} test --filter={{APP_NAME_1}}
+
+# Watch mode
+{{PACKAGE_MANAGER}} test --filter={{APP_NAME_1}} -- --watch
+```
+
+## Test Locations
+
+### Unit Tests
+
+- Located in each package: `{{PACKAGES_DIR}}/**/{{TEST_FILE_PATTERN}}`
+- Located in each app: `{{APP_DIR}}/**/{{TEST_FILE_PATTERN}}`
+- Run with: `{{TEST_COMMAND}}`
+
+### Integration Tests
+
+- Located in: `{{APP_DIR}}/*/{{INTEGRATION_TEST_DIR}}/`
+- Run with: `{{INTEGRATION_TEST_COMMAND}}`
+
+### E2E Tests
+
+- Located in: `{{APP_DIR}}/*/{{E2E_TEST_DIR}}/`
+- Run with: `{{E2E_TEST_COMMAND}}`
+
+## Coverage Requirements
+
+- Minimum coverage: {{COVERAGE_THRESHOLD}}
+- Critical paths must have integration or E2E coverage
+- New features require tests before merging
+
+## Cross-Package Testing
+
+- Shared packages should have standalone unit tests
+- Apps should test integration with shared packages
+- Changes to shared packages must pass all downstream app tests

package/src/monorepo/.claude/rules-snippets/ui-accessibility.md

@@ -0,0 +1,5 @@
+- Develop with a mobile-first approach.
+- Adhere to WCAG 2.1 AA accessibility standards.
+- Use semantic HTML elements.
+- Ensure keyboard navigation and focus management.
+- Use loading states during async operations.

package/src/monorepo/.claude/rules-snippets/version-control.md

@@ -0,0 +1,4 @@
+- Use conventional commit format: `<type>(<scope>): <description>`.
+- Types: feat, fix, docs, refactor, test, chore, style, perf.
+- Include ticket reference when applicable: `feat(auth): add login flow [{{ISSUE_PREFIX}}-123]`.
+- Follow the PR template for pull requests.

package/src/monorepo/.claude/rules-snippets/what-to-avoid.md

@@ -0,0 +1,6 @@
+- No deprecated {{FRAMEWORK}} features.
+- No global CSS outside {{STYLING}} configuration.
+- No direct DOM manipulation; use framework reactivity.
+- No custom solutions for problems solved by core libraries.
+- No inconsistent naming for events or handlers.
+- No mixing server and client code inappropriately.

package/src/monorepo/.claude/rules-snippets/workflows.md

@@ -0,0 +1,81 @@
+## Development
+
+```bash
+# Start all apps
+{{PACKAGE_MANAGER}} dev
+
+# Start specific app
+{{PACKAGE_MANAGER}} dev --filter={{APP_NAME_1}}
+
+# Start app and its dependencies
+{{PACKAGE_MANAGER}} dev --filter={{APP_NAME_1}}...
+```
+
+## Building
+
+```bash
+# Build all packages
+{{PACKAGE_MANAGER}} build
+
+# Build specific package
+{{PACKAGE_MANAGER}} build --filter={{APP_NAME_1}}
+
+# Build only changed packages
+{{PACKAGE_MANAGER}} build --filter=[origin/main]
+```
+
+## Testing
+
+```bash
+# All tests
+{{PACKAGE_MANAGER}} test
+
+# Specific app/package tests
+{{PACKAGE_MANAGER}} test --filter={{APP_NAME_1}}
+
+# Watch mode
+{{PACKAGE_MANAGER}} test --filter={{APP_NAME_1}} -- --watch
+```
+
+## Adding Features
+
+1. Determine which app/package the feature belongs to
+2. Check app-specific `AGENTS.md` for patterns
+3. Implement following local conventions
+4. Run `{{PACKAGE_MANAGER}} lint` and `{{PACKAGE_MANAGER}} test`
+5. Create PR with conventional commits
+
+## Adding Shared Code
+
+1. Identify if code should be in existing or new package
+2. Add to `packages/{{PACKAGE_NAME}}/src/`
+3. Export from package index
+4. Add dependency to consuming apps
+5. Import using package scope
+
+## CI/CD Integration
+
+```yaml
+steps:
+  - name: Install
+    run: {{PACKAGE_MANAGER}} install
+
+  - name: Build
+    run: {{PACKAGE_MANAGER}} build
+
+  - name: Test
+    run: {{PACKAGE_MANAGER}} test
+
+  - name: Lint
+    run: {{PACKAGE_MANAGER}} lint
+```
+
+## Remote Caching
+
+```bash
+# Login to Vercel (for remote cache)
+turbo login
+
+# Link to remote cache
+turbo link
+```

package/src/monorepo/.claude/settings.json

@@ -0,0 +1,7 @@
+{
+    "permissions": {
+        "allow": [],
+        "deny": []
+    },
+    "env": {}
+}

package/src/monorepo/.claude/skills/README.md

@@ -0,0 +1,50 @@
+# Claude Code Skills
+
+This folder is for skills installed via `npx -y skills add -a claude-code <owner/repo> --skill '*'`.
+
+## About Skills
+
+Skills are folders of instructions and resources that help AI agents perform specific tasks more accurately. They use the [Agent Skills](https://agentskills.io/) open format.
+
+## Installing Skills
+
+Install skills from [skills.sh](https://skills.sh/) using the `-a claude-code` flag:
+
+```bash
+# For Claude Code only
+npx -y skills add -a claude-code <owner/repo> --skill '*'
+
+# For multiple agents (e.g., Claude Code + GitHub Copilot)
+npx -y skills add -a claude-code -a github-copilot <owner/repo> --skill '*'
+```
+
+**Tip:** The skills CLI automatically detects installed agents. If you omit `-a claude-code`, you'll be prompted to choose from detected agents.
+
+**Important:** Always use `-a claude-code` to install only for Claude Code (or add multiple `-a` flags if you use multiple agents). This prevents creating unnecessary configuration files for other agents.
+
+## Pre-installed Skills
+
+Universal workflow skills are pre-installed in `.agents/skills/`. These include:
+
+- test-driven-development
+- systematic-debugging
+- verification-before-completion
+- writing-plans
+- executing-plans
+- And more...
+
+## Examples
+
+```bash
+# Frontend skills
+npx -y skills add -a claude-code onmax/nuxt-skills --skill '*'
+npx -y skills add -a claude-code vercel-labs/agent-skills --skill '*'
+
+# Security skills
+npx -y skills add -a claude-code trailofbits/skills --skill '*'
+
+# Framework-specific
+npx -y skills add -a claude-code better-auth/skills --skill '*'
+```
+
+See the main README.md for a full list of recommended skills.

package/src/monorepo/.cursor/agents/admin-portal.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Build administrator portals with RBAC, system dashboards, reporting, analytics, and operational tooling."
+globs:
+alwaysApply: agent
+---
+
+# Admin Portal
+
+Build secure admin interfaces with RBAC, dashboards, reporting, and monitoring integration.
+
+**CRITICAL: READ:** [.claude/agents-snippets/admin-portal.md](../../.claude/agents-snippets/admin-portal.md)

package/src/monorepo/.cursor/agents/api-specialist.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Design and implement API architecture, documentation, and developer experience."
+globs:
+alwaysApply: agent
+---
+
+# API Specialist
+
+Design, document, and optimize APIs for internal and external consumption.
+
+**CRITICAL: READ:** [.claude/agents-snippets/api-specialist.md](../../.claude/agents-snippets/api-specialist.md)

package/src/monorepo/.cursor/agents/backend-architect.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Design APIs, databases, and server-side architecture for scalable backend systems."
+globs:
+alwaysApply: agent
+---
+
+# Backend Architect
+
+Design and implement scalable, secure, and maintainable server-side systems.
+
+**CRITICAL: READ:** [.claude/agents-snippets/backend-architect.md](../../.claude/agents-snippets/backend-architect.md)

package/src/monorepo/.cursor/agents/documenter.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Analyze codebases and create comprehensive documentation."
+globs:
+alwaysApply: agent
+---
+
+# Documenter
+
+Analyze codebases and produce clear, actionable documentation.
+
+**CRITICAL: READ:** [.claude/agents-snippets/documenter.md](../../.claude/agents-snippets/documenter.md)

package/src/monorepo/.cursor/agents/feature-builder.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Coordinate end-to-end feature development using subagents for planning, implementation, and review."
+globs:
+alwaysApply: agent
+---
+
+# Feature Builder
+
+Coordinate the full lifecycle of feature implementation by delegating to specialized subagents.
+
+**CRITICAL: READ:** [.claude/agents-snippets/feature-builder.md](../../.claude/agents-snippets/feature-builder.md)

package/src/monorepo/.cursor/agents/frontend-developer.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Build user interfaces, implement components, handle state management, and optimize frontend performance."
+globs:
+alwaysApply: agent
+---
+
+# Frontend Developer
+
+Build responsive, accessible, and performant user interfaces.
+
+**CRITICAL: READ:** [.claude/agents-snippets/frontend-developer.md](../../.claude/agents-snippets/frontend-developer.md)

package/src/monorepo/.cursor/agents/green.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Write minimal code to make failing tests pass. Part of the TDD red-green-refactor cycle."
+globs:
+alwaysApply: agent
+---
+
+# Green Agent
+
+Write the minimal production code needed to make failing tests pass.
+
+**CRITICAL: READ:** [.claude/agents-snippets/green.md](../../.claude/agents-snippets/green.md)

package/src/monorepo/.cursor/agents/implementer.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Implement code changes for a specific task following TDD practices."
+globs:
+alwaysApply: agent
+---
+
+# Implementer Agent
+
+Write production-quality code for a specific task following TDD practices.
+
+**CRITICAL: READ:** [.claude/agents-snippets/implementer.md](../../.claude/agents-snippets/implementer.md)

package/src/monorepo/.cursor/agents/planner.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Break down feature requests into clear, actionable implementation tasks."
+globs:
+alwaysApply: agent
+---
+
+# Planner Agent
+
+Break down feature requests into clear, actionable implementation tasks.
+
+**CRITICAL: READ:** [.claude/agents-snippets/planner.md](../../.claude/agents-snippets/planner.md)

package/src/monorepo/.cursor/agents/red.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Write failing tests that define expected behavior. Part of the TDD red-green-refactor cycle."
+globs:
+alwaysApply: agent
+---
+
+# Red Agent
+
+Write tests that define the expected behavior for the given requirement.
+
+**CRITICAL: READ:** [.claude/agents-snippets/red.md](../../.claude/agents-snippets/red.md)

package/src/monorepo/.cursor/agents/refactor.agent.md

@@ -0,0 +1,11 @@
+---
+description: "Improve code quality and structure while keeping all tests passing."
+globs:
+alwaysApply: agent
+---
+
+# Refactor Agent
+
+Improve code quality without changing behavior; all tests must remain green.
+
+**CRITICAL: READ:** [.claude/agents-snippets/refactor.md](../../.claude/agents-snippets/refactor.md)