cokit-cli 1.0.7 → 1.0.9

package/templates/repo/.github/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/templates/repo/.github/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/templates/repo/.github/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/templates/repo/.github/prompts/ck-plan-fast.prompt.md

@@ -1,103 +0,0 @@
----
-agent: 'agent'
-description: 'No research. Only analyze and create an implementation plan'
-tools: ['search/codebase', 'search/changes', 'read/problems']
----
-
-Think.
-
-
-## Your mission
-<task>
-${input}
-</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  to:
-1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node  {plan-dir}`
-   If reusing: Use the active plan path from Plan 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. Analyze the codebase by reading `codebase-summary.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.
-
-## 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}.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.
-
-## 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 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
-
-Ready to implement? Run one of these:
-- `/cook` - Full-featured implementation with tests
-- `/code` - Quick implementation
-```
-
-## Important Notes
-- **IMPORTANT:** Ensure token consumption 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/repo/.github/prompts/ck-plan-hard.prompt.md

@@ -1,125 +0,0 @@
----
-agent: 'agent'
-description: 'Research, analyze, and create an implementation plan'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-Think harder.
-
-
-## Your mission
-<task>
-${input}
-</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  {plan-dir}`
-   If reusing: Use the active plan path from Plan 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.
-
-## 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 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.
-
-## 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 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
-
-Ready to implement? Run one of these:
-- `/cook` - Full-featured implementation with tests
-- `/code` - Quick implementation
-```
-
-## 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.

package/templates/repo/.github/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/templates/repo/.github/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.