nitm-ai-dev-toolkit 3.0.15

package/src/repo/.claude/prompt-snippets/tasks.md

@@ -0,0 +1,146 @@
+# Generate Task Breakdown
+
+Break down the implementation plan into executable tasks. This is the third step in the development lifecycle.
+
+## Usage
+
+```
+/tasks {{ISSUE_KEY}}-123
+/tasks docs/features/user-authentication/tasks.md
+```
+
+## Task Consolidation Rules (CRITICAL)
+
+Before creating tasks, apply these consolidation principles:
+
+### Target Task Counts
+
+| Feature Complexity  | Total Tasks | Max Subtasks/Task |
+| ------------------- | ----------- | ----------------- |
+| Simple (< 4 hours)  | 2-3         | 0                 |
+| Medium (4-16 hours) | 3-5         | 2-4               |
+| Complex (16-40 hrs) | 5-8         | 3-6               |
+| Large (40+ hours)   | 8-12        | 5-10              |
+
+### Consolidation Principles
+
+- **Group by deliverable**: Combine work that ships together
+- **Merge related files**: Model + migration + factory = 1 task
+- **Bundle by layer**: All service layer work = 1 task (if related)
+- **Avoid micro-tasks**: Nothing under 1-2 hours as standalone
+- **Limit phases**: Combine Foundation + Implementation when small
+
+### Before Finalizing, Ask:
+
+1. Can any adjacent phases be combined?
+2. Are there tasks under 2 hours that should be merged?
+3. Would a developer naturally complete these together?
+4. Does each task represent meaningful progress?
+
+## Process
+
+1. **Load Context**:
+   - Read specification from `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Read plan from `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md`
+   - Review `AGENTS.md` for project patterns
+
+2. **Generate Consolidated Task Breakdown**:
+
+   Create `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/tasks.md` with phases (combine where appropriate):
+
+   ### Phase 1: Foundation & Setup (combine into 1 task)
+   - Database schema changes, migrations, seeders
+   - Type definitions and interfaces
+   - Base models and validators
+   - Configuration and dependencies
+
+   ### Phase 2: Core Implementation (group by feature area)
+   - Core functionality grouped by component
+   - API endpoints or components (CRUD together)
+   - Business logic and services
+
+   ### Phase 3: Testing (1 task per major component)
+   - Unit tests for component
+   - Integration tests for feature
+   - E2E tests (if applicable)
+
+   ### Phase 4: Polish & Documentation (combine into 1 task)
+   - Error handling improvements
+   - Performance optimization
+   - Documentation updates
+
+3. **Consolidated Task Format**:
+
+   ```markdown
+   ### T001: [Consolidated Task Name]
+
+   **Phase**: [Foundation/Implementation/Testing/Polish]
+   **Estimated Effort**: [Hours - aim for 2-8 hours per task]
+   **Parallel**: [Yes/No]
+
+   **Scope** (what this task covers):
+
+   - [Component/feature 1]
+   - [Component/feature 2]
+   - [Related component 3]
+
+   **Files to Create/Modify**:
+
+   - `{{SRC_DIR}}/path/to/file.{{FILE_EXTENSION}}`
+   - `{{SRC_DIR}}/path/to/related.{{FILE_EXTENSION}}`
+   - `{{TEST_DIR}}/path/to/test.{{FILE_EXTENSION}}`
+
+   **Acceptance Criteria**:
+
+   - [ ] All components implemented
+   - [ ] Tests passing
+   - [ ] No type/lint errors
+
+   **Subtasks** (only if task > 8 hours):
+
+   - [ ] Subtask 1
+   - [ ] Subtask 2
+   ```
+
+4. **Task Ordering Rules**:
+   - Setup before implementation
+   - Tests before or alongside code (TDD)
+   - Core before integration
+   - Everything before polish
+
+5. **Parallel Execution**:
+   - Mark parallelizable tasks with `[P]`
+   - Different feature areas = can be parallel
+   - Same files = sequential
+
+6. **Report Completion**:
+   - Tasks file path
+   - **Consolidated task count** (should be 3-7)
+   - Estimated total effort
+   - **Consolidation note**: "Combined X items into Y tasks"
+   - Ready for `/implement` command
+
+## Anti-Patterns to Avoid
+
+❌ **Don't create separate tasks for**:
+
+- Each individual file
+- "Create X" then "Configure X" then "Test X"
+- Setup tasks under 1 hour
+- Each CRUD operation separately
+
+✅ **Do combine into single tasks**:
+
+- All database work for an entity
+- All API endpoints for a resource
+- All configuration/setup work
+- Related service layer methods
+
+## Orchestrator Dispatch Guide
+
+When this task list is used by `/implement-feature` or `/implement`:
+
+- **Parallel [P] tasks**: Dispatch one subagent per `[P]` task concurrently using `dispatching-parallel-agents` skill
+- **Sequential tasks**: Execute in dependency order, one subagent per task using `subagent-driven-development` skill
+- **Domain routing**: Match each task to the appropriate specialist agent (Backend Architect, Frontend Developer, API Specialist, etc.)
+- **Review gate**: Every task must pass a Reviewer agent before being marked complete

package/src/repo/.claude/rules/agent-conduct.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Agent conduct and clarification rules for ambiguous requirements."
+---
+
+# Agent Conduct
+
+Follow the rules defined in [.claude/rules-snippets/agent-conduct.md](../rules-snippets/agent-conduct.md).
+
+Key points:
+- Use coordinator agents for non-trivial multi-step tasks (orchestration checkpoint).
+- Ask for clarification on ambiguous requirements before making assumptions.
+- Never silently change database schemas, API contracts, or authentication flows.

package/src/repo/.claude/rules/api-server.md

@@ -0,0 +1,16 @@
+---
+applyTo:
+  - "src/server/**"
+  - "src/api/**"
+  - "**/*.server.*"
+description: "API and server-side development standards."
+---
+
+# API & Server
+
+Follow the rules defined in [.claude/rules-snippets/api-server.md](../rules-snippets/api-server.md).
+
+Key points:
+- Follow {{API_ROUTE_PATTERN}} for API route conventions.
+- Validate all input data before processing.
+- Return consistent response formats with proper HTTP status codes.

package/src/repo/.claude/rules/coding-standards.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Coding standards and language conventions."
+---
+
+# Coding Standards
+
+Follow the rules defined in [.claude/rules-snippets/coding-standards.md](../rules-snippets/coding-standards.md).
+
+Key points:
+- All code must follow {{LANGUAGE}} type safety rules and {{FRAMEWORK}} conventions.
+- Keep functions focused and manageable (under 50-75 lines).
+- Use try-catch for async operations; leverage {{FRAMEWORK}} error utilities.

package/src/repo/.claude/rules/component-structure.md

@@ -0,0 +1,15 @@
+---
+applyTo:
+  - "src/components/**"
+  - "**/*.{vue,tsx,jsx}"
+description: "Component structure and composition patterns."
+---
+
+# Component Structure
+
+Follow the rules defined in [.claude/rules-snippets/component-structure.md](../rules-snippets/component-structure.md).
+
+Key points:
+- Follow the {{COMPONENT_PATTERN}} pattern for all components.
+- Use clear and descriptive naming for props, events, and methods.
+- Use bracketed identifiers for logs: `[ComponentName]: message`.

package/src/repo/.claude/rules/core-libraries.md

@@ -0,0 +1,13 @@
+---
+applyTo: "src/**"
+description: "Core library and framework usage conventions."
+---
+
+# Core Libraries
+
+Follow the rules defined in [.claude/rules-snippets/core-libraries.md](../rules-snippets/core-libraries.md).
+
+Key points:
+- Use {{UTILITY_LIBRARY}} for common utilities and {{STATE_MANAGEMENT}} for state.
+- Use {{STYLING}} for styling; prefer utility classes over custom CSS.
+- Use {{UI_LIBRARY}} for UI components; check existing components before creating new ones.

package/src/repo/.claude/rules/environment-tooling.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Environment and tooling configuration."
+---
+
+# Environment & Tooling
+
+Follow the rules defined in [.claude/rules-snippets/environment-tooling.md](../rules-snippets/environment-tooling.md).
+
+Key points:
+- Tailor commands to the user's OS and shell.
+- Use `{{PACKAGE_MANAGER}}` for package management.
+- Follow project-specific tooling rules for linting and formatting.

package/src/repo/.claude/rules/logging-comments.md

@@ -0,0 +1,13 @@
+---
+applyTo: "src/**"
+description: "Logging identifiers and code comment conventions."
+---
+
+# Logging & Comments
+
+Follow the rules defined in [.claude/rules-snippets/logging-comments.md](../rules-snippets/logging-comments.md).
+
+Key points:
+- Comment complex logic and non-obvious implementations.
+- Use bracketed identifiers for logs: `[ModuleName]: message`.
+- Remove debug logs before committing to main branch.

package/src/repo/.claude/rules/logging.md

@@ -0,0 +1,13 @@
+---
+applyTo: "src/**"
+description: "Structured logging standards and best practices."
+---
+
+# Logging Standards
+
+Follow the rules defined in [.claude/rules-snippets/logging.md](../rules-snippets/logging.md).
+
+Key points:
+- Use bracketed tags: `[Source] [Context]: Message | Details`.
+- Use appropriate log levels: error, warn, info, debug.
+- Never log passwords, API keys, tokens, or PII — sanitize before logging.

package/src/repo/.claude/rules/orient-to-recent-work.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Orient to recent project activity before non-trivial tasks."
+---
+
+# Orient to Recent Work
+
+Follow the protocol defined in [../../.agents/skills/orient-to-recent-work/SKILL.md](../../.agents/skills/orient-to-recent-work/SKILL.md).
+
+Key rules:
+- Run the orientation protocol at session start and before any multi-file change.
+- Read CHANGELOG Unreleased, last release, and recent commits.
+- Hold the mental model for the session; skip for trivial fixes.

package/src/repo/.claude/rules/prisma-migrations.md

@@ -0,0 +1,16 @@
+---
+applyTo:
+  - "prisma/**"
+  - "**/migrations/**"
+  - "**/*.prisma"
+description: "Database migration and schema management."
+---
+
+# Prisma Migrations
+
+Follow the rules defined in [.claude/rules-snippets/prisma-migrations.md](../rules-snippets/prisma-migrations.md).
+
+Key points:
+- Follow {{DATABASE_SYNC_RULE}} for database synchronization.
+- Create migrations with descriptive names; apply to dev database before committing.
+- Run tests after schema modifications.

package/src/repo/.claude/rules/project-context.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Project context and documentation references."
+---
+
+# Project Context
+
+Follow the rules defined in [.claude/rules-snippets/project-context.md](../rules-snippets/project-context.md).
+
+Key points:
+- Review project documentation before generating code or suggestions.
+- Reference AGENTS.md for project overview, agent conduct rules, and skills.
+- Reference `.claude/rules-snippets/` for detailed standards (coding, testing, deployment, logging, etc.).

package/src/repo/.claude/rules/server-client-separation.md

@@ -0,0 +1,13 @@
+---
+applyTo: "src/**"
+description: "Server and client code boundary enforcement."
+---
+
+# Server-Client Separation
+
+Follow the rules defined in [.claude/rules-snippets/server-client-separation.md](../rules-snippets/server-client-separation.md).
+
+Key points:
+- Never import server-only code in client components.
+- Use API endpoints to expose server functionality to clients.
+- Mark server-only modules clearly (e.g., `.server.{{LANGUAGE_EXTENSION}}`).

package/src/repo/.claude/rules/subagent-workflow.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Subagent workflow and orchestration patterns."
+---
+
+# Subagent Workflow
+
+Follow the rules defined in [.claude/rules-snippets/subagent-workflow.md](../rules-snippets/subagent-workflow.md).
+
+Key points:
+- Default to orchestrator + subagents for non-trivial work (features, refactors, multi-file fixes).
+- Use a coordinator agent (Feature Builder or TDD) as the entry point.
+- Match task domain to the right specialist before defaulting to Implementer.

package/src/repo/.claude/rules/testing-quality.md

@@ -0,0 +1,16 @@
+---
+applyTo:
+  - "**/*.{test,spec}.*"
+  - "tests/**"
+  - "__tests__/**"
+description: "Testing standards and quality gates."
+---
+
+# Testing & Quality
+
+Follow the rules defined in [.claude/rules-snippets/testing-quality.md](../rules-snippets/testing-quality.md).
+
+Key points:
+- Ensure lint, test, and build pass before committing.
+- Use {{TEST_FRAMEWORK}} for unit/component tests and {{E2E_FRAMEWORK}} for E2E tests.
+- Aim for meaningful test coverage of business logic.

package/src/repo/.claude/rules/testing.md

@@ -0,0 +1,16 @@
+---
+applyTo:
+  - "**/*.{test,spec}.*"
+  - "tests/**"
+  - "__tests__/**"
+description: "Testing standards, commands, and conventions."
+---
+
+# Testing Standards
+
+Follow the rules defined in [.claude/rules-snippets/testing.md](../rules-snippets/testing.md).
+
+Key points:
+- Unit tests: `{{TEST_FILE_PATTERN}}`, integration tests: `{{INTEGRATION_TEST_PATTERN}}`, E2E tests: `{{E2E_TEST_PATTERN}}`.
+- Minimum coverage: {{COVERAGE_THRESHOLD}}.
+- New features require tests before merging.

package/src/repo/.claude/rules/ui-accessibility.md

@@ -0,0 +1,15 @@
+---
+applyTo:
+  - "src/components/**"
+  - "**/*.{vue,tsx,jsx,css,scss}"
+description: "UI accessibility and responsive design standards."
+---
+
+# UI & Accessibility
+
+Follow the rules defined in [.claude/rules-snippets/ui-accessibility.md](../rules-snippets/ui-accessibility.md).
+
+Key points:
+- Develop with a mobile-first approach.
+- Adhere to WCAG 2.1 AA accessibility standards.
+- Use semantic HTML elements and ensure keyboard navigation.

package/src/repo/.claude/rules/version-control.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Version control and commit conventions."
+---
+
+# Version Control
+
+Follow the rules defined in [.claude/rules-snippets/version-control.md](../rules-snippets/version-control.md).
+
+Key points:
+- Use conventional commit format: `<type>(<scope>): <description>`.
+- Types: feat, fix, docs, refactor, test, chore, style, perf.
+- Include ticket reference when applicable.

package/src/repo/.claude/rules/what-to-avoid.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**/*"
+description: "Patterns and practices to avoid."
+---
+
+# What to Avoid
+
+Follow the rules defined in [.claude/rules-snippets/what-to-avoid.md](../rules-snippets/what-to-avoid.md).
+
+Key points:
+- No deprecated {{FRAMEWORK}} features or global CSS outside {{STYLING}} configuration.
+- No direct DOM manipulation; use framework reactivity.
+- No custom solutions for problems solved by core libraries.

package/src/repo/.claude/rules-snippets/agent-conduct.md

@@ -0,0 +1,51 @@
+# Agent Conduct & Interaction Rules
+
+## ⚠️ CRITICAL: Orchestration Checkpoint First
+
+**BEFORE responding to ANY request with multiple steps (research + planning + implementation + testing + review):**
+
+- Read the orchestration checkpoint in [AGENTS.md](../../AGENTS.md#-critical-orchestration-checkpoint-read-first) and [subagent-workflow.md](./subagent-workflow.md#-before-starting-orchestration-checkpoint)
+- Determine if this task requires a coordinator agent (Feature Builder, TDD) or can be single-agent work
+- If multi-step work, document why you're using orchestrator-first in your response before proceeding
+
+This applies to ANY task that involves 2+ of: research, planning, implementation, testing, validation, code review.
+
+---
+
+## Clarification & Assumption Handling
+
+**CRITICAL**: Before making assumptions or proceeding with ambiguous requirements, agents MUST proactively ask the user for clarification. This applies to:
+
+- **Ambiguous requirements**: If a task description is vague, incomplete, or could be interpreted multiple ways, ask the user to clarify before proceeding.
+- **Architecture decisions**: When multiple valid approaches exist (e.g., adding a new service vs. extending an existing one), present options and ask for the user's preference.
+- **Data model changes**: Before adding/modifying database columns, relationships, or entities, confirm the intended schema with the user.
+- **Breaking changes**: If an implementation could break existing functionality, API contracts, or database compatibility, flag it and ask before proceeding.
+- **Scope uncertainty**: If unsure whether a feature should be minimal (MVP) or comprehensive, ask about the desired scope.
+- **External dependencies**: When a task requires secrets, third-party services, or infrastructure not yet configured, ask the user before assuming.
+- **Domain-specific decisions**: Sensitive UX choices or domain-specific behavior should be confirmed with the user first.
+
+## How to Ask for Clarification
+
+- Be specific about what is unclear and why it matters
+- Offer 2-3 concrete options when possible (with a recommended default)
+- Explain the trade-offs of each option briefly
+- If there is a clearly best practice, recommend it but still confirm
+
+### Example
+
+> "This endpoint could return paginated results or the full list. Given the expected data volume, I'd recommend pagination with a default page size of 20. Should I proceed with that approach, or do you prefer returning all results?"
+
+## Decision Documentation
+
+When a clarification is resolved:
+
+1. **Record the decision** in a code comment or relevant documentation
+2. **Reference the rationale** so future agents/developers understand why
+3. **Update specs/plans** if the decision changes the original scope
+
+## Guardrails
+
+- **Never silently change** database schemas, API contracts, or auth flows without confirmation
+- **Never assume scope** — if a task says "add search," ask whether it means basic text search, full-text search, or filter/facet search
+- **Never skip tests** for assumed-correct behavior — confirm expectations first
+- **Prefer reversible changes** when acting without full clarity

package/src/repo/.claude/rules-snippets/api-server.md

@@ -0,0 +1,7 @@
+# API Server
+
+- {{API_ROUTE_PATTERN}}
+- Validate all input data before processing.
+- Return consistent response formats.
+- Use proper HTTP status codes.
+- Document API endpoints in {{API_DOCS_LOCATION}}.

package/src/repo/.claude/rules-snippets/coding-standards.md

@@ -0,0 +1,45 @@
+# Coding Standards
+
+## Primary Pattern: {{PRIMARY_PATTERN_NAME}}
+
+```{{FILE_EXTENSION}}
+{{PRIMARY_PATTERN_EXAMPLE}}
+```
+
+**Rules:**
+
+- {{CODING_RULE_1}}
+- {{CODING_RULE_2}}
+- {{CODING_RULE_3}}
+
+## Data Access Pattern
+
+```{{FILE_EXTENSION}}
+{{DATA_ACCESS_PATTERN}}
+```
+
+## API / Route Pattern
+
+```{{FILE_EXTENSION}}
+{{API_PATTERN}}
+```
+
+## Naming Conventions
+
+- Files: {{FILE_NAMING_CONVENTION}}
+- Components: {{COMPONENT_NAMING_CONVENTION}}
+- Functions: {{FUNCTION_NAMING_CONVENTION}}
+- Variables: {{VARIABLE_NAMING_CONVENTION}}
+
+## Code Quality
+
+- Follow {{FRAMEWORK}} and {{LANGUAGE}} best practices
+- Run linting before committing: `{{LINT_COMMAND}}`
+- Format code consistently: `{{FORMAT_COMMAND}}`
+
+## SRP and reuse-first principle
+
+- **Before implementing new functionality, review existing patterns** in `{{COMPOSABLES_PATH}}`, `{{UTILS_PATH}}`, and `{{HELPERS_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 codebase.
+- When in doubt, extend the existing pattern and keep consumers (components, controllers, handlers) thin.

package/src/repo/.claude/rules-snippets/component-structure.md

@@ -0,0 +1,8 @@
+# Component Structure
+
+- {{COMPONENT_STRUCTURE_RULE}}
+- Follow the {{COMPONENT_PATTERN}} pattern for all components.
+- Use clear and descriptive naming for props, events, and methods.
+- Keep logic within components focused and manageable.
+- Add code comments for complex logic or non-obvious implementations.
+- Use bracketed identifiers for logs: `[ComponentName]: message`.

package/src/repo/.claude/rules-snippets/core-libraries.md

@@ -0,0 +1,6 @@
+# Core Libraries
+
+- Use {{UTILITY_LIBRARY}} for common utilities.
+- Use {{STATE_MANAGEMENT}} for state management.
+- Use {{STYLING}} for styling; prefer utility classes over custom CSS.
+- Use {{UI_LIBRARY}} for UI components; check existing components before creating new ones.

package/src/repo/.claude/rules-snippets/deployment.md

@@ -0,0 +1,38 @@
+# Deployment
+
+## Target Platform
+
+- **Platform:** {{DEPLOY_PLATFORM}}
+- **Environment:** {{ENVIRONMENT}}
+
+## Deploy Commands
+
+```bash
+# Deploy to {{DEPLOY_PLATFORM}}
+{{DEPLOY_COMMAND}}
+
+# Build for production
+{{BUILD_COMMAND}}
+```
+
+## Environment Variables
+
+| Variable        | Description        | Required |
+| --------------- | ------------------ | -------- |
+| `{{ENV_VAR_1}}` | {{ENV_VAR_1_DESC}} | Yes      |
+| `{{ENV_VAR_2}}` | {{ENV_VAR_2_DESC}} | No       |
+
+## CI/CD
+
+```yaml
+# .github/workflows/deploy.yml (or equivalent)
+{ { CI_WORKFLOW_EXAMPLE } }
+```
+
+## Pre-Deployment Checklist
+
+- [ ] All tests pass
+- [ ] Linting passes
+- [ ] Build completes without errors
+- [ ] Environment variables configured
+- [ ] Database migrations applied (if applicable)