nitm-ai-dev-toolkit 3.0.15

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

@@ -0,0 +1,119 @@
+# Implement Feature
+
+Implement a feature by completing tasks sequentially with proper tracking.
+
+## Usage
+
+```
+
+/implement-feature {{ISSUE_KEY}}-123
+/implement-feature apps/{{APP_NAME}}/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
+
+1. **Load Feature Context**:
+   - Read specification from `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Read implementation plan from `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md`
+   - Read task list from `apps/{{APP_NAME}}/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. **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/monorepo/.claude/prompt-snippets/implement-fixes.md

@@ -0,0 +1,122 @@
+# 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
+
+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/monorepo/.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/monorepo/.claude/prompt-snippets/plan.md

@@ -0,0 +1,67 @@
+You are helping to create an implementation plan for a feature or requirement.
+
+## 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.
+
+## Your Task
+
+1. **Load context**:
+
+   - Read `AGENTS.md` for project architecture and patterns
+   - Review `docs/constitution.md` for project principles (if exists)
+   - Read the feature spec from `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Check relevant existing code for patterns to follow
+
+2. **Analyze the requirement**:
+
+   - Identify functional requirements
+   - Identify non-functional requirements (performance, security, etc.)
+   - Note dependencies on existing code or external services
+   - List acceptance criteria
+
+3. **Create the implementation plan**:
+
+   - **Technical approach**: How will this be implemented?
+   - **File changes**: What files need to be created or modified?
+   - **Data model changes**: Any database or schema changes?
+   - **API changes**: Any endpoints to add or modify?
+   - **Dependencies**: External packages or services needed?
+   - **Testing strategy**: How will this be tested?
+   - **Parallelization map**: Identify which tasks are independent and can be dispatched to parallel subagents during implementation (mark with `[P]`)
+
+4. **Output the plan**:
+   - Determine the target app directory (e.g., `apps/{{APP_NAME}}/`)
+   - Create `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md` with the plan
+   - Include estimated complexity and effort
+   - List any open questions or decisions needed
+
+## Plan Template
+
+```markdown
+# Implementation Plan: {{FEATURE_NAME}}
+
+## Overview
+
+[Brief description of the feature]
+
+## Technical Approach
+
+[How this will be implemented]
+
+## File Changes
+
+- [ ] `path/to/file.{{FILE_EXTENSION}}` - Description of changes
+
+## Testing Strategy
+
+- Unit tests for...
+- Integration tests for...
+
+## Open Questions
+
+- [ ] Question 1
+```

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

@@ -0,0 +1,55 @@
+# 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/monorepo/.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/monorepo/.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/monorepo/.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/monorepo/.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/monorepo/.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/monorepo/.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.

package/src/monorepo/.claude/prompt-snippets/release-notes.md

@@ -0,0 +1,134 @@
+You are helping to generate professional release notes from git commits.
+
+## Your Task
+
+1. **Ask the user** which format they need:
+
+   - **Web** — Customer-facing changelog for a website, blog post, or announcement
+   - **Git Tag** — Concise summary for a git tag annotation or GitHub release
+   - **Documentation** — Detailed technical notes for RELEASE_NOTES.md or internal changelog
+
+2. **Ask for the scope** — entire monorepo, specific app, or specific package
+
+3. **Ask for the commit range** (date range, tag range, or number of commits)
+
+4. **Gather commit data** using terminal commands:
+
+   ```bash
+   # All commits in range
+   git log --oneline --since="[START_DATE]" --until="[END_DATE]"
+
+   # Scoped to a specific app/package
+   git log --oneline --since="[START_DATE]" -- apps/[APP_NAME]/
+   git log --oneline --since="[START_DATE]" -- packages/[PACKAGE_NAME]/
+
+   # Detailed info
+   git log --since="[START_DATE]" --format="%h|%s|%b|%an|%ad" --date=short
+   git diff --stat [START_REF]..[END_REF]
+   ```
+
+5. **Analyze commits**:
+
+   - Extract conventional commit types (feat, fix, perf, refactor, etc.)
+   - Identify scopes
+   - Group related commits together
+   - Determine user/developer impact
+   - Note which apps/packages are affected
+
+6. **Generate release notes** in the selected format:
+
+### Web Format
+
+```markdown
+# What's New in {{PROJECT_NAME}} [Version]
+
+**Released [Date]**
+
+[1-2 sentence overview for end users]
+
+## Highlights
+
+### [Feature Title]
+
+[2-3 sentences in plain language]
+
+## Improvements
+
+- [User-visible improvement]
+
+## Bug Fixes
+
+- Fixed an issue where [problem description]
+```
+
+- Write for non-technical users
+- No commit hashes, file paths, or code references
+- Focus on benefits and outcomes
+
+### Git Tag Format
+
+```markdown
+## [Version] - [Date]
+
+### Summary
+
+[1-2 sentence overview]
+
+### Key Changes
+
+- 🚀 [Major improvement]
+- ✨ [New feature]
+- 🐛 [Important fix]
+
+### Upgrade Notes
+
+[Only for breaking changes]
+```
+
+- Maximum 5 bullet points
+- No file details or commit hashes
+- Include upgrade notes only for breaking changes
+
+### Documentation Format
+
+```markdown
+# Release Notes - [Month Year]
+
+## Version: [Version] ([Date])
+
+### Summary
+
+[2-3 sentence overview]
+
+---
+
+## [Category with Emoji] ([Date])
+
+### [Feature/Fix Title]
+
+**Commit**: `[hash]` - `[message]`
+**Impact**: [Impact statement]
+
+#### Changes
+
+- [Change with file reference]
+
+#### Benefits
+
+- ✅ [Benefit]
+```
+
+- Include commit hashes and file paths
+- Use emoji category headers (🚀 🎨 🔒 🐛 ✨ 🔧 📚)
+- Full technical detail
+
+7. **Present the release notes** and ask if adjustments are needed
+
+## Guidelines
+
+- Use conventional commit types to categorize changes
+- Group related commits that address the same feature/fix
+- Reference {{ISSUE_TRACKER}} tickets when applicable
+- Never include sensitive information (credentials, internal URLs)
+- Verify version number and date accuracy
+- For scoped releases, filter commits to only those affecting the target app/package