nitm-ai-dev-toolkit 3.0.15

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

@@ -0,0 +1,204 @@
+# Generate Release Notes
+
+Generate professional release notes from git commits. Supports three output formats: **web** (customer-facing), **git tag** (concise), and **documentation** (detailed technical).
+
+## Usage
+
+```
+/release-notes web
+/release-notes tag
+/release-notes docs
+```
+
+## Process
+
+1. **Determine Output Format**:
+
+   Ask the user which format they need:
+
+   | Format            | Purpose                                             | Audience                            | Length         |
+   | ----------------- | --------------------------------------------------- | ----------------------------------- | -------------- |
+   | **Web**           | Website changelog, blog post, customer announcement | End users, customers                | 200-500 words  |
+   | **Git Tag**       | Git tag annotation, GitHub/GitLab release           | Developers, external consumers      | 100-300 words  |
+   | **Documentation** | RELEASE_NOTES.md, comprehensive changelog           | Internal developers, technical team | 500-2000 words |
+
+2. **Gather Commit Data**:
+
+   Run these commands to collect release information:
+
+   ```bash
+   # Get commits in range
+   git log --oneline --since="[START_DATE]" --until="[END_DATE]"
+
+   # Get detailed commit info
+   git log --since="[START_DATE]" --format="%h|%s|%b|%an|%ad" --date=short
+
+   # Get changed files
+   git diff --stat [START_REF]..[END_REF]
+
+   # Get commits by conventional type
+   git log --oneline --grep="^feat" --since="[START_DATE]"
+   git log --oneline --grep="^fix" --since="[START_DATE]"
+   git log --oneline --grep="^perf" --since="[START_DATE]"
+   ```
+
+3. **Analyze Commits**:
+
+   - Extract conventional commit type (feat, fix, perf, refactor, etc.)
+   - Identify scope (auth, frontend, admin, etc.)
+   - Group related commits together
+   - Determine user/developer impact
+
+4. **Generate Release Notes** using the appropriate template below.
+
+---
+
+## Templates
+
+### Web Format (Customer-Facing)
+
+For website changelogs, blog posts, and customer-facing announcements.
+
+```markdown
+# What's New in {{PROJECT_NAME}} [Version]
+
+**Released [Date]**
+
+[1-2 sentence overview written for end users, focusing on value delivered]
+
+## Highlights
+
+### [Feature/Improvement Title]
+
+[2-3 sentences explaining the change in plain language. Focus on what users can now do, not how it was implemented.]
+
+### [Feature/Improvement Title]
+
+[2-3 sentences explaining the change in plain language.]
+
+## Improvements
+
+- [User-visible improvement in plain language]
+- [User-visible improvement in plain language]
+
+## Bug Fixes
+
+- Fixed an issue where [user-visible problem description]
+- Resolved [user-visible problem description]
+
+---
+
+_For detailed technical notes, see [RELEASE_NOTES.md](RELEASE_NOTES.md)._
+```
+
+**Web format guidelines:**
+
+- Write for non-technical users where possible
+- Focus on benefits and outcomes, not implementation details
+- No commit hashes, file paths, or code references
+- Use plain language — avoid jargon
+- Include screenshots or links to demos when applicable
+- Keep each item to 1-3 sentences
+
+### Git Tag Format (Concise)
+
+For git tag annotations, GitHub/GitLab releases, and quick announcements.
+
+```markdown
+## [Version Number] - [Date]
+
+### Summary
+
+[1-2 sentence overview]
+
+### Key Changes
+
+- 🚀 [Major improvement 1]
+- ✨ [New feature]
+- 🐛 [Important fix]
+- 🔧 [Notable maintenance item]
+
+### Upgrade Notes
+
+[Only if breaking changes or required actions exist]
+```
+
+**Git tag format guidelines:**
+
+- Maximum 5 bullet points
+- Focus on user-facing changes only
+- No technical file details or commit hashes
+- Emoji categories for quick scanning
+- Include upgrade/migration notes only for breaking changes
+
+### Documentation Format (Detailed)
+
+For RELEASE_NOTES.md, comprehensive changelogs, and internal documentation.
+
+```markdown
+# Release Notes - [Month Year]
+
+## Version: [Version Number] ([Date])
+
+### Summary
+
+[2-3 sentence overview of the release focus and key improvements]
+
+---
+
+## [Category with Emoji] ([Date])
+
+### [Feature/Fix Title]
+
+**Commit**: `[hash]` - `[commit message]`
+
+**Impact**: [Business/technical impact statement]
+
+#### Changes
+
+- [Specific change with file reference]
+- [Specific change with file reference]
+
+#### Benefits
+
+- ✅ [User/developer benefit]
+- ✅ [User/developer benefit]
+```
+
+**Documentation format guidelines:**
+
+- Use emoji category headers:
+  - 🚀 Performance & Optimization
+  - 🎨 Frontend & UI
+  - 🔒 Security & Authentication
+  - 🐛 Bug Fixes
+  - ✨ New Features
+  - 🔧 Configuration & Deployment
+  - 📚 Documentation
+- Include commit hash and message for each change
+- List modified files with context
+- Explain technical changes clearly
+- Highlight benefits with ✅ checkmarks
+
+---
+
+## General Guidelines
+
+1. **Categories**: Use conventional commit types to categorize changes
+2. **Tone**: Professional, clear, and appropriate for the target audience
+3. **Format**: Use proper markdown with headers, bullets, code blocks
+4. **Grouping**: Combine commits that address the same feature/fix
+5. **Context**: Reference {{ISSUE_TRACKER}} tickets when applicable
+
+## Quality Checklist
+
+Before finalizing release notes:
+
+- [ ] Correct format selected for the audience
+- [ ] All significant commits categorized appropriately
+- [ ] Impact statements are clear and concise
+- [ ] No sensitive information included (credentials, internal URLs)
+- [ ] Version number and date are accurate
+- [ ] Markdown formatting renders correctly
+- [ ] Grammar and spelling checked
+- [ ] Breaking changes clearly called out (if any)

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

@@ -0,0 +1,156 @@
+# Review Pull Request
+
+Conduct comprehensive code review for pull requests with structured fix tracking.
+
+> **📋 Builds on [review.md](review.md)** — Uses the same review categories and report format. This prompt adds PR-specific workflows: comment retrieval, fix tracking, and thread resolution.
+
+## Usage
+
+```bash
+/review-pr 42
+/review-pr <PR-or-MR-url>
+```
+
+## Orchestrator Checkpoint
+
+> **🛑 For large PRs** (10+ files or 3+ domains): Dispatch specialist reviewers in parallel:
+>
+> - **Backend Architect** → architecture, API design, database
+> - **Frontend Developer** → UI, components, accessibility
+> - **Reviewer** → code quality, SOLID, DRY
+> - **Documenter** → documentation completeness
+>   Each reviewer returns findings independently; the orchestrator merges results.
+>   See `.claude/rules-snippets/subagent-workflow.md` for patterns.
+
+## Process
+
+1. **Load PR Context**:
+   - Get PR details (title, description, changed files)
+   - Extract issue reference if available
+   - Get PR diff and file changes
+   - **CRITICAL — Comment Retrieval Strategy**:
+     1. **Use issue tracker MCP tools** (preferred) to retrieve ALL comments:
+        - Get PR/MR details and review comments
+        - Get the active PR/MR context
+        - Fetch **top-level conversation comments** (often missed!)
+        - Fetch **inline review comments** (comments on specific lines of code)
+        - Fetch **pending review comments** (from in-progress reviews)
+     2. **If MCP tools fail or unavailable**, fall back to the CLI — see the `issue-tracker` skill (`.agents/skills/issue-tracker/SKILL.md`) for your tracker's API commands.
+     3. **Always check BOTH** top-level conversation comments AND inline review comments — agents commonly miss top-level comments by only checking inline review comments
+   - Identify which comments are **unresolved/open** vs already resolved
+
+2. **Review PR Comments from ALL Reviewers**:
+   - **CRITICAL**: Use `manage_todo_list` tool to create comprehensive todo list
+   - Extract and categorize ALL **unresolved/open** PR comments by severity:
+     - Critical (blocking issues)
+     - High Priority (should be fixed before merge)
+     - Medium Priority (important improvements)
+   - For each comment:
+     - Summarize the reviewer's feedback
+     - Assess confidence in the resolution — can you fix this with high confidence?
+     - **If the comment is unclear, ambiguous, or you cannot determine the right fix**:
+       - **STOP and ask the user for clarification** before proceeding
+       - Present 2-3 recommended solutions with trade-offs for each
+       - Explain what you understand and what is unclear
+       - Do NOT guess at a fix when the intent is ambiguous
+     - If confident, propose a resolution plan with 99.9% confidence level
+     - Add to todo list with appropriate status
+
+3. **Verify Requirements**:
+   - Read specification if linked
+   - Check task completion against acceptance criteria
+   - Verify all requirements met
+
+4. **Apply Review Checklist**:
+   - Apply all review categories from [review.md](review.md) (Architecture & Patterns, Functionality, Code Quality, Error Handling, Security, Performance, Testing, Documentation)
+   - Add all identified issues to todo list
+
+5. **Review Decision**:
+   - **✅ Approve**: All criteria met, ready for merge
+   - **❌ Request Changes**: Blocking issues found
+   - **💬 Comment**: Non-blocking suggestions only
+
+6. **Provide Actionable Improvements**:
+   - For each suggestion:
+     - Provide clear explanation of why improvement is needed
+     - Include specific code examples or patterns
+     - Reference best practices or conventions
+
+7. **Output Format**:
+
+   Use the standard report format from [review.md](review.md), with these PR-specific additions:
+
+   ```markdown
+   ## Review Summary
+
+   **Decision**: [✅ Approve | ❌ Request Changes | 💬 Comment]
+
+   [Concise 2-3 sentence summary of review findings]
+
+   ## PR Comments & Resolution Plan
+
+   | Severity | Reviewer | Comment   | Resolution Plan | Confidence |
+   | -------- | -------- | --------- | --------------- | ---------- |
+   | Critical | @user    | [Summary] | [Plan]          | 99.9%      |
+   | High     | @user    | [Summary] | [Plan]          | 99.9%      |
+   | Medium   | @user    | [Summary] | [Plan]          | 99.9%      |
+
+   ## Code Quality Findings
+
+   [Use the standard categories from review.md: Architecture & Patterns, Functionality, Code Quality, Error Handling, Security, Performance, Testing, Documentation]
+
+   ## Action Items Checklist
+
+   - [ ] Fix: [Critical issue 1]
+   - [ ] Fix: [Critical issue 2]
+   - [ ] Address: [High priority comment]
+   - [ ] Improve: [Medium priority suggestion]
+
+   ## Fixes Applied
+
+   _After fixes are implemented, populate this table with every change made:_
+
+   | File              | Issue                           | Fix                              |
+   | ----------------- | ------------------------------- | -------------------------------- |
+   | `ExampleFile.php` | Missing import → fatal error    | Added `use Namespace\ClassName;` |
+   | `ExampleFile.php` | Unreachable code after `return` | Removed dead `break` statements  |
+   | `AnotherFile.php` | Field missing from `$casts`     | Added `'field' => 'datetime'`    |
+
+   Every fix must appear in this table — one row per file+issue pair.
+   ```
+
+8. **Report Review Status**:
+   - Review decision with clear justification
+   - Summary of key findings by severity
+   - Inline comments for specific code locations
+   - Todo list status showing progress
+   - Next steps if changes requested
+
+9. **Confirm Execution Plan**
+   - If there are changes, ask the user to confirm the execution plan with a (Y/n)
+
+10. **If the plan is confirmed, proceed with fix Tracking with Internal Todo List**:
+    - **Before Starting Work**:
+      - Use `manage_todo_list` to create comprehensive list of ALL fixes:
+        - PR comments requiring fixes (by severity)
+        - Code quality issues
+        - Potential bugs or security concerns
+        - Performance improvements
+    - **During Implementation**:
+      - Mark ONE todo as `in-progress` before starting
+      - Complete the specific fix
+      - Test the fix (if applicable)
+      - Mark todo as `completed` IMMEDIATELY after finishing
+      - Move to next todo and repeat
+    - **Never batch completions** - mark each done immediately
+
+11. **Resolve PR Comment Threads After Fixing**:
+    - **CRITICAL**: After each comment is addressed and the fix is pushed:
+      1. **Resolve the comment thread** via your issue tracker's tools:
+         - Use the issue tracker MCP tools to submit a review resolving threads
+         - Or reply to each resolved thread with a brief summary of what was fixed
+         - Or use the CLI — see the `issue-tracker` skill for your tracker's API commands
+      2. **If a comment could NOT be addressed**:
+         - Reply to the thread explaining why (e.g., out of scope, needs more context, trade-off decision)
+         - Ask the user whether to leave it open or resolve with an explanation
+      3. **Verify resolution** — after pushing, confirm the comment threads show as resolved in the PR

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

@@ -0,0 +1,35 @@
+# Review Staged Files
+
+Review the current staged files before committing.
+
+> **📋 Builds on [review.md](review.md)** — Uses the same review categories and report format. This prompt adds staged-files-specific context loading and a pre-commit focus.
+
+## Usage
+
+```
+/review-staged
+```
+
+## Process
+
+1. **Load Staged Context**:
+   - Run `git diff --cached` to get all staged changes
+   - Run `git diff --cached --stat` for a summary of affected files
+   - Load `AGENTS.md` for project patterns
+   - Identify the scope of changes (feature, fix, refactor, etc.)
+
+2. **Apply Review Checklist**:
+   - Apply all review categories from [review.md](review.md) (Architecture & Patterns, Functionality, Code Quality, Error Handling, Security, Performance, Testing, Documentation)
+   - Focus on issues that should block this specific commit
+
+3. **Pre-Commit Checks**:
+   - [ ] Documentation updated (see `.claude/rules-snippets/documentation.md`)
+   - [ ] No debug code, console logs, or TODO comments left in
+   - [ ] No secrets, credentials, or sensitive data
+   - [ ] Changes match the commit message scope
+
+4. **Output Format**:
+
+   Use the standard report format from [review.md](review.md).
+
+   If issues are found, recommend either fixing before commit or creating a follow-up task.

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

@@ -0,0 +1,139 @@
+# Code Review
+
+Comprehensive code review checklist for quality, security, and maintainability.
+
+> **📋 This is the base review prompt.** [/review-pr](review-pr.md) and [/review-staged](review-staged.md) build on this with scenario-specific guidance. All three share the same review categories and report format defined here.
+
+## Usage
+
+```
+/review {{SRC_DIR}}/feature/component.{{FILE_EXTENSION}}
+/review feature-name
+/review
+```
+
+## Orchestrator Checkpoint
+
+> **🛑 For large PRs** (10+ files or 3+ domains): Dispatch specialist reviewers in parallel:
+>
+> - **Backend Architect** → architecture, API design, database
+> - **Frontend Developer** → UI, components, accessibility
+> - **Reviewer** → code quality, SOLID, DRY
+> - **Documenter** → documentation completeness
+>   Each reviewer returns findings independently; the orchestrator merges results.
+>   See `.claude/rules-snippets/subagent-workflow.md` for patterns.
+
+> **🛑 Subagent isolation**: For independent quality reviews (especially after implementation), dispatch the Reviewer as a fresh subagent with NO shared conversation context. Shared context creates anchoring bias and causes reviewers to rubber-stamp work they watched being built.
+
+## Process
+
+> **📋 Standards**: Review against [Coding Standards](../rules-snippets/coding-standards.md) and [Testing](../rules-snippets/testing.md).
+
+1. **Determine Context**:
+   - If file path provided, review that file
+   - If feature name provided, review related files
+   - If no argument, use chat history for context
+
+2. **Load Context**:
+   - Retrieve file contents and changes
+   - Load `AGENTS.md` for project patterns
+   - Check linked issues if available
+   - **Git context** (when reviewing changes): note the base SHA (before changes) and head SHA (after changes) to scope the diff
+
+3. **Conduct Review**:
+   Apply review checklist and report findings
+
+## Review Categories
+
+### Architecture & Patterns
+
+- [ ] Controllers/handlers are thin (business logic in services/models)
+- [ ] Proper separation of concerns
+- [ ] Appropriate use of design patterns
+- [ ] Follows project architecture from `AGENTS.md`
+
+### Functionality
+
+- [ ] Code does what it's supposed to do
+- [ ] Edge cases are handled
+- [ ] No obvious bugs or logic errors
+
+### Code Quality
+
+- [ ] Code is readable and well-structured
+- [ ] Functions are small and focused
+- [ ] Variable names are descriptive
+- [ ] No code duplication
+- [ ] Follows project conventions from `AGENTS.md`
+
+### Error Handling
+
+- [ ] Errors are handled gracefully
+- [ ] User-facing errors are friendly
+- [ ] Errors are logged appropriately
+
+### Security
+
+- [ ] No security vulnerabilities
+- [ ] Input validation is present
+- [ ] Authorization checks in place
+- [ ] Sensitive data handled properly
+- [ ] No hardcoded secrets or credentials
+
+### Performance
+
+- [ ] No obvious performance issues
+- [ ] Database queries optimized (no N+1)
+- [ ] Appropriate caching where needed
+- [ ] No unnecessary loops or operations
+
+### Testing
+
+- [ ] Tests verify actual behavior (not mocked behavior)
+- [ ] Edge cases covered
+- [ ] Tests are readable and maintainable
+- [ ] No brittle or over-specified tests
+
+### Documentation
+
+- [ ] Complex logic is commented
+- [ ] Public APIs are documented
+- [ ] README updated if needed
+
+## Report Format
+
+```markdown
+## Code Review: [file/feature]
+
+### Strengths
+
+[What was done well — call out good patterns, clean code, solid testing]
+
+### Findings
+
+#### Critical 🔴
+
+- [Must fix before merge — security issues, data loss risks, broken functionality]
+
+#### Important 🟡
+
+- [Should address — performance problems, maintainability concerns, missing error handling]
+
+#### Minor 🟢
+
+- [Optional improvements — style inconsistencies, naming suggestions, documentation gaps]
+
+### Assessment
+
+[✅ Approved | ⚠️ Approved with suggestions | ❌ Changes required]
+```
+
+## Review Loop
+
+After findings are reported:
+
+1. **Critical issues**: MUST be fixed before proceeding. Re-review after fixes.
+2. **Important issues**: SHOULD be fixed. Reviewer re-reviews after fixes.
+3. **Minor issues**: Can be deferred or fixed at implementer's discretion.
+
+If fixes are applied, verify them before marking the review complete.

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

@@ -0,0 +1,84 @@
+# Create Feature Specification
+
+Start a new feature by creating a specification. This is the first step in the development lifecycle.
+
+## Usage
+
+```
+/specify Add user authentication with OAuth2 support
+/specify Create a REST API for product catalog
+```
+
+## Process
+
+> **📋 Context**: Reference [Project Context](../rules-snippets/project-context.md) for architecture and patterns.
+
+1. **Parse Feature Description**:
+   - Extract core functionality
+   - Identify user stories
+   - Note constraints and requirements
+
+2. **Determine Context**:
+   - Check `AGENTS.md` for project architecture
+   - Review existing features in `docs/features/`
+   - Understand tech stack and patterns
+
+3. **Create Feature Directory**:
+   ```
+   docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/
+   ```
+
+4. **Generate Specification**:
+
+   Create `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md` using template:
+
+   ```markdown
+   # Feature: {{FEATURE_NAME}}
+
+   ## Overview
+   [What this feature does and why it's needed]
+
+   ## User Stories
+   - As a [user type], I want [goal] so that [benefit]
+
+   ## Functional Requirements
+   1. [Requirement 1]
+   2. [Requirement 2]
+
+   ## Non-Functional Requirements
+   - Performance: [expectations]
+   - Security: [considerations]
+   - Scalability: [requirements]
+
+   ## Acceptance Criteria
+   - [ ] Criterion 1
+   - [ ] Criterion 2
+
+   ## Technical Constraints
+   - [Framework/library requirements]
+   - [Integration requirements]
+
+   ## Out of Scope
+   - [What this feature does NOT include]
+
+   ## Open Questions
+   - [ ] [Questions needing clarification]
+   ```
+
+5. **Create Git Branch** (optional):
+   ```bash
+   git checkout -b feature/{{FEATURE_NAME}}
+   ```
+
+6. **Report Completion**:
+   - Feature directory path
+   - Spec file path
+   - Branch name (if created)
+   - Ready for `/plan` command
+
+## Guidelines
+
+- Be specific and actionable
+- Mark ambiguities with `[NEEDS CLARIFICATION: question]`
+- Include acceptance criteria for testability
+- Reference existing patterns from `AGENTS.md`