nitm-ai-dev-toolkit 3.0.15

package/src/repo/.claude/prompt-snippets/implement-feature.md

@@ -0,0 +1,124 @@
+# Implement Feature
+
+Implement a feature by completing tasks sequentially with proper tracking.
+
+## Usage
+
+```
+/implement-feature {{ISSUE_KEY}}-123
+/implement-feature docs/features/{{FEATURE_NAME}}/tasks.md
+```
+
+## Orchestrator Checkpoint
+
+> **🛑 Before starting**: This command involves planning, implementation, testing, and review.
+> Use the **orchestrator-first** flow. Delegate to the **Feature Builder** coordinator or use
+> the `subagent-driven-development` skill to dispatch a fresh subagent per task.
+> See `.claude/rules-snippets/subagent-workflow.md` for full patterns.
+
+## Process
+
+> **📋 Standards**: Follow [Coding Standards](../rules-snippets/coding-standards.md), [Testing](../rules-snippets/testing.md), and [Documentation](../rules-snippets/documentation.md).
+
+1. **Load Feature Context**:
+   - Read specification from `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Read implementation plan from `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md`
+   - Read task list from `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/tasks.md`
+   - Review `AGENTS.md` for project patterns
+
+2. **Parallelization Analysis**:
+   - Scan task list for `[P]` markers and independent tasks
+   - Group tasks by domain (backend, frontend, docs, tests)
+   - Tasks that touch **different files with no shared state** → dispatch in parallel
+   - Tasks with dependencies or shared files → keep sequential
+   - Use `dispatching-parallel-agents` skill when 3+ independent tasks exist
+
+3. **Create Feature Branch**:
+
+   ```bash
+   git checkout -b feature/{{FEATURE_NAME}}
+   git pull origin {{DEFAULT_BRANCH}}
+   ```
+
+4. **Task Implementation** (sequential or parallel per analysis):
+
+   For tasks with dependencies, execute in order.
+   For `[P]` tasks with no shared state, **dispatch parallel subagents** — one per task domain:
+
+   For each task:
+
+   a. **Mark Task In Progress**
+
+   b. **Research & Understand**:
+   - Search codebase for similar patterns
+   - Review referenced files
+   - Understand dependencies
+
+   c. **Implement (TDD required)**:
+   - Follow acceptance criteria exactly
+   - Use patterns from `AGENTS.md`
+   - **Write a failing test first** — one behavior per test, clear name, real code
+   - **Verify it fails** — watch it fail for the right reason (feature missing, not error)
+   - **Write minimal code to pass** — simplest implementation, no over-engineering
+   - **Verify it passes** — all tests green, no regressions
+   - **Refactor** — clean up only after green (remove duplication, improve names)
+   - Ensure type safety
+   - See `test-driven-development/SKILL.md` for the full cycle
+
+   d. **Validate**:
+   - Run type checking: `{{PACKAGE_MANAGER}} run check-types`
+   - Run linter: `{{PACKAGE_MANAGER}} run lint`
+   - Run tests: `{{PACKAGE_MANAGER}} run test`
+   - Build: `{{PACKAGE_MANAGER}} run build`
+
+   e. **Update Documentation**:
+   - Ensure `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md` reflects final implementation
+   - Update `plan.md` if implementation deviated from original plan
+   - Update `docs/api/` if any API surfaces changed
+   - Update `README.md` if setup steps, commands, or env vars changed
+   - Add entry to `CHANGELOG.md` under `[Unreleased]`
+   - See `.claude/rules-snippets/documentation.md` for full pre-commit checklist
+
+   f. **Commit Changes**:
+
+   ```bash
+   git commit -m "feat({{SCOPE}}): {{DESCRIPTION}}"
+   ```
+
+   f. **Mark Task Complete**
+
+5. **Post-Implementation Review**:
+   - Dispatch **Reviewer** agent on all changes before proceeding
+   - If reviewer requests changes, route back to the original domain specialist
+   - Use `verification-before-completion` skill for final quality gate
+
+6. **Create Pull Request**:
+
+   After all tasks complete:
+
+   a. **Final Validation**:
+   - All tests passing
+   - No type errors
+   - No linter errors
+   - Build successful
+
+   b. **Push and Create PR**:
+
+   ```bash
+   git push -u origin feature/{{FEATURE_NAME}}
+   ```
+
+   - Create PR targeting `{{DEFAULT_BRANCH}}`
+   - Include feature summary and testing notes
+
+7. **Report Status**:
+   - Completed tasks count
+   - PR URL
+   - Ready for code review
+
+## Guidelines
+
+- **No Placeholders**: Never implement "Coming Soon" or placeholder functionality
+- **Complete Features**: Each task should result in working functionality
+- **Test-Driven (mandatory)**: Write failing tests before implementation. Follow red-green-refactor. No production code without a failing test first.
+- **Atomic Commits**: One logical change per commit

package/src/repo/.claude/prompt-snippets/implement-fixes.md

@@ -0,0 +1,116 @@
+# Implement Fixes
+
+Implement bug fixes and corrections with proper validation and documentation.
+
+## Usage
+
+```
+/implement-fixes {{ISSUE_KEY}}-456
+/implement-fixes "Fix authentication timeout issue"
+```
+
+## Orchestrator Checkpoint
+
+> **🛑 For multiple independent fixes**: If fixing 2+ unrelated bugs, use `dispatching-parallel-agents`
+> to dispatch one subagent per bug (different root causes, different files = parallel-safe).
+> For a single focused fix, proceed directly — single-agent is appropriate.
+> See `.claude/rules-snippets/subagent-workflow.md` for patterns.
+
+## Workflow Modes
+
+1. **Issue-Based Fixes**: For tracked fixes requiring documentation
+2. **Direct Code Fixes**: For quick fixes without issue tracking
+
+## Process
+
+> **📋 Standards**: Follow [Coding Standards](../rules-snippets/coding-standards.md) and [Documentation](../rules-snippets/documentation.md).
+
+1. **Load Fix Context**:
+   - Retrieve issue details if applicable
+   - Understand the reported bug
+   - Identify affected code areas
+
+2. **Create Fix Branch**:
+   ```bash
+   git checkout {{DEFAULT_BRANCH}}
+   git pull origin {{DEFAULT_BRANCH}}
+   git checkout -b fix/{{FIX_DESCRIPTION}}
+   ```
+
+3. **Reproduce & Test (TDD required)**:
+   - Identify root cause
+   - **Write a failing test that reproduces the bug** — this proves you understand the issue
+   - **Verify it fails** — watch it fail for the right reason
+   - See `test-driven-development/SKILL.md` for the bug fix workflow
+
+4. **Implement Fix**:
+   - Write minimal code to make the failing test pass
+   - Fix only the reported issue
+   - Maintain backward compatibility
+   - **Verify all tests pass** — run the full suite, no regressions
+
+5. **Validate Fix**:
+   - Run type checking: `{{PACKAGE_MANAGER}} run check-types`
+   - Run tests: `{{PACKAGE_MANAGER}} run test`
+   - Build: `{{PACKAGE_MANAGER}} run build`
+   - Verify fix resolves the issue
+   - Check for regressions
+
+6. **Commit and Push**:
+   ```bash
+   git commit -m "fix({{SCOPE}}): {{FIX_DESCRIPTION}}"
+   git push -u origin fix/{{FIX_DESCRIPTION}}
+   ```
+
+7. **Create Pull Request**:
+   - Target: `{{DEFAULT_BRANCH}}`
+   - Include:
+     - Root cause explanation
+     - Fix approach description
+     - Testing performed
+     - Potential impacts
+
+8. **Report Status**:
+   - Bug fixed and root cause
+   - Validation completed
+   - PR ready for review
+
+   **Include a Fixes Applied table** summarizing every change:
+
+   ```markdown
+   ## Fixes Applied
+
+   | File | Issue | Fix |
+   | ---- | ----- | --- |
+   | `PostsCategory.php` | Missing `BelongsTo` import → fatal runtime error | Added `use Illuminate\Database\Eloquent\Relations\BelongsTo;` |
+   | `PostsCategory.php` | Timestamp constants with no DB columns | Replaced `CREATED_AT`/`UPDATED_AT` constants with `public $timestamps = false` |
+   | `Metadata.php` | `deleted_at` cast with no SoftDeletes/column | Removed spurious `'deleted_at' => 'datetime'` cast |
+   | `Metadata.php` | Two unreachable `break` after `return` | Removed the dead `break` statements |
+   | `Follow.php` | `end_date` missing from `$casts` | Added `'end_date' => 'datetime'` |
+   | `Follow.php` | `end_date` assigned twice in `beforeDelete()` | Removed the redundant first assignment |
+   | `LoginController.php` | `Request` used but not imported → fatal error | Added `use Illuminate\Http\Request;` |
+   | `RegisterController.php` | Unused `Str` import | Removed `use Illuminate\Support\Str;` |
+   ```
+
+   Every fix must appear in this table — one row per file+issue pair.
+
+## Fix Guidelines
+
+- **Minimal Scope**: Fix only the reported issue
+- **No Refactoring**: Avoid unrelated code changes
+- **Backward Compatible**: Don't break existing functionality
+- **Test First**: Write a failing test reproducing the bug before writing the fix — no exceptions
+- **Document**: Record the fix in changelog if significant
+
+## Documentation
+
+For significant fixes, document in `docs/fixes/` or `CHANGELOG.md`:
+
+```markdown
+## [{{VERSION}}] - {{DATE}}
+
+### Fixed
+- {{FIX_DESCRIPTION}} ({{ISSUE_KEY}})
+  - Root cause: {{ROOT_CAUSE}}
+  - Solution: {{SOLUTION}}
+```

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

@@ -0,0 +1,56 @@
+You are helping to implement features based on a task list or specification.
+
+## Orchestrator Checkpoint
+
+> **🛑 Before starting**: If the task list contains 2+ tasks across different domains or files,
+> use the **orchestrator-first** flow. Dispatch a fresh subagent per task using the
+> `subagent-driven-development` skill. For 3+ independent `[P]` tasks, use the
+> `dispatching-parallel-agents` skill to run them concurrently.
+> See `.claude/rules-snippets/subagent-workflow.md` for full patterns.
+
+## Your Task
+
+1. **Load context**:
+
+   - Read the specification or task list provided
+   - Review `AGENTS.md` for coding patterns
+   - Check relevant documentation in `docs/`
+
+2. **Analyze implementation requirements**:
+
+   - Identify files to create or modify
+   - Understand dependencies between tasks
+   - Note testing requirements
+   - **Parallelization check**: Identify `[P]` tasks and group independent work by domain
+   - Tasks touching different files with no shared state → dispatch in parallel
+
+3. **Execute implementation**:
+
+   - For sequential tasks: implement in dependency order
+   - For parallel `[P]` tasks: dispatch domain specialist subagents concurrently
+   - **Follow TDD**: Write failing tests before implementation (red-green-refactor). See `test-driven-development/SKILL.md`.
+   - Follow project coding standards
+   - Add appropriate comments and documentation
+
+4. **Review gate**:
+   - Dispatch **Reviewer** agent after implementation, before marking work complete
+   - Use `verification-before-completion` skill for final quality check
+
+5. **Validate implementation**:
+
+   - Run linting: `{{PACKAGE_MANAGER}} run lint`
+   - Run tests: `{{PACKAGE_MANAGER}} run test`
+   - Build project: `{{PACKAGE_MANAGER}} run build`
+
+6. **Track progress**:
+   - Mark completed tasks
+   - Report any blockers or issues
+   - Summarize changes made
+
+## Guidelines
+
+- Follow patterns from `AGENTS.md`
+- Keep changes focused and atomic
+- Write tests for new functionality
+- Update documentation as needed
+- Use conventional commit messages

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

@@ -0,0 +1,94 @@
+# Plan Feature Implementation
+
+Plan how to implement the specified feature. This is the second step in the development lifecycle.
+
+## Usage
+
+```
+/plan {{ISSUE_KEY}}-123
+/plan docs/features/user-authentication/spec.md
+```
+
+## Orchestrator Checkpoint
+
+> **🛑 Before starting**: For complex features spanning multiple domains (backend + frontend + API + docs),
+> dispatch **Researcher** subagents in parallel to analyze each domain simultaneously.
+> Use the `writing-plans` skill for structured plan creation.
+> See `.claude/rules-snippets/subagent-workflow.md` for full patterns.
+
+## Process
+
+> **📋 Standards**: Reference [Patterns](../rules-snippets/patterns.md) for architecture patterns.
+
+1. **Load Feature Context**:
+   - Read specification from `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Review `AGENTS.md` for architecture patterns
+   - Check `docs/constitution.md` for project principles
+
+2. **Analyze Requirements**:
+   - Functional requirements
+   - Non-functional requirements
+   - Dependencies on existing code
+   - External service integrations
+
+3. **Generate Implementation Plan**:
+
+   Create `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md` with:
+
+   - **Architecture Overview**: Component structure, data flow
+   - **Tech Stack**: Libraries and frameworks to use
+   - **File Structure**: Exact paths following project conventions
+   - **API Design**: Input/output schemas (if applicable)
+   - **Database Changes**: Schema modifications (if needed)
+   - **Security Considerations**: Auth, validation, data protection
+   - **Testing Strategy**: Unit, integration, E2E approach
+   - **Integration Points**: Dependencies on other features
+   - **Parallelization Map**: Identify independent tasks that can be dispatched to parallel subagents during implementation (mark with `[P]`)
+
+4. **Generate Additional Artifacts** (if needed, place in the same feature folder):
+   - `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/research.md` - Technical research
+   - `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/data-model.md` - Data model details
+   - `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/api-contract.md` - API specifications
+
+5. **Report Completion**:
+   - Plan file path
+   - Additional artifacts created
+   - Ready for `/tasks` command
+
+## Plan Template
+
+```markdown
+# Implementation Plan: {{FEATURE_NAME}}
+
+## Overview
+[Feature description and goals]
+
+## Architecture
+[Component structure and relationships]
+
+## Tech Stack
+- {{FRAMEWORK}}: [usage]
+- {{DATABASE}}: [usage]
+
+## File Structure
+- `{{SRC_DIR}}/{{FEATURE_NAME}}/`
+  - `index.{{FILE_EXTENSION}}` - Entry point
+  - `types.{{FILE_EXTENSION}}` - Type definitions
+
+## API Design
+[Endpoints, inputs, outputs]
+
+## Database Changes
+[Schema modifications]
+
+## Testing Strategy
+- Unit tests for [components]
+- Integration tests for [flows]
+- E2E tests for [scenarios]
+
+## Security
+[Authentication, authorization, validation]
+
+## Open Questions
+- [ ] Question 1
+```

package/src/repo/.claude/prompt-snippets/playwright-test.md

@@ -0,0 +1,58 @@
+# Playwright E2E Testing
+
+Validate scenarios using Playwright for end-to-end testing.
+
+## Usage
+
+```
+/playwright-test "User can log in and see dashboard"
+/playwright-test {{TEST_DIR}}/auth.spec.ts
+```
+
+## Process
+
+1. **Check for Existing Test**:
+
+   - Look in `{{TEST_DIR}}/` for matching scenario
+   - If found, run the existing test
+
+2. **Create New Test** (if needed):
+
+   - Create test file in `{{TEST_DIR}}/`
+   - Follow project testing conventions
+   - Include proper setup and teardown
+
+3. **Run Test**:
+
+   ```bash
+   {{PACKAGE_MANAGER}} run test:e2e
+   # or
+   npx -y playwright test <test-file>
+   ```
+
+4. **Report Results**:
+   - Summarize test outcomes
+   - Report any failures with details
+   - Suggest fixes for failing tests
+
+## Test Template
+
+```typescript
+import { test, expect } from "@playwright/test";
+
+test.describe("{{FEATURE_NAME}}", () => {
+	test("should {{TEST_DESCRIPTION}}", async ({ page }) => {
+		await page.goto("{{APP_URL}}");
+
+		// Test steps here
+
+		await expect(page).toHaveURL(/expected-path/);
+	});
+});
+```
+
+## Configuration
+
+- Test directory: `{{TEST_DIR}}/`
+- Base URL: `{{APP_URL}}`
+- Run command: `{{PACKAGE_MANAGER}} run test:e2e`

package/src/repo/.claude/prompt-snippets/ponytail-audit.md

@@ -0,0 +1,5 @@
+---
+description: Audit the whole repo for over-engineering, what can be deleted
+---
+
+Audit the entire repository for over-engineering only, not correctness. Scan the whole tree, not a diff. One line per finding, ranked biggest cut first: <tag> <what to cut>. <replacement>. [path]. Tags: delete (dead code/speculative feature), stdlib (reinvented standard library), native (dependency doing what the platform does), yagni (abstraction with one implementation), shrink (same logic, fewer lines). End with the net lines and dependencies removable. If nothing to cut: 'Lean already. Ship.'

package/src/repo/.claude/prompt-snippets/ponytail-debt.md

@@ -0,0 +1,5 @@
+---
+description: "Harvest ponytail: comments into a tracked debt ledger"
+---
+
+Harvest every `ponytail:` comment in this repository into a debt ledger so deferrals do not rot into 'later means never'. Grep the whole tree for comment markers (grep -rnE '(#|//) ?ponytail:' ., skipping node_modules/.git/build output). One row per marker, grouped by file: <file>:<line>, <what was simplified>. ceiling: <the limit named in the comment>. upgrade: <the trigger to revisit>. Tag any marker that names no upgrade path or trigger as no-trigger, those rot silently. End with the count of markers and how many lack a trigger. If none: 'No ponytail: debt. Clean ledger.' Report only, change nothing.

package/src/repo/.claude/prompt-snippets/ponytail-gain.md

@@ -0,0 +1,5 @@
+---
+description: Show ponytail's measured impact scoreboard (less code, cost, time)
+---
+
+Show the ponytail gain scoreboard. One shot, change nothing: do not switch mode, write flag files, or persist anything. Render the published benchmark medians (5 everyday tasks; models Haiku, Sonnet, Opus; source DietrichGebert/ponytail benchmarks and README on GitHub) as plain ASCII bars: Lines of code, no-skill 100% vs ponytail 6-20% (down 80-94%); Cost, no-skill 100% vs ponytail 23-53% (down 47-77%); Speed, ponytail 3-6x faster. The bar length shows the measured range, the label carries the exact figure. These are benchmark medians, not this repo. NEVER print a per-repo savings number: the unbuilt version was never written, so there is no real baseline to subtract from in a live repo. For real per-repo figures, point to /ponytail-debt (the counted shortcut ledger) and /ponytail-audit (what is still cuttable). Report only.

package/src/repo/.claude/prompt-snippets/ponytail-help.md

@@ -0,0 +1,5 @@
+---
+description: Quick reference for ponytail levels, skills, and commands
+---
+
+Show the ponytail quick reference. One shot, change nothing: do not switch mode, write flag files, or persist anything. Levels: /ponytail lite (build what's asked, name the lazier alternative in one line), /ponytail (full, the default ladder: YAGNI then stdlib then native then one line then minimum), /ponytail ultra (deletion before addition, challenges the requirement before building). Commands: /ponytail-review (over-engineering review of the current changes), /ponytail-audit (whole-repo over-engineering audit), /ponytail-debt (harvest ponytail: comments into a tracked ledger), /ponytail-gain (measured-impact scoreboard), /ponytail-help (this card). Deactivate with 'stop ponytail', 'normal mode', or /ponytail off; resume anytime with /ponytail. Default mode is full; change it with the PONYTAIL_DEFAULT_MODE environment variable (off|lite|full|ultra) or a config file at ~/.config/ponytail/config.json (Windows: %APPDATA%\ponytail\config.json) with {"defaultMode": "lite"}. Resolution order: env var, then config file, then full.

package/src/repo/.claude/prompt-snippets/ponytail-review.md

@@ -0,0 +1,5 @@
+---
+description: Review changes for over-engineering, what can be deleted
+---
+
+Review the current code changes for over-engineering only, not correctness. One line per finding: L<line>: <tag> <what to cut>. <replacement>. Tags: delete (dead code/speculative feature), stdlib (reinvented standard library), native (dependency doing what the platform does), yagni (abstraction with one implementation), shrink (same logic, fewer lines). End with the net lines removable. If nothing to cut: 'Lean already. Ship.'

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

@@ -0,0 +1,5 @@
+---
+description: Switch ponytail intensity level (lite/full/ultra/off)
+---
+
+Switch to ponytail $ARGUMENTS mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark intentional simplifications with a ponytail: comment.