thanh-kit 2.5.3 → 2.5.4

package/templates/commands/fix/logs.md

@@ -0,0 +1,26 @@
+---
+description: ⚡ Analyze logs and fix issues
+argument-hint: [issue]
+---
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+## Mission
+<issue>$ARGUMENTS</issue>
+
+## Workflow
+1. Check if `./logs.txt` exists:
+   - If missing, set up permanent log piping in project's script config (`package.json`, `Makefile`, `pyproject.toml`, etc.):
+     - **Bash/Unix**: append `2>&1 | tee logs.txt`
+     - **PowerShell**: append `*>&1 | Tee-Object logs.txt`
+   - Run the command to generate logs
+2. Use `debugger` subagent to analyze `./logs.txt` and find root causes:
+   - Use `Grep` with `head_limit: 30` to read only last 30 lines (avoid loading entire file)
+   - If insufficient context, increase `head_limit` as needed
+3. Use `scout` subagent to analyze the codebase and find the exact location of the issues, then report back to main agent.
+4. Use `planner` subagent to create an implementation plan based on the reports, then report back to main agent.
+5. Start implementing the fix based the reports and solutions.
+6. Use `tester` agent to test the fix and make sure it works, then report back to main agent.
+7. Use `code-reviewer` subagent to quickly review the code changes and make sure it meets requirements, then report back to main agent.
+8. If there are issues or failed tests, repeat from step 3.
+9. After finishing, respond back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.

package/templates/commands/fix/parallel.md

@@ -0,0 +1,54 @@
+---
+description: ⚡⚡ Analyze & fix issues with parallel fullstack-developer agents
+argument-hint: [issues]
+---
+
+**Ultrathink parallel** to fix: <issues>$ARGUMENTS</issues>
+
+**IMPORTANT:** Activate needed skills. Ensure token efficiency. Sacrifice grammar for concision.
+
+## Workflow
+
+### 1. Issue Analysis
+- Use `debugger` subagent to analyze root causes
+- Use `/scout:ext` to find related files
+- Categorize issues by scope/area (frontend, backend, auth, payments, etc.)
+- Identify dependencies between issues
+
+### 2. Parallel Fix Planning
+- Trigger `/plan:parallel <detailed-fix-instructions>` for parallel-executable fix plan
+- Wait for plan with dependency graph, execution strategy, file ownership matrix
+- Group independent fixes for parallel execution
+- Sequential fixes for dependent issues
+
+### 3. Parallel Fix Implementation
+- Read `plan.md` for dependency graph
+- Launch multiple `fullstack-developer` agents in PARALLEL for independent fixes
+  - Example: "Fix auth + Fix payments + Fix UI" → launch 3 agents simultaneously
+  - Pass phase file path: `{plan-dir}/phase-XX-*.md`
+  - Include environment info
+- Wait for all parallel fixes complete before dependent fixes
+- Sequential fixes: launch one agent at a time
+
+### 4. Testing
+- Use `tester` subagent for full test suite
+- NO fake data/mocks/cheats
+- Verify all issues resolved
+- If fail: use `debugger`, fix, repeat
+
+### 5. Code Review
+- Use `code-reviewer` for all changes
+- Verify fixes don't introduce regressions
+- If critical issues: fix, retest
+
+### 6. Project Management & Docs
+- If approved: use `project-manager` + `docs-manager` in parallel
+- Update plan files, docs, roadmap
+- If rejected: fix and repeat
+
+### 7. Final Report
+- Summary of all fixes from parallel phases
+- Verification status per issue
+- Ask to commit (use `git-manager` if yes)
+
+**Example:** Fix 1 (auth) + Fix 2 (payments) + Fix 3 (UI) → Launch 3 fullstack-developer agents → Wait → Fix 4 (integration) sequential

package/templates/commands/fix/test.md

@@ -0,0 +1,20 @@
+---
+description: ⚡⚡ Run test suite and fix issues
+argument-hint: [issues]
+---
+
+Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+## Reported Issues:
+<issues>$ARGUMENTS</issues>
+
+## Workflow:
+1. Use `tester` subagent to compile the code and fix all syntax errors if any.
+2. Use `tester` subagent to run the tests and report back to main agent.
+3. If there are issues or failed tests, use `debugger` subagent to find the root cause of the issues, then report back to main agent.
+4. Use `planner` subagent to create an implementation plan based on the reports, then report back to main agent.
+5. Use main agent to implement the plan step by step.
+6. Use `tester` agent to test the fix and make sure it works, then report back to main agent.
+6. Use `code-reviewer` subagent to quickly review the code changes and make sure it meets requirements, then report back to main agent.
+7. If there are issues or failed tests, repeat from step 2.
+8. After finishing, respond back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.

package/templates/commands/fix/types.md

@@ -0,0 +1,9 @@
+---
+description: ⚡ Fix type errors
+---
+
+Run `bun run typecheck` or `tsc` or `npx tsc` and fix all type errors.
+
+## Rules
+- Fix all of type errors and repeat the process until there are no more type errors.
+- Do not use `any` just to pass the type check.

package/templates/commands/fix/ui.md

@@ -0,0 +1,48 @@
+---
+description: ⚡⚡ Analyze and fix UI issues
+argument-hint: [issue]
+---
+
+## Required Skills (Priority Order)
+1. **`ui-ux-pro-max`** - Design intelligence database (ALWAYS ACTIVATE FIRST)
+2. **`aesthetic`** - Design principles
+3. **`frontend-design`** - Implementation patterns
+
+Use `ui-ux-designer` subagent to read and analyze `./docs/design-guidelines.md` then fix the following issues:
+<issue>$ARGUMENTS</issue>
+
+## Workflow
+**FIRST**: Run `ui-ux-pro-max` searches to understand context and common issues:
+```bash
+python3 .claude/skills/ui-ux-pro-max/scripts/search.py "<product-type>" --domain product
+python3 .claude/skills/ui-ux-pro-max/scripts/search.py "<style-keywords>" --domain style
+python3 .claude/skills/ui-ux-pro-max/scripts/search.py "accessibility" --domain ux
+python3 .claude/skills/ui-ux-pro-max/scripts/search.py "z-index animation" --domain ux
+```
+
+If the user provides a screenshots or videos, use `ai-multimodal` skill to describe as detailed as possible the issue, make sure developers can predict the root causes easily based on the description.
+
+1. Use `ui-ux-designer` subagent to implement the fix step by step.
+2. Use screenshot capture tools along with `ai-multimodal` skill to take screenshots of the implemented fix (at the exact parent container, don't take screenshot of the whole page) and use the appropriate Gemini analysis skills (`ai-multimodal`, `video-analysis`, or `document-extraction`) to analyze those outputs so the result matches the design guideline and addresses all issues.
+  - If the issues are not addressed, repeat the process until all issues are addressed.
+3. Use `chrome-devtools` skill to analyze the implemented fix and make sure it matches the design guideline.
+4. Use `tester` agent to test the fix and compile the code to make sure it works, then report back to main agent.
+  - If there are issues or failed tests, ask main agent to fix all of them and repeat the process until all tests pass.
+5. Project Management & Documentation:
+  **If user approves the changes:** Use `project-manager` and `docs-manager` subagents in parallel to update the project progress and documentation:
+    * Use `project-manager` subagent to update the project progress and task status in the given plan file.
+    * Use `docs-manager` subagent to update the docs in `./docs` directory if needed.
+    * Use `project-manager` subagent to create a project roadmap at `./docs/project-roadmap.md` file.
+    * **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+  **If user rejects the changes:** Ask user to explain the issues and ask main agent to fix all of them and repeat the process.
+6. Final Report:
+  * Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
+  * Ask the user if they want to commit and push to git repository, if yes, use `git-manager` subagent to commit and push to git repository.
+  * **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+  * **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+
+**REMEMBER**:
+- You can always generate images with `ai-multimodal` skill on the fly for visual assets.
+- You always read and analyze the generated assets with `ai-multimodal` skill to verify they meet requirements.
+- For image editing (removing background, adjusting, cropping), use `ImageMagick` skill or similar tools as needed.
+- **IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.

package/templates/commands/fix.md

@@ -0,0 +1,43 @@
+---
+description: ⚡⚡ Analyze and fix issues [INTELLIGENT ROUTING]
+argument-hint: [issues]
+---
+
+**Analyze issues and route to specialized fix command:**
+<issues>$ARGUMENTS</issues>
+
+## Decision Tree
+
+**1. Check for existing plan:**
+- If markdown plan exists → `/code <path-to-plan>`
+
+**2. Route by issue type:**
+
+**A) Type Errors** (keywords: type, typescript, tsc, type error)
+→ `/fix:types`
+
+**B) UI/UX Issues** (keywords: ui, ux, design, layout, style, visual, button, component, css, responsive)
+→ `/fix:ui <detailed-description>`
+
+**C) CI/CD Issues** (keywords: github actions, pipeline, ci/cd, workflow, deployment, build failed)
+→ `/fix:ci <github-actions-url-or-description>`
+
+**D) Test Failures** (keywords: test, spec, jest, vitest, failing test, test suite)
+→ `/fix:test <detailed-description>`
+
+**E) Log Analysis** (keywords: logs, error logs, log file, stack trace)
+→ `/fix:logs <detailed-description>`
+
+**F) Multiple Independent Issues** (2+ unrelated issues in different areas)
+→ `/fix:parallel <detailed-description>`
+
+**G) Complex Issues** (keywords: complex, architecture, refactor, major, system-wide, multiple components)
+→ `/fix:hard <detailed-description>`
+
+**H) Simple/Quick Fixes** (default: small bug, single file, straightforward)
+→ `/fix:fast <detailed-description>`
+
+## Notes
+- `detailed-description` = enhanced prompt describing issue in detail
+- If unclear, ask user for clarification before routing
+- Can combine routes: e.g., multiple type errors + UI issue → `/fix:parallel`

package/templates/commands/plan/ci.md

@@ -0,0 +1,33 @@
+---
+description: Analyze Github Actions logs and provide a plan to fix the issues
+argument-hint: [github-actions-url]
+---
+
+Activate `planning` skill.
+
+## Github Actions URL
+ $ARGUMENTS
+
+Use the `planner` subagent to read the github actions logs, analyze and find the root causes of the issues, then provide a detailed plan for implementing the fixes.
+
+**Plan File Specification:**
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P1
+  effort: {estimated fix time}
+  branch: {current git branch}
+  tags: [ci, bugfix]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+
+**Output:**
+Provide at least 2 implementation approaches with clear trade-offs, and explain the pros and cons of each approach, and provide a recommended approach.
+
+**IMPORTANT:** Ask the user for confirmation before implementing.
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.

package/templates/commands/plan/cro.md

@@ -0,0 +1,69 @@
+---
+description: Create a CRO plan for the given content
+argument-hint: [issues]
+---
+
+You are an expert in conversion optimization. Analyze the content based on the given issues:
+<issues>$ARGUMENTS</issues>
+
+Activate `planning` skill.
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+## Conversion Optimization Framework
+
+1. Headline 4-U Formula: **Useful, Unique, Urgent, Ultra-specific** (80% won't read past this)
+2. Above-Fold Value Proposition: Customer problem focus, no company story, zero scroll required
+3. CTA First-Person Psychology: "Get MY Guide" vs "Get YOUR Guide" (90% more clicks)
+4. 5-Field Form Maximum: Every field kills conversions, progressive profiling for the rest
+5. Message Match Precision: Ad copy, landing page headline, broken promises = bounce
+6. Social Proof Near CTAs: Testimonials with faces/names, results, placed at decision points
+7. Cognitive Bias Stack: Loss aversion (fear), social proof (FOMO), anchoring (pricing)
+8. PAS Copy Framework: Problem > Agitate > Solve, emotion before logic
+9. Genuine Urgency Only: Real deadlines, actual limits, fake timers destroy trust forever
+10. Price Anchoring Display: Show expensive option first, make real price feel like relief
+11. Trust Signal Clustering: Security badges, guarantees, policies all visible together
+12. Visual Hierarchy F-Pattern: Eyes scan F-shape, put conversions in the path
+13. Lead Magnet Hierarchy: Templates > Checklists > Guides (instant > delayed gratification)
+14. Objection Preemption: Address top 3 concerns before they think them, FAQ near CTA
+15. Mobile Thumb Zone: CTAs where thumbs naturally rest, not stretching required
+16. One-Variable Testing: Change one thing, measure impact, compound wins over time
+17. Post-Conversion Momentum: Thank you page sells next step while excitement peaks
+18. Cart Recovery Sequence: Email in 1 hour, retarget in 4 hours, incentive at 24 hours
+19. Reading Level Grade 6: Smart people prefer simple, 11-word sentences, short paragraphs
+20. TOFU/MOFU/BOFU Logic: Awareness content ≠ decision content, match intent precisely
+21. White Space = Focus: Empty space makes CTAs impossible to miss, crowded = confused
+22. Benefit-First Language: Features tell, benefits sell, transformations compel
+23. Micro-Commitment Ladder: Small yes leads to big yes, start with email only
+24. Performance Tracking Stack: Heatmaps show problems, recordings show why, events show what
+25. Weekly Optimization Ritual: Review metrics Monday, test Tuesday, iterate or scale
+
+## Workflow
+
+- If the user provides a screenshots or videos, use `ai-multimodal` skill to describe as detailed as possible the issue, make sure fullstack-developer can fully understand the issue easily based on the description.
+- If the user provides a URL, use `web_fetch` tool to fetch the content of the URL and analyze the current issues.
+- You can use screenshot capture tools along with `ai-multimodal` skill to capture screenshots of the exact parent container and analyze the current issues with the appropriate Gemini analysis skills (`ai-multimodal`, `gemini-video-understanding`, or `gemini-document-processing`).
+- Use `/scout:ext` (preferred) or `/scout` (fallback) slash command to search the codebase for files needed to complete the task
+- Use `planner` agent to create a comprehensive CRO plan following the progressive disclosure structure:
+  - Create a directory using naming pattern from `## Naming` section.
+  - Every `plan.md` MUST start with YAML frontmatter:
+    ```yaml
+    ---
+    title: "{Brief title}"
+    description: "{One sentence for card preview}"
+    status: pending
+    priority: P2
+    effort: {sum of phases, e.g., 4h}
+    branch: {current git branch}
+    tags: [cro, conversion]
+    created: {YYYY-MM-DD}
+    ---
+    ```
+  - Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
+  - For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
+  - Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+- Do not start implementing the CRO plan yet, wait for the user to approve the plan first.
+
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.

package/templates/commands/plan/fast.md

@@ -0,0 +1,82 @@
+---
+description: ⚡⚡ No research. Only analyze and create an implementation plan
+argument-hint: [task]
+---
+
+Think.
+Activate `planning` skill.
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Pre-Creation Check (Active vs Suggested Plan)
+
+Check the `## Plan Context` section in the injected context:
+- If "Plan:" shows a path → Active plan exists. Ask user: "Continue with this? [Y/n]"
+- If "Suggested:" shows a path → Branch-matched hint only. Ask if they want to activate or create new.
+- If "Plan: none" → Create new plan using naming from `## Naming` section.
+
+## Workflow
+Use `planner` subagent to:
+1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
+   If reusing: Use the active plan path from Plan Context.
+   Make sure you pass the directory path to every subagent during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
+4. Gathers all information and create an implementation plan of this task.
+5. Ask user to review the plan.
+
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** After plan creation, you MUST remind the user with the **full absolute path**:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run:
+> ```
+> /cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
+
+**Why `--auto`?** Fast planning pairs with fast execution - skips review gates.
+**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
+
+This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan with the actual absolute path.
+
+## Output Requirements
+
+**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
+```
+{plan-dir}/
+├── reports/
+│   ├── XX-report.md
+│   └── ...
+├── plan.md
+├── phase-XX-phase-name-here.md
+└── ...
+```
+
+**Plan File Specification**
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P2
+  effort: {sum of phases, e.g., 4h}
+  branch: {current git branch}
+  tags: [relevant, tags]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status and progress plus links to phase files.
+- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order: Context links (reference parent plan, dependencies, docs), Overview (date, description, priority, implementation status, review status), Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps.
+
+## Important Notes
+- **IMPORTANT:** Ensure token consumption efficiency while maintaining high quality.
+- **IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+- **IMPORTANT**: **Do not** start implementing.

package/templates/commands/plan/hard.md

@@ -0,0 +1,108 @@
+---
+description: ⚡⚡⚡ Research, analyze, and create an implementation plan
+argument-hint: [task]
+---
+
+Think harder.
+Activate `planning` skill.
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Pre-Creation Check (Active vs Suggested Plan)
+
+Check the `## Plan Context` section in the injected context:
+- If "Plan:" shows a path → Active plan exists. Ask user: "Continue with this? [Y/n]"
+- If "Suggested:" shows a path → Branch-matched hint only. Ask if they want to activate or create new.
+- If "Plan: none" → Create new plan using naming from `## Naming` section.
+
+## Workflow
+1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
+   If reusing: Use the active plan path from Plan Context.
+   Make sure you pass the directory path to every subagent during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Use multiple `researcher` agents (max 2 agents) in parallel to research for this task:
+   Each agent research for a different aspect of the task and are allowed to perform max 5 tool calls.
+4. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
+   **ONLY PERFORM THIS FOLLOWING STEP IF `codebase-summary.md` is not available or older than 3 days**: Use `/scout <instructions>` slash command to search the codebase for files needed to complete the task.
+5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the prompt to create an implementation plan of this task.
+6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
+
+## Post-Plan Validation (Optional)
+
+After plan creation, offer validation interview to confirm decisions before implementation.
+
+**Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:**
+
+| Mode | Behavior |
+|------|----------|
+| `prompt` | Ask user: "Validate this plan with a brief interview?" → Yes (Recommended) / No |
+| `auto` | Automatically execute `/plan:validate {plan-path}` |
+| `off` | Skip validation step entirely |
+
+**If mode is `prompt`:** Use `AskUserQuestion` tool with options above.
+**If user chooses validation or mode is `auto`:** Execute `/plan:validate {plan-path}` SlashCommand.
+
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** If user skips validation (chooses "No" or mode is `off`), you MUST remind them with the **full absolute path**:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run:
+> ```
+> /cook {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
+
+**Why no flag?** Thorough planning without validation needs interactive review gates.
+**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
+
+This reminder is **NON-NEGOTIABLE** when validation is skipped - always output with the actual absolute path.
+
+## Output Requirements
+
+**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
+```
+{plan-dir}/
+├── research/
+│   ├── researcher-XX-report.md
+│   └── ...
+├── reports/
+│   ├── XX-report.md
+│   └── ...
+├── scout/
+│   ├── scout-XX-report.md
+│   └── ...
+├── plan.md
+├── phase-XX-phase-name-here.md
+└── ...
+```
+
+**Research Output Requirements**
+- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
+
+**Plan File Specification**
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P2
+  effort: {sum of phases, e.g., 4h}
+  branch: {current git branch}
+  tags: [relevant, tags]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status and progress plus links to phase files.
+- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order: Context links (reference parent plan, dependencies, docs), Overview (date, description, priority, implementation status, review status), Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps.
+
+## Important Notes
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+**IMPORTANT**: **Do not** start implementing.

package/templates/commands/plan/parallel.md

@@ -0,0 +1,145 @@
+---
+description: ⚡⚡⚡ Create detailed plan with parallel-executable phases
+argument-hint: [task]
+---
+
+Think strategically about parallelization.
+Activate `planning` skill.
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Workflow
+1. Create a directory using naming pattern from `## Naming` section in injected context.
+   Make sure you pass the directory path to every subagent during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Use multiple `researcher` agents (max 2 agents) in parallel to research for this task:
+   Each agent research for a different aspect of the task and are allowed to perform max 5 tool calls.
+4. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
+   **ONLY PERFORM THIS FOLLOWING STEP IF `codebase-summary.md` is not available or older than 3 days**: Use `/scout <instructions>` slash command to search the codebase for files needed to complete the task.
+5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the prompt to create a parallel-optimized implementation plan.
+6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
+
+## Post-Plan Validation (Optional)
+
+After plan creation, offer validation interview to confirm decisions before implementation.
+
+**Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:**
+
+| Mode | Behavior |
+|------|----------|
+| `prompt` | Ask user: "Validate this plan with a brief interview?" → Yes (Recommended) / No |
+| `auto` | Automatically execute `/plan:validate {plan-path}` |
+| `off` | Skip validation step entirely |
+
+**If mode is `prompt`:** Use `AskUserQuestion` tool with options above.
+**If user chooses validation or mode is `auto`:** Execute `/plan:validate {plan-path}` SlashCommand.
+
+## Special Requirements for Parallel Execution
+
+**CRITICAL:** The planner subagent must create phases that:
+1. **Can be executed independently** - Each phase should be self-contained with no runtime dependencies on other phases
+2. **Have clear boundaries** - No file overlap between phases (each file should only be modified in ONE phase)
+3. **Separate concerns logically** - Group by architectural layer, feature domain, or technology stack
+4. **Minimize coupling** - Phases should communicate through well-defined interfaces only
+5. **Include dependency matrix** - Clearly document which phases must run sequentially vs in parallel
+
+**Parallelization Strategy:**
+- Group frontend/backend/database work into separate phases when possible
+- Separate infrastructure setup from application logic
+- Isolate different feature domains (e.g., auth vs profile vs payments)
+- Split by file type/directory (e.g., components vs services vs models)
+- Create independent test phases per module
+
+**Phase Organization Example:**
+```
+Phase 01: Database Schema (can run independently)
+Phase 02: Backend API Layer (can run independently)
+Phase 03: Frontend Components (can run independently)
+Phase 04: Integration Tests (depends on 01, 02, 03)
+```
+
+## Output Requirements
+
+**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
+```
+{plan-dir}/
+├── research/
+│   ├── researcher-XX-report.md
+│   └── ...
+├── reports/
+│   ├── XX-report.md
+│   └── ...
+├── scout/
+│   ├── scout-XX-report.md
+│   └── ...
+├── plan.md
+├── phase-XX-phase-name-here.md
+└── ...
+```
+
+**Research Output Requirements**
+- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
+
+**Plan File Specification**
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P2
+  effort: {sum of phases, e.g., 4h}
+  branch: {current git branch}
+  tags: [relevant, tags]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status, progress, parallelization group, and links to phase files.
+- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order:
+  - Context links (reference parent plan, dependencies, docs)
+  - **Parallelization Info** (which phases can run concurrently, which must wait)
+  - Overview (date, description, priority, implementation status, review status)
+  - Key Insights
+  - Requirements
+  - Architecture
+  - **Related code files** (MUST be exclusive to this phase - no overlap with other phases)
+  - **File Ownership** (explicit list of files this phase owns/modifies)
+  - Implementation Steps
+  - Todo list
+  - Success Criteria
+  - **Conflict Prevention** (how this phase avoids conflicts with parallel phases)
+  - Risk Assessment
+  - Security Considerations
+  - Next steps
+
+**Main plan.md must include:**
+- Dependency graph showing which phases can run in parallel
+- Execution strategy (e.g., "Phases 1-3 parallel, then Phase 4")
+- File ownership matrix (which phase owns which files)
+
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** After plan creation, you MUST remind the user with the **full absolute path**:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run:
+> ```
+> /cook --parallel {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
+
+**Why `--parallel`?** Parallel-optimized plan pairs with parallel execution - multiple agents work on independent phases.
+**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
+
+This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan with the actual absolute path.
+
+## Important Notes
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+**IMPORTANT:** Do not start implementing.
+**IMPORTANT:** Each phase MUST have exclusive file ownership - no file can be modified by multiple phases.