cokit-cli 1.0.8 → 1.0.9

package/templates/repo/.github/prompts/ck-ck-help.prompt.md

@@ -1,114 +1,112 @@
----
-agent: 'agent'
-description: 'ClaudeKit usage guide - just type naturally'
-tools: ['search/codebase']
----
-
-Think harder.
-All-in-one ClaudeKit guide. Run the script and present output based on type markers.
-
-## Pre-Processing
-
-**IMPORTANT: Always translate `${input}` to English before passing to script.**
-
-The Python script only understands English keywords. If `${input}` is in another language:
-1. Translate `${input}` to English
-2. Pass the translated English string to the script
-
-## Execution
-
-```bash
-python ~/.claude/scripts/ck_help.py "${input}"
-```
-
-## Output Type Detection
-
-The script outputs a type marker on the first line: `@CK_OUTPUT_TYPE:<type>`
-
-**Read this marker and adjust your presentation accordingly:**
-
-### `@CK_OUTPUT_TYPE:comprehensive-docs`
-
-Full documentation (config, schema, setup guides).
-
-**Presentation:**
-1. Show the **COMPLETE** script output verbatim - every section, every code block
-2. **THEN ADD** helpful context:
-   - Real-world usage examples ("For example, if you're working on multiple projects...")
-   - Common gotchas and tips ("Watch out for: ...")
-   - Practical scenarios ("This is useful when...")
-3. End with a specific follow-up question
-
-**Example enhancement after showing full output:**
-```
-## Additional Tips
-
-**When to use global vs local config:**
-- Use global ( for personal preferences like language, issue prefix style
-- Use local ( for project-specific paths, naming conventions
-
-**Common setup for teams:**
-Each team member sets their locale globally, but projects share local config via git.
-
-Need help setting up a specific configuration?
-```
-
-### `@CK_OUTPUT_TYPE:category-guide`
-
-Workflow guides for command categories (fix, plan, cook, etc.).
-
-**Presentation:**
-1. Show the complete workflow and command list
-2. **ADD** practical context:
-   - When to use this workflow vs alternatives
-   - Real example: "If you encounter a bug in authentication, start with..."
-   - Transition tips between commands
-3. Offer to help with a specific task
-
-### `@CK_OUTPUT_TYPE:command-details`
-
-Single command documentation.
-
-**Presentation:**
-1. Show full command info from script
-2. **ADD**:
-   - Concrete usage example with realistic input
-   - When this command shines vs alternatives
-   - Common flags or variations
-3. Offer to run the command for them
-
-### `@CK_OUTPUT_TYPE:search-results`
-
-Search matches for a keyword.
-
-**Presentation:**
-1. Show all matches from script
-2. **HELP** user navigate:
-   - Group by relevance if many results
-   - Suggest most likely match based on context
-   - Offer to explain any specific command
-3. Ask what they're trying to accomplish
-
-### `@CK_OUTPUT_TYPE:task-recommendations`
-
-Task-based command suggestions.
-
-**Presentation:**
-1. Show recommended commands from script
-2. **EXPLAIN** the reasoning:
-   - Why these commands fit the task
-   - Suggested order of execution
-   - What each step accomplishes
-3. Offer to start with the first recommended command
-
-## Key Principle
-
-**Script output = foundation. Your additions = value-add.**
-
-Never replace or summarize the script output. Always show it fully, then enhance with your knowledge and context.
-
-## Important: Correct Workflows
-
-- ** → **: Plan first, then execute the plan
-- **`/cook`**: Standalone - plans internally, no separate  needed
-- **NEVER** suggest  → `/cook` (cook has its own planning)
+---
+agent: 'agent'
+description: 'Cokit usage guide - just type naturally'
+tools: ['search/codebase']
+---
+
+Think harder.
+All-in-one Cokit guide for GitHub Copilot. Run the script and present output based on type markers.
+
+## Pre-Processing
+
+**IMPORTANT: Always translate `${input}` to English before passing to script.**
+
+The Python script only understands English keywords. If `${input}` is in another language:
+1. Translate `${input}` to English
+2. Pass the translated English string to the script
+
+## Execution
+
+Search for CoKit resources in `.github/` directory and present them to user based on their query: `${input}`
+
+## Output Type Detection
+
+The script outputs a type marker on the first line: `@CK_OUTPUT_TYPE:<type>`
+
+**Read this marker and adjust your presentation accordingly:**
+
+### `@CK_OUTPUT_TYPE:comprehensive-docs`
+
+Full documentation (config, schema, setup guides).
+
+**Presentation:**
+1. Show the **COMPLETE** script output verbatim - every section, every code block
+2. **THEN ADD** helpful context:
+   - Real-world usage examples ("For example, if you're working on multiple projects...")
+   - Common gotchas and tips ("Watch out for: ...")
+   - Practical scenarios ("This is useful when...")
+3. End with a specific follow-up question
+
+**Example enhancement after showing full output:**
+```
+## Additional Tips
+
+**When to use global vs local config:**
+- Use global ( for personal preferences like language, issue prefix style
+- Use local ( for project-specific paths, naming conventions
+
+**Common setup for teams:**
+Each team member sets their locale globally, but projects share local config via git.
+
+Need help setting up a specific configuration?
+```
+
+### `@CK_OUTPUT_TYPE:category-guide`
+
+Workflow guides for command categories (fix, plan, cook, etc.).
+
+**Presentation:**
+1. Show the complete workflow and command list
+2. **ADD** practical context:
+   - When to use this workflow vs alternatives
+   - Real example: "If you encounter a bug in authentication, start with..."
+   - Transition tips between commands
+3. Offer to help with a specific task
+
+### `@CK_OUTPUT_TYPE:command-details`
+
+Single command documentation.
+
+**Presentation:**
+1. Show full command info from script
+2. **ADD**:
+   - Concrete usage example with realistic input
+   - When this command shines vs alternatives
+   - Common flags or variations
+3. Offer to run the command for them
+
+### `@CK_OUTPUT_TYPE:search-results`
+
+Search matches for a keyword.
+
+**Presentation:**
+1. Show all matches from script
+2. **HELP** user navigate:
+   - Group by relevance if many results
+   - Suggest most likely match based on context
+   - Offer to explain any specific command
+3. Ask what they're trying to accomplish
+
+### `@CK_OUTPUT_TYPE:task-recommendations`
+
+Task-based command suggestions.
+
+**Presentation:**
+1. Show recommended commands from script
+2. **EXPLAIN** the reasoning:
+   - Why these commands fit the task
+   - Suggested order of execution
+   - What each step accomplishes
+3. Offer to start with the first recommended command
+
+## Key Principle
+
+**Script output = foundation. Your additions = value-add.**
+
+Never replace or summarize the script output. Always show it fully, then enhance with your knowledge and context.
+
+## Important: Correct Workflows
+
+- ** → **: Plan first, then execute the plan
+- **`/cook`**: Standalone - plans internally, no separate  needed
+- **NEVER** suggest  → `/cook` (cook has its own planning)

package/templates/repo/.github/prompts/ck-code.prompt.md

@@ -1,178 +1,178 @@
----
-agent: 'agent'
-description: 'Start coding & testing an existing plan'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'web/githubRepo', 'read/terminalLastCommand']
----
-
-**MUST READ** `CLAUDE.md` then **THINK HARDER** to start working on the following plan follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules:
-<plan>${input}</plan>
-
----
-
-## Role Responsibilities
-- You are a senior software engineer who must study the provided implementation plan end-to-end before writing code.
-- Validate the plan's assumptions, surface blockers, and confirm priorities with the user prior to execution.
-- Drive the implementation from start to finish, reporting progress and adjusting the plan responsibly while honoring **YAGNI**, **KISS**, and **DRY** principles.
-
-**IMPORTANT:** Remind these rules with  communication:
-- Sacrifice grammar for the sake of concision when writing reports.
-- In reports, list any unresolved questions at the end, if any.
-- Ensure token efficiency while maintaining high quality.
-
----
-
-## Step 0: Plan Detection & Phase Selection
-
-**If `{input}` is empty:**
-1. Find latest `plan.md` in `.s` | `find .s -name "plan.md" -type f -exec stat -f "%m %N" {} \; 2>/dev/null | sort -rn | head -1 | cut -d' ' -f2-`
-2. Parse plan for phases and status, auto-select next incomplete (prefer IN_PROGRESS or earliest Planned)
-
-**If `{input}` provided:** Use that plan and detect which phase to work on (auto-detect or use argument like "phase-2").
-
-**Output:** `✓ Step 0: [Plan Name] - [Phase Name]`
-
-** Pattern (use throughout):**
-```
-Task(_type="[type]", prompt="[task description]", description="[brief]")
-```
-
----
-
-## Workflow Sequence
-
-**Rules:** Follow steps 1-6 in order. Each step requires output marker starting with "✓ Step N:". Mark each complete in TodoWrite before proceeding. Do not skip steps.
-
----
-
-## Step 1: Analysis & Task Extraction
-
-Read plan file completely. Map dependencies between tasks. List ambiguities or blockers. Identify required skills/tools and activate from catalog. Parse phase file and extract actionable tasks.
-
-**TodoWrite Initialization & Task Extraction:**
-- Initialize TodoWrite with `Step 0: [Plan Name] - [Phase Name]` and all command steps (Step 1 through Step 6)
-- Read phase file (e.g., phase-01-preparation.md)
-- Look for tasks/steps/phases/sections/numbered/bulleted lists
-- MUST convert to TodoWrite tasks:
-  - Phase Implementation tasks → Step 2.X (Step 2.1, Step 2.2, etc.)
-  - Phase Testing tasks → Step 3.X (Step 3.1, Step 3.2, etc.)
-  - Phase Code Review tasks → Step 4.X (Step 4.1, Step 4.2, etc.)
-- Ensure each task has UNIQUE name (increment X for each task)
-- Add tasks to TodoWrite after their corresponding command step
-
-**Output:** `✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list or "none"]`
-
-Mark Step 1 complete in TodoWrite, mark Step 2 in_progress.
-
----
-
-## Step 2: Implementation
-
-Implement selected plan phase step-by-step following extracted tasks (Step 2.1, Step 2.2, etc.). Mark tasks complete as done. For UI work, /docs/design-guidelines.md". Use `ai-multimodal` skill for image assets, `imagemagick` for editing. Run type checking and compile to verify no syntax errors.
-
-**Output:** `✓ Step 2: Implemented [N] files - [X/Y] tasks complete, compilation passed`
-
-Mark Step 2 complete in TodoWrite, mark Step 3 in_progress.
-
----
-
-## Step 3: Testing
-
-Write tests covering happy path, edge cases, and error cases.  If ANY tests fail: STOP,  Repeat until 100% pass.
-
-**Testing standards:** Unit tests may use mocks for external dependencies (APIs, DB). Integration tests use test environment. E2E tests use real but isolated data. Forbidden: commenting out tests, changing assertions to pass, TODO/FIXME to defer fixes.
-
-**Output:** `✓ Step 3: Tests [X/X passed] - All requirements met`
-
-**Validation:** If X ≠ total, Step 3 INCOMPLETE - do not proceed.
-
-Mark Step 3 complete in TodoWrite, mark Step 4 in_progress.
-
----
-
-## Step 4: Code Review
-
- Check security, performance, architecture, YAGNI/KISS/DRY". If critical issues found: STOP, fix all, re-run `tester` to verify, re-run `code-reviewer`. Repeat until no critical issues.
-
-**Critical issues:** Security vulnerabilities (XSS, SQL injection, OWASP), performance bottlenecks, architectural violations, principle violations.
-
-**Output:** `✓ Step 4: Code reviewed - [0] critical issues`
-
-**Validation:** If critical issues > 0, Step 4 INCOMPLETE - do not proceed.
-
-Mark Step 4 complete in TodoWrite, mark Step 5 in_progress.
-
----
-
-## Step 5: User Approval ⏸ BLOCKING GATE
-
-Present summary (3-5 bullets): what implemented, tests [X/X passed], code review outcome.
-
-**Ask user explicitly:** "Phase implementation complete. All tests pass, code reviewed. Approve changes?"
-
-**Stop and wait** - do not output Step 6 content until user responds.
-
-**Output (while waiting):** `⏸ Step 5: WAITING for user approval`
-
-**Output (after approval):** `✓ Step 5: User approved - Ready to complete`
-
-Mark Step 5 complete in TodoWrite, mark Step 6 in_progress.
-
----
-
-## Step 6: Finalize
-
-**Prerequisites:** User approved in Step 5 (verified above).
-
-1. **STATUS UPDATE - BOTH MANDATORY - PARALLEL EXECUTION:**
-- **Call** `project-manager` sub-agent: "Update plan status in [plan-path]. Mark plan phase [phase-name] as DONE with timestamp. Update roadmap."
-- **Call** `docs-manager` sub-agent: "Update docs for plan phase [phase-name]. Changed files: [list]."
-
-2. **ONBOARDING CHECK:** Detect onboarding requirements (API keys, env vars, config) + generate summary report with next steps.
-
-3. **AUTO-COMMIT (after steps 1 and 2 completes):**
-- Run only if: Steps 1 and 2 successful + User approved + Tests passed
-- Auto-stage, commit with message [phase - plan] to LOCAL repository only
-- **IMPORTANT:** Do NOT push to remote repository. Only commit locally. If user wants to push, suggest them to run `/commit` or `git push` manually.
-
-**Validation:** Steps 1 and 2 must complete successfully. Step 3 (auto-commit) runs only if conditions met.
-
-Mark Step 6 complete in TodoWrite.
-
-**Phase workflow finished. Ready for next plan phase.**
-
----
-
-## Critical Enforcement Rules
-
-**Step outputs must follow unified format:** `✓ Step [N]: [Brief status] - [Key metrics]`
-
-**Examples:**
-- Step 0: `✓ Step 0: [Plan Name] - [Phase Name]`
-- Step 1: `✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list]`
-- Step 2: `✓ Step 2: Implemented [N] files - [X/Y] tasks complete`
-- Step 3: `✓ Step 3: Tests [X/X passed] - All requirements met`
-- Step 4: `✓ Step 4: Code reviewed - [0] critical issues`
-- Step 5: `✓ Step 5: User approved - Ready to complete`
-- Step 6: `✓ Step 6: Finalize - Status updated - Git committed`
-
-**If any "✓ Step N:" output missing, that step is INCOMPLETE.**
-
-**TodoWrite tracking required:** Initialize at Step 0, mark each step complete before next.
-
-**Mandatory  calls:**
-- Step 3: `tester`
-- Step 4: `code-reviewer`
-- Step 6: `project-manager` AND `docs-manager` (when user approves)
-
-**Blocking gates:**
-- Step 3: Tests must be 100% passing
-- Step 4: Critical issues must be 0
-- Step 5: User must explicitly approve
-- Step 6: Both `project-manager` and `docs-manager` must complete successfully
-
-**REMEMBER:**
-- Do not skip steps. Do not proceed if validation fails. Do not assume approval without user response.
-- One plan phase per command run. Command focuses on single plan phase only.
-- 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` or similar tools as needed.
+---
+agent: 'agent'
+description: 'Start coding & testing an existing plan'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'web/githubRepo', 'read/terminalLastCommand']
+---
+
+**THINK HARDER** to start working on the following plan follow the Orchestration Protocol, Core Responsibilities, and Development Rules:
+<plan>${input}</plan>
+
+---
+
+## Role Responsibilities
+- You are a senior software engineer who must study the provided implementation plan end-to-end before writing code.
+- Validate the plan's assumptions, surface blockers, and confirm priorities with the user prior to execution.
+- Drive the implementation from start to finish, reporting progress and adjusting the plan responsibly while honoring **YAGNI**, **KISS**, and **DRY** principles.
+
+**IMPORTANT:** Remind these rules with  communication:
+- Sacrifice grammar for the sake of concision when writing reports.
+- In reports, list any unresolved questions at the end, if any.
+- Ensure token efficiency while maintaining high quality.
+
+---
+
+## Step 0: Plan Detection & Phase Selection
+
+**If `{input}` is empty:**
+1. Find latest `plan.md` in `.s` | `find .s -name "plan.md" -type f -exec stat -f "%m %N" {} \; 2>/dev/null | sort -rn | head -1 | cut -d' ' -f2-`
+2. Parse plan for phases and status, auto-select next incomplete (prefer IN_PROGRESS or earliest Planned)
+
+**If `{input}` provided:** Use that plan and detect which phase to work on (auto-detect or use argument like "phase-2").
+
+**Output:** `✓ Step 0: [Plan Name] - [Phase Name]`
+
+** Pattern (use throughout):**
+```
+Task(_type="[type]", prompt="[task description]", description="[brief]")
+```
+
+---
+
+## Workflow Sequence
+
+**Rules:** Follow steps 1-6 in order. Each step requires output marker starting with "✓ Step N:". Mark each complete in TodoWrite before proceeding. Do not skip steps.
+
+---
+
+## Step 1: Analysis & Task Extraction
+
+Read plan file completely. Map dependencies between tasks. List ambiguities or blockers. Identify required skills/tools and activate from catalog. Parse phase file and extract actionable tasks.
+
+**TodoWrite Initialization & Task Extraction:**
+- Initialize TodoWrite with `Step 0: [Plan Name] - [Phase Name]` and all command steps (Step 1 through Step 6)
+- Read phase file (e.g., phase-01-preparation.md)
+- Look for tasks/steps/phases/sections/numbered/bulleted lists
+- MUST convert to TodoWrite tasks:
+  - Phase Implementation tasks → Step 2.X (Step 2.1, Step 2.2, etc.)
+  - Phase Testing tasks → Step 3.X (Step 3.1, Step 3.2, etc.)
+  - Phase Code Review tasks → Step 4.X (Step 4.1, Step 4.2, etc.)
+- Ensure each task has UNIQUE name (increment X for each task)
+- Add tasks to TodoWrite after their corresponding command step
+
+**Output:** `✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list or "none"]`
+
+Mark Step 1 complete in TodoWrite, mark Step 2 in_progress.
+
+---
+
+## Step 2: Implementation
+
+Implement selected plan phase step-by-step following extracted tasks (Step 2.1, Step 2.2, etc.). Mark tasks complete as done. For UI work, /docs/design-guidelines.md". Use `ai-multimodal` skill for image assets, `imagemagick` for editing. Run type checking and compile to verify no syntax errors.
+
+**Output:** `✓ Step 2: Implemented [N] files - [X/Y] tasks complete, compilation passed`
+
+Mark Step 2 complete in TodoWrite, mark Step 3 in_progress.
+
+---
+
+## Step 3: Testing
+
+Write tests covering happy path, edge cases, and error cases.  If ANY tests fail: STOP,  Repeat until 100% pass.
+
+**Testing standards:** Unit tests may use mocks for external dependencies (APIs, DB). Integration tests use test environment. E2E tests use real but isolated data. Forbidden: commenting out tests, changing assertions to pass, TODO/FIXME to defer fixes.
+
+**Output:** `✓ Step 3: Tests [X/X passed] - All requirements met`
+
+**Validation:** If X ≠ total, Step 3 INCOMPLETE - do not proceed.
+
+Mark Step 3 complete in TodoWrite, mark Step 4 in_progress.
+
+---
+
+## Step 4: Code Review
+
+ Check security, performance, architecture, YAGNI/KISS/DRY". If critical issues found: STOP, fix all, re-run `tester` to verify, re-run `code-reviewer`. Repeat until no critical issues.
+
+**Critical issues:** Security vulnerabilities (XSS, SQL injection, OWASP), performance bottlenecks, architectural violations, principle violations.
+
+**Output:** `✓ Step 4: Code reviewed - [0] critical issues`
+
+**Validation:** If critical issues > 0, Step 4 INCOMPLETE - do not proceed.
+
+Mark Step 4 complete in TodoWrite, mark Step 5 in_progress.
+
+---
+
+## Step 5: User Approval ⏸ BLOCKING GATE
+
+Present summary (3-5 bullets): what implemented, tests [X/X passed], code review outcome.
+
+**Ask user explicitly:** "Phase implementation complete. All tests pass, code reviewed. Approve changes?"
+
+**Stop and wait** - do not output Step 6 content until user responds.
+
+**Output (while waiting):** `⏸ Step 5: WAITING for user approval`
+
+**Output (after approval):** `✓ Step 5: User approved - Ready to complete`
+
+Mark Step 5 complete in TodoWrite, mark Step 6 in_progress.
+
+---
+
+## Step 6: Finalize
+
+**Prerequisites:** User approved in Step 5 (verified above).
+
+1. **STATUS UPDATE - BOTH MANDATORY - PARALLEL EXECUTION:**
+- **Call** `project-manager` sub-agent: "Update plan status in [plan-path]. Mark plan phase [phase-name] as DONE with timestamp. Update roadmap."
+- **Call** `docs-manager` sub-agent: "Update docs for plan phase [phase-name]. Changed files: [list]."
+
+2. **ONBOARDING CHECK:** Detect onboarding requirements (API keys, env vars, config) + generate summary report with next steps.
+
+3. **AUTO-COMMIT (after steps 1 and 2 completes):**
+- Run only if: Steps 1 and 2 successful + User approved + Tests passed
+- Auto-stage, commit with message [phase - plan] to LOCAL repository only
+- **IMPORTANT:** Do NOT push to remote repository. Only commit locally. If user wants to push, suggest them to run `/commit` or `git push` manually.
+
+**Validation:** Steps 1 and 2 must complete successfully. Step 3 (auto-commit) runs only if conditions met.
+
+Mark Step 6 complete in TodoWrite.
+
+**Phase workflow finished. Ready for next plan phase.**
+
+---
+
+## Critical Enforcement Rules
+
+**Step outputs must follow unified format:** `✓ Step [N]: [Brief status] - [Key metrics]`
+
+**Examples:**
+- Step 0: `✓ Step 0: [Plan Name] - [Phase Name]`
+- Step 1: `✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list]`
+- Step 2: `✓ Step 2: Implemented [N] files - [X/Y] tasks complete`
+- Step 3: `✓ Step 3: Tests [X/X passed] - All requirements met`
+- Step 4: `✓ Step 4: Code reviewed - [0] critical issues`
+- Step 5: `✓ Step 5: User approved - Ready to complete`
+- Step 6: `✓ Step 6: Finalize - Status updated - Git committed`
+
+**If any "✓ Step N:" output missing, that step is INCOMPLETE.**
+
+**TodoWrite tracking required:** Initialize at Step 0, mark each step complete before next.
+
+**Mandatory  calls:**
+- Step 3: `tester`
+- Step 4: `code-reviewer`
+- Step 6: `project-manager` AND `docs-manager` (when user approves)
+
+**Blocking gates:**
+- Step 3: Tests must be 100% passing
+- Step 4: Critical issues must be 0
+- Step 5: User must explicitly approve
+- Step 6: Both `project-manager` and `docs-manager` must complete successfully
+
+**REMEMBER:**
+- Do not skip steps. Do not proceed if validation fails. Do not assume approval without user response.
+- One plan phase per command run. Command focuses on single plan phase only.
+- 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` or similar tools as needed.