cokit-cli 1.0.8 → 1.2.0

package/prompts/ck-fix-test.prompt.md

@@ -1,19 +0,0 @@
----
-agent: 'agent'
-description: 'Run test suite and fix issues'
-tools: ['search/codebase', 'search/changes', 'read/problems', 'read/terminalLastCommand']
----
-
-## Reported Issues:
-<issues>${input}</issues>
-
-## Workflow:
-1. compile the code and fix all syntax errors if any.
-2. run the tests and .
-3. If there are issues or failed tests, find the root cause of the issues, .
-4. create an implementation plan based on the reports, .
-5. Use main agent to implement the plan step by step.
-6. test the fix and make sure it works, .
-6. quickly review the code changes and make sure it meets requirements, .
-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/prompts/ck-fix-types.prompt.md

@@ -1,11 +0,0 @@
----
-agent: 'agent'
-description: 'Fix type errors'
-tools: ['search/codebase', 'read/problems', 'read/terminalLastCommand']
----
-
-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/prompts/ck-fix-ui.prompt.md

@@ -1,49 +0,0 @@
----
-agent: 'agent'
-description: 'Analyze and fix UI issues'
-tools: ['search/codebase', 'search/changes', 'read/problems', 'web/fetch']
----
-
-## Required Skills (Priority Order)
-1. **`ui-ux-pro-max`** - Design intelligence database (ALWAYS ACTIVATE FIRST)
-2. **`aesthetic`** - Design principles
-3. **`frontend-design`** - Implementation patterns
-
-Read and analyze `./docs/design-guidelines.md` then fix the following issues:
-<issue>${input}</issue>
-
-## Workflow
-**FIRST**: Run `ui-ux-pro-max` searches to understand context and common issues:
-```bash
-python3  "<product-type>" --domain product
-python3  "<style-keywords>" --domain style
-python3  "accessibility" --domain ux
-python3  "z-index animation" --domain ux
-```
-
-If the user provides a screenshots or videos, 
-
-1. 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. 
-4. test the fix and compile the code to make sure it works, .
-  - 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 s  to update the project progress and documentation:
-    * update the project progress and task status in the given plan file.
-    * update the docs in `./docs` directory if needed.
-    * 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, 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:** 

package/prompts/ck-git-cm.prompt.md

@@ -1,8 +0,0 @@
----
-agent: 'agent'
-description: 'Stage all files and create a commit.'
-tools: ['search/changes', 'web/githubRepo']
----
-
-stage all files and create a commit.
-**IMPORTANT: DO NOT push the changes to remote repository**

package/prompts/ck-git-cp.prompt.md

@@ -1,7 +0,0 @@
----
-agent: 'agent'
-description: 'Stage, commit and push all code in the current branch'
-tools: ['search/changes', 'web/githubRepo']
----
-
-stage all files, create a meaningful commit based on the changes and push to remote repository.

package/prompts/ck-git-merge.prompt.md

@@ -1,41 +0,0 @@
----
-agent: 'agent'
-description: '⚠️ Merge code from one branch to another'
-tools: ['search/changes', 'web/githubRepo']
----
-
-## Variables
-
-TO_BRANCH: $1 (defaults to `main`)
-FROM_BRANCH: $2 (defaults to current branch)
-
-## Workflow
-
-### Step 1: Sync with remote (CRITICAL)
-```bash
-git fetch origin
-git checkout {TO_BRANCH}
-git pull origin {TO_BRANCH}
-```
-
-### Step 2: Merge from REMOTE tracking branch
-```bash
-# Use origin/{FROM_BRANCH} to merge remote state, not local WIP
-git merge origin/{FROM_BRANCH} --no-ff -m "merge: {FROM_BRANCH} into {TO_BRANCH}"
-```
-
-**Why `origin/{FROM_BRANCH}`:** Ensures merging only committed+pushed changes, not local uncommitted work.
-
-### Step 3: Resolve conflicts if any
-- If conflicts exist, resolve them manually
-- After resolution: `git add . && git commit`
-
-### Step 4: Push merged result
-```bash
-git push origin {TO_BRANCH}
-```
-
-## Notes
-- If `gh` command is not available, instruct the user to install and authorize GitHub CLI first.
-- If you need more clarifications, ask the user for more details.
-- Always fetch and pull latest remote state before merging to avoid stale conflicts.

package/prompts/ck-git-pr.prompt.md

@@ -1,49 +0,0 @@
----
-agent: 'agent'
-description: 'Create a pull request'
-tools: ['search/changes', 'web/githubRepo']
----
-
-## Variables
-
-TO_BRANCH: $1 (defaults to `main`)
-FROM_BRANCH: $2 (defaults to current branch)
-
-## Workflow
-
-### Step 1: Ensure remote is synced
-```bash
-git fetch origin
-git push -u origin HEAD  # Push current branch if not pushed
-```
-
-### Step 2: Analyze REMOTE diff (CRITICAL)
-**IMPORTANT:** Always compare REMOTE branches, not local:
-```bash
-# Get commits between remote branches (what PR will actually contain)
-git log origin/{TO_BRANCH}...origin/{FROM_BRANCH} --oneline
-
-# Get file diff between remote branches
-git diff origin/{TO_BRANCH}...origin/{FROM_BRANCH} --stat
-git diff origin/{TO_BRANCH}...origin/{FROM_BRANCH}
-```
-
-**DO NOT use:**
-- `git diff {TO_BRANCH}...HEAD` (includes unpushed local changes)
-- `git diff --cached` (staged local changes)
-- `git status` (local working tree state)
-
-### Step 3: Generate PR content from remote diff
-Based on the REMOTE diff analysis:
-- **Title:** Conventional commit format from the primary change (no version/release numbers)
-- **Body:** Summary of changes that exist ON REMOTE, not local WIP
-
-### Step 4: Create PR
-```bash
-gh pr create --base {TO_BRANCH} --head {FROM_BRANCH} --title "..." --body "..."
-```
-
-## Notes
-- If `gh` command is not available, instruct the user to install and authorize GitHub CLI first.
-- If local has unpushed commits, push first before analyzing diff.
-- PR content must reflect REMOTE state since PRs are based on remote branches.

package/prompts/ck-kanban.prompt.md

@@ -1,77 +0,0 @@
----
-agent: 'agent'
-description: 'Plans directory (default: .s)'
-tools: ['search/codebase', 'read/terminalLastCommand']
----
-
-Plans dashboard with progress tracking and timeline visualization.
-
-## Usage
-
-- `/kanban` - View dashboard for .s directory
-- `/kanban plans/` - View dashboard for specific directory
-- `/kanban --stop` - Stop running server
-
-## Features
-
-- Plan cards with progress bars
-- Phase status breakdown (completed, in-progress, pending)
-- Timeline/Gantt visualization
-- Activity heatmap
-- Issue and branch links
-
-## Execution
-
-**IMPORTANT:**  This makes the server visible in `/tasks` and manageable via `KillShell`.
-
-Check if this script is located in the current workspace or in  directory:
-- If in current workspace: `$SKILL_DIR_PATH` = 
-- If in home directory: `$SKILL_DIR_PATH` = 
-
-### Stop Server
-
-If `--stop` flag is provided:
-
-```bash
-node $SKILL_DIR_PATH/scripts/server.cjs --stop
-```
-
-### Start Server
-
-Otherwise, run the kanban server as CC background task with `--foreground` flag (keeps process alive for CC task management):
-
-```bash
-# Determine plans directory
-INPUT_DIR="${dir}"
-PLANS_DIR="${INPUT_DIR:-.s}"
-
-# Start kanban dashboard
-node $SKILL_DIR_PATH/scripts/server.cjs \
-  --dir "$PLANS_DIR" \
-  --host 0.0.0.0 \
-  --open \
-  --foreground
-```
-
-**Critical:** ## Future Plans
-
-The `/kanban` command will evolve into **VibeKanban-inspired** AI agent orchestration:
-
-### Phase 1 (Current - MVP)
-- ✅ Task board with progress tracking
-- ✅ Visual representation of plans/tasks
-- ✅ Click to view plan details
-
-### Phase 2 (Worktree Integration)
-- Create tasks → spawn git worktrees
-- Assign agents to tasks
-- Track agent progress per worktree
-
-### Phase 3 (Full Orchestration)
-- Parallel agent execution monitoring
-- Code diff/review interface
-- PR creation workflow
-- Agent output streaming
-- Conflict detection
-
-Track progress: https://github.com/claudekit/claudekit-engineer/issues/189

package/prompts/ck-plan-archive.prompt.md

@@ -1,57 +0,0 @@
----
-agent: 'agent'
-description: 'Write journal entries and archive specific plans or all plans'
-tools: ['search/codebase', 'search/changes']
----
-
-## Your mission
-Read and analyze the plans, then write journal entries and archive specific plans or all plans in the `plans` directory.
-
-## Plan Resolution
-1. If `${input}` provided → Use that path
-2. Else read all plans in the `plans` directory
-
-## Workflow
-
-### Step 1: Read Plan Files
-
-Read the plan directory:
-- `plan.md` - Overview and phases list
-- `phase-*.md` - 20 first lines of each phase file to understand the progress and status
-
-### Step 2: Summarize the plans and document them with `/journal` 
-Ask if user wants to document journal entries or not.
-Skip this step if user selects "No".
-If user selects "Yes":
-- Analyze the information in previous steps.
-- Use  with `_type="journal-writer"`  to document all plans.
-- Journal entries should be concise and focused on the most important events, key changes, impacts, and decisions.
-- Keep journal entries in the `./docs/journals/` directory.
-
-### Step 3: Ask user to confirm the action before archiving these plans
-Ask if user wants to proceed with archiving these plans, select specific plans to archive or all completed plans only.
-Ask if user wants to delete permanently or move to the `.s/archive` directory.
-
-### Step 4: Archive the plans
-Start archiving the plans based on the user's choice:
-- Move the plans to the `.s/archive` directory.
-- Delete the plans permanently: `rm -rf .s/<plan-1> .s/<plan-2> ...`
-
-### Step 5: Ask if user wants to commit the changes
-Ask if user wants to commit the changes with these options:
-- Stage and commit the changes (Use `/git:cm` )
-- Commit and push the changes (Use `/git:cp` )
-- Nah, I'll do it later
-
-## Output
-After archiving the plans, provide summary:
-- Number of plans archived 
-- Number of plans deleted permanently
-- Table of plans that are archived or deleted (title, status, created date, LOC)
-- Table of journal entries that are created (title, status, created date, LOC)
-
-## Important Notes
-- **IMPORTANT:** Only ask questions about genuine decision points - don't manufacture artificial choices.
-- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
-- **IMPORTANT:** In the last summary report, list any unresolved questions at the end, if any.
-- **IMPORTANT:** Ensure token efficiency while maintaining high quality.

package/prompts/ck-plan-ci.prompt.md

@@ -1,35 +0,0 @@
----
-agent: 'agent'
-description: 'Analyze Github Actions logs and provide a plan to fix the issues'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'web/githubRepo', 'read/problems']
----
-
-
-
-## Github Actions URL
- ${input}
-
-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 Notes
-- **IMPORTANT:** Ask the user for confirmation before implementing.
-- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
-- **IMPORTANT:** **Do not** start implementing.

package/prompts/ck-plan-cro.prompt.md

@@ -1,66 +0,0 @@
----
-agent: 'agent'
-description: 'Create a CRO plan for the given content'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-You are an expert in conversion optimization. Analyze the content based on the given issues:
-<issues>${input}</issues>
-
-
-
-**IMPORTANT:** 
-**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, 
-- 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`).
  - 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/prompts/ck-plan-parallel.prompt.md

@@ -1,159 +0,0 @@
----
-agent: 'agent'
-description: 'Create detailed plan with parallel-executable phases'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-Think strategically about parallelization.
-
-
-## Your mission
-<task>
-${input}
-</task>
-
-## Workflow
-1. Create a directory using naming pattern from `## Naming` section in injected context.
-   Make sure you pass the directory path to every  during the process.
-2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
-3. Use multiple `researcher` agents (max 2 agents)  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`, ``, `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  <instructions>`  to search the codebase for files needed to complete the task.
-5. 
-6. 
-
-**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 :validate {plan-path}` |
-| `off` | Skip validation step entirely |
-
-**If mode is `prompt`:** Ask user with options above.
-**If user chooses validation or mode is `auto`:** Execute :validate {plan-path}` SlashCommand.
-
-## Special Requirements for Parallel Execution
-
-**CRITICAL:** The planner  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 
-
-**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}.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 
-- Execution strategy (e.g., "Phases 1-3 parallel, then Phase 4")
-- File ownership matrix (which phase owns which files)
-
-## Clarification & Finalization Flow
-
-After creating the initial plan:
-
-1. **If questions exist** → List questions at the end of your response (max 3-5 questions)
-2. **After user answers** → Update `plan.md` with clarified requirements
-3. **Repeat** until no ambiguities remain
-4. **Finalize** → Confirm plan is complete and ready for implementation
-
-**Question format:**
-```
-## Questions before finalizing:
-1. [Question 1]?
-2. [Question 2]?
-...
-```
-
-## Next Steps Suggestion
-
-After plan is finalized, suggest the parallel execution command:
-
-**Example output:**
-```
-✅ Plan finalized: {plan-dir}/plan.md
-
-Parallel execution strategy:
-- Phases 1-3: Can run in parallel
-- Phase 4: Depends on 1-3
-
-Ready to implement? Run:
-- `/cook:parallel` - Execute phases in parallel
-- `/cook` - Execute phases sequentially
-```
-
-## Important Notes
-- **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.

package/prompts/ck-plan-two.prompt.md

@@ -1,78 +0,0 @@
----
-agent: 'agent'
-description: 'Research & create an implementation plan with 2 approaches'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-Think harder.
-
-
-## Your mission
-create 2 detailed implementation plans for this following task:
-<task>
- ${input}
-</task>
-
-## Workflow
-1. First: Create a directory using naming pattern from `## Naming` section in injected context.
-   Make sure you pass the directory path to every  during the process.
-2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
-3. Use multiple `researcher` agents  to research for this task, each agent research for a different aspect of the task and perform max 5 researches (max 5 tool calls).
-4. search the codebase for files needed to complete the task.
-5. 
-  **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.
-1. 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}
-  ---
-  ```
-
-## Clarification & Finalization Flow
-
-After creating the initial plans:
-
-1. **If questions exist** → List questions at the end of your response (max 3-5 questions)
-2. **After user chooses approach** → Update selected `plan.md` with clarified requirements
-3. **Finalize** → Confirm plan is complete and ready for implementation
-
-**Question format:**
-```
-## Questions before finalizing:
-1. Which approach do you prefer? (A or B)
-2. [Other questions]?
-...
-```
-
-## Next Steps Suggestion
-
-After plan is finalized, suggest the appropriate implementation command:
-
-| Task Type | Suggested Command |
-|-----------|-------------------|
-| Feature development | `/cook` or `/code` |
-| Bug fix | `/fix` |
-| Refactoring | `/refactor` |
-| Documentation | `/docs` |
-
-**Example output:**
-```
-✅ Plan finalized: {plan-dir}/plan.md (Approach A selected)
-
-Ready to implement? Run one of these:
-- `/cook` - Full-featured implementation with tests
-- `/code` - Quick implementation
-```
-
-## Important Notes
-- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
-- **IMPORTANT:** Ensure token efficiency while maintaining high quality.
-- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
-- **IMPORTANT:** **Do not** start implementing.