nitm-ai-dev-toolkit 3.0.15

package/src/monorepo/.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/monorepo/.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/monorepo/.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/monorepo/.claude/prompt-snippets/specify.md

@@ -0,0 +1,51 @@
+You are helping to create a feature specification based on the user's description.
+
+## Your Task
+
+1. **Parse the feature description**:
+   - Extract the core functionality being requested
+   - Identify user stories or use cases
+   - Note any constraints or requirements mentioned
+
+2. **Load context**:
+   - Read `AGENTS.md` for project architecture
+   - Review existing features in `apps/*/docs/features/` for format consistency
+   - Check related code for context
+
+3. **Create the specification**:
+   - Determine the target app directory (e.g., `apps/{{APP_NAME}}/`)
+   - Create `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Use the template structure below
+   - Be specific and actionable
+
+4. **Output**:
+   - Confirm specification created
+   - Summarize key requirements
+   - Suggest next step: `/plan` to create implementation plan
+
+## Specification 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]
+
+## Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+
+## Out of Scope
+- [What this feature does NOT include]
+```

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

@@ -0,0 +1,108 @@
+You are helping to break down a feature into actionable tasks.
+
+## Your Task
+
+1. **Load context**:
+   - Read the specification in `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md`
+   - Read the plan in `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md` (if exists)
+   - Review `AGENTS.md` for project patterns
+
+2. **Break down into tasks** (aim for 3-7 total tasks):
+   - **Setup**: Dependencies, configuration, scaffolding (combine into 1 task)
+   - **Core**: Main implementation tasks (group by component/feature area)
+   - **Tests**: Unit and integration tests (1 task per component)
+   - **Polish**: Documentation, cleanup, optimization (combine into 1 task)
+
+3. **Task Consolidation Rules** (CRITICAL):
+   - **Group related work**: Combine tasks that touch the same files or feature area
+   - **Merge small tasks**: Tasks under 2 hours should be combined with related work
+   - **Limit total tasks**: Target 3-7 tasks total; never exceed 10 for any feature
+   - **Avoid over-granularity**: "Create model + migration + factory" = 1 task, not 3
+   - **Bundle by outcome**: Group by what gets delivered, not individual steps
+
+4. **Complexity-Based Task Sizing**:
+
+   | Complexity          | Task Count | Subtask Limit     |
+   | ------------------- | ---------- | ----------------- |
+   | Simple (< 4 hours)  | 2-3 tasks  | 0 subtasks        |
+   | Medium (4-16 hours) | 3-5 tasks  | 2-4 per task max  |
+   | Complex (16-40 hrs) | 5-8 tasks  | 3-6 per task max  |
+   | Large (40+ hours)   | 8-12 tasks | 5-10 per task max |
+
+5. **Task ordering rules**:
+   - Setup before implementation
+   - Tests before or alongside code (TDD)
+   - Core features before integrations
+   - Mark parallelizable tasks with [P]
+
+6. **Create task list**:
+   - Output to `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/tasks.md`
+   - Each task should be specific and actionable
+   - Include file paths where relevant
+
+## Task Template
+
+```markdown
+# Tasks: {{FEATURE_NAME}}
+
+**Complexity**: Simple | Medium | Complex
+**Estimated Total**: X hours
+**Task Count**: X tasks
+
+## T001: Setup & Configuration
+
+- Install dependencies and configure environment
+- Create file structure and scaffolding
+- **Files**: `package.json`, `{{CONFIG_DIR}}/*`
+
+## T002: Core Implementation - [Feature Area]
+
+- Implement [feature part] including models, services, and controllers
+- **Files**: `{{SRC_DIR}}/models/*`, `{{SRC_DIR}}/services/*`
+- **Subtasks** (only if complex):
+  - Model and database layer
+  - Business logic and services
+  - API/Controller layer
+
+## T003 [P]: Testing
+
+- Add unit and integration tests for all components
+- **Files**: `{{TEST_DIR}}/*`
+
+## T004: Polish & Documentation
+
+- Update documentation, error handling, and cleanup
+- **Files**: `README.md`, `docs/*`
+```
+
+## Anti-Patterns to Avoid
+
+❌ **Don't create separate tasks for**:
+
+- Each individual file in a feature
+- "Create X" then "Configure X" then "Test X" (combine them)
+- Minor changes that take < 30 minutes
+- Obvious steps like "commit code" or "run linter"
+
+✅ **Do combine into single tasks**:
+
+- All model/migration/factory work for an entity
+- Related API endpoints that share logic
+- All configuration and environment setup
+- Documentation updates across multiple files
+
+## Notes
+
+- [P] indicates tasks that can run in parallel
+- Tasks affecting the same file should be sequential
+- Each task should be completable independently
+- **Quality over quantity**: Fewer, well-defined tasks beat many granular ones
+
+## 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/monorepo/.claude/rules/agent-conduct.md

@@ -0,0 +1,14 @@
+---
+applyTo: "**/*"
+description: "Agent conduct rules and clarification protocols."
+---
+
+# Agent Conduct
+
+Follow the rules defined in [.claude/rules-snippets/agent-conduct.md](../rules-snippets/agent-conduct.md).
+
+Key points:
+- Read the orchestration checkpoint before any multi-step task (2+ of research, planning, implementation, testing, review).
+- Ask for clarification on ambiguous requirements before proceeding.
+- Never silently change database schemas, API contracts, or authentication flows.
+- Never modify shared packages without considering downstream consumers.

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

@@ -0,0 +1,19 @@
+---
+paths:
+  - "src/server/**"
+  - "src/api/**"
+  - "apps/**/server/**"
+  - "apps/**/api/**"
+  - "**/*.server.*"
+description: "API server patterns and route conventions."
+---
+
+# API Server
+
+Follow the rules defined in [.claude/rules-snippets/api-server.md](../rules-snippets/api-server.md).
+
+Key points:
+- Follow the API route pattern for all endpoints.
+- Validate all input data before processing.
+- Return consistent response formats with proper HTTP status codes.
+- Document API endpoints in the designated location.

package/src/monorepo/.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/monorepo/.claude/rules/component-structure.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "src/components/**"
+  - "apps/**/components/**"
+  - "packages/**/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.
+- Add code comments for complex logic or non-obvious implementations.
+- Use bracketed identifiers for logs: `[ComponentName]: message`.

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

@@ -0,0 +1,16 @@
+---
+paths:
+  - "src/**"
+  - "apps/**"
+  - "packages/**"
+description: "Core library and framework usage standards."
+---
+
+# 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.
+- Use {{STATE_MANAGEMENT}} for state management and {{STYLING}} for styling.
+- Use {{UI_LIBRARY}} for UI components; check existing components before creating new ones.

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

@@ -0,0 +1,12 @@
+---
+applyTo: "**/*"
+description: "Environment setup and tooling conventions."
+---
+
+# 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.

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

@@ -0,0 +1,17 @@
+---
+paths:
+  - "src/**"
+  - "apps/**"
+  - "packages/**"
+description: "Code comments and basic logging 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`.
+- Use appropriate log levels: error, warn, info, debug.
+- Remove debug logs before committing to main branch.

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

@@ -0,0 +1,17 @@
+---
+paths:
+  - "src/**"
+  - "apps/**"
+  - "packages/**"
+description: "Monorepo logging standards and cross-app tracing."
+---
+
+# Logging
+
+Follow the rules defined in [.claude/rules-snippets/logging.md](../rules-snippets/logging.md).
+
+Key points:
+- Always prefix logs with `[App:name]` or `[Pkg:name]` for context.
+- Use correlation IDs for cross-app request tracing.
+- Centralize logging in a shared package (`{{PACKAGE_LOGGING}}`).
+- Never log passwords, tokens, or sensitive credentials.

package/src/monorepo/.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/monorepo/.claude/rules/prisma-migrations.md

@@ -0,0 +1,16 @@
+---
+paths:
+  - "prisma/**"
+  - "**/migrations/**"
+  - "**/*.prisma"
+description: "Database migration and schema management rules."
+---
+
+# Prisma Migrations
+
+Follow the rules defined in [.claude/rules-snippets/prisma-migrations.md](../rules-snippets/prisma-migrations.md).
+
+Key points:
+- Create migrations with descriptive names.
+- Apply migrations to development database before committing.
+- Update affected services and run tests after schema changes.

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

@@ -0,0 +1,14 @@
+---
+applyTo: "**/*"
+description: "Project documentation and context conventions."
+---
+
+# 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.
+- Check `docs/` directory for architecture and design decisions.
+- Reference AGENTS.md for project overview and `.github/instructions/` for detailed standards.
+- Check app-specific AGENTS.md files for per-app patterns and conventions.