cokit-cli 1.2.0 → 1.2.3

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

@@ -4,7 +4,7 @@ description: 'Bootstrap a new project step by step'
 argument-hint: 'Describe your project requirements'
 ---
 
-**Ultrathink** to plan & bootstrap a new project follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules in your `CLAUDE.md` file: 
+**Think step by step** to plan & bootstrap a new project follow the Orchestration Protocol, Core Responsibilities, Agents Team and Development Rules in your project configuration file:
 
 ---
 
@@ -17,20 +17,20 @@ argument-hint: 'Describe your project requirements'
 ## Role Responsibilities
 
 - You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
-- Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
+- Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your agents to implement the plan.
 - You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
 
 ---
 
 ## Your Approach
 
-1. **Question Everything**: Use `AskUserQuestion` tool to ask probing questions to the user to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
+1. **Question Everything**: Ask probing questions directly in your response to fully understand the user's request, constraints, and true objectives. Then stop and wait for the user to answer before proceeding. Don't assume - clarify until you're 100% certain.
 
 2. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
 
-3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior. Use `AskUserQuestion` tool to ask the user for their preferences.
+3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior. Ask the user for their preferences and wait for response.
 
-4. **Challenge Assumptions**: Question the user's initial approach. Often the best solution is different from what was originally envisioned. Use `AskUserQuestion` tool to ask the user for their preferences.
+4. **Challenge Assumptions**: Question the user's initial approach. Often the best solution is different from what was originally envisioned. Ask the user for their preferences and wait for response.
 
 5. **Consider All Stakeholders**: Evaluate impact on end users, developers, operations team, and business objectives.
 
@@ -40,11 +40,11 @@ argument-hint: 'Describe your project requirements'
 
 Follow strictly these following steps:
 
-**First thing first:** check if Git has been initialized, if not, ask the user if they want to initialize it, if yes, use `git-manager` subagent to initialize it.
+**First thing first:** check if Git has been initialized, if not, ask the user if they want to initialize it, if yes, use `git-manager` agent to initialize it.
 
 ### Fullfill the request
 
-* If you have any questions, use `AskUserQuestion` tool to ask the user to clarify them.
+* If you have any questions, ask the user directly in your response and wait for their answer before proceeding.
 * Ask 1 question at a time, wait for the user to answer before moving to the next question.
 * If you don't have any questions, start the next step.
 
@@ -52,19 +52,19 @@ Follow strictly these following steps:
 
 ### Research
 
-* Use multiple `researcher` subagents in parallel to explore the user's request, idea validation, challenges, and find the best possible solutions.
+* Use multiple `researcher` agents in parallel to explore the user's request, idea validation, challenges, and find the best possible solutions.
 * Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
 
 ### Tech Stack
 
 1. Ask the user for any tech stack they want to use, if the user provides their tech stack, skip step 2-3.
-2. Use `planner` subagent and multiple `researcher` subagents in parallel to find a best fit tech stack for this project, keeping research reports within the ≤150 lines limit.
+2. Use `planner` agent and multiple `researcher` agents in parallel to find a best fit tech stack for this project, keeping research reports within the ≤150 lines limit.
 3. Ask the user to review and approve the tech stack, if the user requests to change the tech stack, repeat the previous step until the user approves the tech stack
 4. Write the tech stack down in `./docs` directory
 
 ### Planning
 
-* Use `planner` subagent to create a detailed implementation plan following the progressive disclosure structure:
+* Use `planner` agent to create a detailed implementation plan following the progressive disclosure structure:
   - Create a directory using naming pattern from `## Naming` section.
   - 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).
@@ -76,53 +76,46 @@ Follow strictly these following steps:
 ### Wireframe & Design
 
 * Ask the user if they want to create wireframes and design guidelines, if yes, continue to the next step, if no, skip to **"Implementation"** phase.
-* Use `ui-ux-designer` subagent and multiple `researcher` subagents in parallel to create a design plan that follows the same directory/phase structure described above, keeping related research reports within the ≤150 lines limit.
+* Use `ui-ux-designer` agent and multiple `researcher` agents in parallel to create a design plan that follows the same directory/phase structure described above, keeping related research reports within the ≤150 lines limit.
    - **Research** about design style, trends, fonts, colors, border, spacing, elements' positions, etc.
-   - Describe details of the assets in the design so they can be generated with `ai-multimodal` skill later on.
+   - Describe details of the assets in the design so they can be generated later on.
    - **IMPORTANT:** Try to predict the font name (Google Fonts) and font size in the given screenshot, don't just use **Inter** or **Poppins** fonts.
-* Then use `ui-ux-designer` subagent to create the design guidelines at `./docs/design-guidelines.md` file & generate wireframes in HTML at `./docs/wireframe` directory, make sure it's clear for developers to implement later on.
-* If there are no logo provided, use `ai-multimodal` skill to generate a logo.
-* Use `chrome-devtools` skill to take a screenshot of the wireframes and save it at `./docs/wireframes/` directory.
+* Then use `ui-ux-designer` agent to create the design guidelines at `./docs/design-guidelines.md` file & generate wireframes in HTML at `./docs/wireframe` directory, make sure it's clear for developers to implement later on.
+* Use `agent-browser` skill to take a screenshot of the wireframes and save it at `./docs/wireframes/` directory.
 * Ask the user to review and approve the design guidelines, if the user requests to change the design guidelines, repeat the previous step until the user approves the design guidelines.
 
 **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.
+- Always verify generated assets meet design requirements before proceeding.
 
 ### Implementation
 
 * Use `general agent (main agent)` to implement the plan step by step, follow the implementation plan in `./plans` directory.
-* Use `ui-ux-designer` subagent to implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
-  * Use `ai-multimodal` skill to generate the assets.
-  * Use `ai-multimodal` (`video-analysis`, or `document-extraction`) skills to analyze the generated assets based on their format.
-  * Use `Background Removal Tool` to remove background from the assets if needed.
-  * Use `ai-multimodal` (`image-generation`) skill to edit the assets if needed.
-  * Use `imagemagick` skill to crop or resize the assets if needed.
+* Use `ui-ux-designer` agent to implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
+  * Generate and verify visual assets as needed.
 * Run type checking and compile the code command to make sure there are no syntax errors.
 
 ### Testing
 
 * Write the tests for the plan, make sure you don't use fake data just to pass the tests, tests should be real and cover all possible cases.
-* Use `tester` subagent to run the tests, make sure it works, then report back to main agent.
-* If there are issues or failed tests, use `debugger` subagent to find the root cause of the issues, then ask main agent to fix all of them and 
+* Use `tester` agent to run the tests, make sure it works, then report back to main agent.
+* If there are issues or failed tests, use `debugger` agent to find the root cause of the issues, then ask main agent to fix all of them and 
 * Repeat the process until all tests pass or no more issues are reported. Again, do not ignore failed tests or use fake data just to pass the build or github actions.
 
 ### Code Review
 
-* After finishing, delegate to `code-reviewer` subagent to review code. If there are critical issues, ask main agent to improve the code and tell `tester` agent to run the tests again. Repeat the process until all tests pass.
+* After finishing, delegate to `code-reviewer` agent to review code. If there are critical issues, ask main agent to improve the code and tell `tester` agent to run the tests again. Repeat the process until all tests pass.
 * When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
 * **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
 
 ### Documentation
 
-* If user approves the changes, use `docs-manager` subagent to update the docs if needed.
+* If user approves the changes, use `docs-manager` agent to update the docs if needed.
   * Create/update `./docs/README.md` file (keep it concise, under 300 lines).
   * Create/update `./docs/codebase-summary.md` file.
   * Create/update `./docs/project-overview.-pdr.md` (Product Development Requirements) file.
   * Create/update `./docs/code-standards.md` file.
   * Create/update `./docs/system-architecture.md` file.
-* Use `project-manager` subagent to create a project roadmap at `./docs/project-roadmap.md` file & project progress and task status in the given plan file.
+* Use `project-manager` agent to create a project roadmap at `./docs/project-roadmap.md` file & project progress and task status in the given plan file.
 * **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
 
 ### Onboarding
@@ -133,7 +126,7 @@ Follow strictly these following steps:
 
 ### 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.
+* Ask the user if they want to commit and push to git repository, if yes, use `git-manager` agent 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.
 
@@ -143,5 +136,6 @@ Follow strictly these following steps:
 
 | Command | Description |
 |---------|-------------|
-| `/ck.brainstorm` | Explore ideas |
-| `/ck.plan` | Create plan |
+| `/ck-brainstorm` | Explore ideas |
+| `/ck-plan` | Create plan |
+| `/ck-spec-specify` | Write detailed feature spec |

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

@@ -55,7 +55,7 @@ You operate by the holy trinity of software engineering: **YAGNI** (You Aren't G
 6. **Consensus Phase**: Ensure alignment on chosen approach and document decisions
 7. **Documentation Phase**: Create comprehensive markdown summary report
 8. **Finalize Phase**: Ask if user wants to create a detailed implementation plan
-   - If Yes: Run `/ck.plan` with brainstorm summary context
+   - If Yes: Run `/ck-plan` with brainstorm summary context
    - If No: End the session
 
 ## Output Requirements
@@ -82,5 +82,6 @@ When brainstorming concludes with agreement, create a detailed markdown summary
 
 | Command | Description |
 |---------|-------------|
-| `/ck.plan` | Create implementation plan |
-| `/ck.ask` | Answer technical questions |
+| `/ck-plan` | Create implementation plan |
+| `/ck-ask` | Answer technical questions |
+| `/ck-spec-specify` | Write detailed feature spec |

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

@@ -75,7 +75,7 @@ Human review required at these checkpoints (skipped with `--auto`):
 ## Process
 
 1. **Detect Mode**: Analyze input to determine workflow mode
-2. **Scout**: Use `/ck.scout` to discover relevant files
+2. **Scout**: Use `/ck-scout` to discover relevant files
 3. **Research** (if applicable): Gather technical context
 4. **Plan**: Create or load implementation plan
 5. **Implement**: Execute plan phases (use `@fullstack-developer` in parallel mode)
@@ -90,6 +90,7 @@ Human review required at these checkpoints (skipped with `--auto`):
 
 | Command | Description |
 |---------|-------------|
-| `/ck.test` | Run tests |
-| `/ck.git` | Commit changes |
-| `/ck.review` | Code review |
+| `/ck-test` | Run tests |
+| `/ck-review` | Code review |
+| `/ck-git` | Commit changes |
+| `/ck-spec-implement` | Spec-driven implementation instead |

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

@@ -109,6 +109,7 @@ Stop and follow process if thinking:
 
 | Command | Description |
 |---------|-------------|
-| `/ck.test` | Run tests to verify |
-| `/ck.fix` | Apply fix |
-| `/ck.git` | Commit fix |
+| `/ck-test` | Run tests to verify |
+| `/ck-fix` | Apply fix |
+| `/ck-git` | Commit fix |
+| `/ck-spec-analyze` | Analyze spec consistency |

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

@@ -96,6 +96,7 @@ Search and retrieve up-to-date documentation for libraries, frameworks, and pack
 
 | Command | Description |
 |---------|-------------|
-| `/ck.ask` | Ask technical questions |
-| `/ck.plan` | Create implementation plan |
-| `/ck.cook` | Implement feature |
+| `/ck-ask` | Ask technical questions |
+| `/ck-plan` | Create implementation plan |
+| `/ck-cook` | Implement feature |
+| `/ck-spec-specify` | Write detailed feature spec |

package/templates/repo/.github/prompts/ck-fix-ci.prompt.md

@@ -0,0 +1,46 @@
+---
+agent: 'agent'
+description: 'Analyze Github Actions logs and fix issues'
+argument-hint: 'Github Actions URL or description'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-ci` is an internal mode for CI/CD pipeline failures — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-ci` is an internal mode for CI/CD pipeline failures — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run  immediately — do NOT ask user to re-enter their input.
+
+
+## Github Actions URL
+<url>${input}</url>
+
+## Workflow
+1. Read the github actions logs with `gh` command, analyze and find the root cause of the issues.
+2. Implement the fix based on findings.
+3. Test the fix and make sure it works.
+4. If there are issues or failed tests, repeat from step 1.
+5. After finishing, respond back to user with a summary of the changes and suggest next steps.
+
+## Notes
+- If `gh` command is not available, instruct the user to install and authorize GitHub CLI first.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests and analyze results |
+| `/ck-git` | Commit changes |

package/templates/repo/.github/prompts/ck-fix-fast.prompt.md

@@ -0,0 +1,44 @@
+---
+agent: 'agent'
+description: 'Analyze and fix small issues [FAST]'
+argument-hint: 'Describe the issues'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-fast` is an internal mode for quick fixes for simple bugs — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-fast` is an internal mode for quick fixes for simple bugs — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run `/ck-fix ${input}` immediately — do NOT ask user to re-enter their input.
+
+
+## Mission
+**Think hard** to analyze and fix these issues:
+<issues>${input}</issues>
+
+## Workflow
+1. Activate `debug` and `problem-solving` skills to find the root cause.
+2. Implement the fix.
+3. Test the fix and make sure it works.
+4. If there are issues or failed tests, repeat from step 1.
+5. After finishing, respond back to user with a summary of the changes and suggest next steps.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests and analyze results |
+| `/ck-git` | Commit changes |

package/templates/repo/.github/prompts/ck-fix-hard.prompt.md

@@ -0,0 +1,60 @@
+---
+agent: 'agent'
+description: 'Plan and fix hard issues systematically'
+argument-hint: 'Describe the issues'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-hard` is an internal mode for complex, multi-step bug fixing — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-hard` is an internal mode for complex, multi-step bug fixing — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run  immediately — do NOT ask user to re-enter their input.
+
+
+**Think deeply** to plan & fix these issues:
+<issues>${input}</issues>
+
+## Workflow:
+
+### Clarify the request
+**Question Everything**: Ask probing questions directly in your response to fully understand the user's request, constraints, and true objectives. Then stop and wait for the user to answer before proceeding. Don't assume - clarify until you're 100% certain.
+
+* Ask 1 question at a time, wait for the user to answer before moving to the next question.
+* If you don't have any questions, start the next step.
+
+### Fix the issue
+
+Use `sequential-thinking` skill to break complex problems into sequential thought steps.
+Use `problem-solving` skills to tackle the issues.
+
+1. Investigate and find the root cause of the issues.
+2. Research about the root causes on the internet (if needed).
+3. Create an implementation plan based on findings.
+4. Implement the plan step by step.
+5. Test the fix and make sure it works.
+6. Final Report:
+   * Summary of changes, guide user to get started, suggest next steps.
+   * Ask the user if they want 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.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests and analyze results |
+| `/ck-git` | Commit changes |

package/templates/repo/.github/prompts/ck-fix-logs.prompt.md

@@ -0,0 +1,53 @@
+---
+agent: 'agent'
+description: 'Analyze logs and fix issues'
+argument-hint: 'Describe the issue'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-logs` is an internal mode for issues found in logs — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-logs` is an internal mode for issues found in logs — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run  immediately — do NOT ask user to re-enter their input.
+
+
+## Mission
+<issue>${input}</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. Analyze `./logs.txt` and find root causes:
+   - Search for the last 30 lines of log output (avoid loading entire file)
+   - If insufficient context, increase `head_limit` as needed
+3. Search the codebase to find the exact location of the issues.
+4. Create an implementation plan based on findings.
+5. Implement the fix.
+6. Test the fix and make sure it works.
+7. Review the code changes and make sure it meets requirements.
+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 suggest next steps.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests and analyze results |
+| `/ck-git` | Commit changes |

package/templates/repo/.github/prompts/ck-fix-test.prompt.md

@@ -0,0 +1,47 @@
+---
+agent: 'agent'
+description: 'Run test suite and fix issues'
+argument-hint: 'Describe the test issues'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-test` is an internal mode for test failures — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-test` is an internal mode for test failures — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run  immediately — do NOT ask user to re-enter their input.
+
+
+## Reported Issues:
+<issues>${input}</issues>
+
+## Workflow:
+1. Compile the code and fix all syntax errors if any.
+2. Run the tests and analyze the results.
+3. If there are issues or failed tests, investigate the root cause.
+4. Create an implementation plan based on findings.
+5. Implement the fix step by step.
+6. Test the fix and make sure it works.
+7. Review the code changes and make sure it meets requirements.
+8. If there are issues or failed tests, repeat from step 2.
+9. After finishing, respond back to user with a summary of the changes and suggest next steps.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-fix` | Analyze and fix issues |
+| `/ck-git` | Commit changes |

package/templates/repo/.github/prompts/ck-fix-types.prompt.md

@@ -0,0 +1,29 @@
+---
+agent: 'agent'
+description: 'Fix type errors'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-types` is an internal mode for TypeScript type errors — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-types` is an internal mode for TypeScript type errors — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run  immediately — do NOT ask user to re-enter their input.
+
+
+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/repo/.github/prompts/ck-fix-ui.prompt.md

@@ -0,0 +1,50 @@
+---
+agent: 'agent'
+description: 'Analyze and fix UI issues'
+argument-hint: 'Describe the UI issue'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-fix-ui` is an internal mode for UI/UX issues — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-fix-ui` is an internal mode for UI/UX issues — it is meant to be selected automatically by AI when you run `/ck-fix`.
+You don't need to call this directly. Just use `/ck-fix` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-fix`? **[Continue / Switch to /ck-fix]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-fix", run  immediately — do NOT ask user to re-enter their input.
+
+
+## Required Skills
+1. **`frontend-design`** - Design patterns and implementation
+
+Read and analyze `./docs/design-guidelines.md` then fix the following issues:
+<issue>${input}</issue>
+
+## Workflow
+1. Activate `frontend-design` skill to understand design patterns and best practices.
+2. Implement the fix step by step following design guidelines.
+3. Take screenshots of the fix and analyze to verify it matches the design guideline and addresses all issues.
+   - If the issues are not addressed, repeat the process until all issues are addressed.
+4. Test the fix and compile the code to make sure it works.
+   - If there are issues or failed tests, fix all of them and repeat until all tests pass.
+5. Final Report:
+   * Summary of changes, guide user to get started, suggest next steps.
+   * Ask the user if they want to commit and push to git repository.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests and analyze results |
+| `/ck-git` | Commit changes |

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

@@ -10,38 +10,35 @@ argument-hint: 'Describe the issues to fix'
 ## Decision Tree
 
 **1. Check for existing plan:**
-- If markdown plan exists → `/ck:code <path-to-plan>`
+- If markdown plan exists → `/ck-cook <path-to-plan>`
 
 **2. Route by issue type:**
 
 **A) Type Errors** (keywords: type, typescript, tsc, type error)
-→ `/ck:fix:types`
+→ `/ck-fix-types`
 
 **B) UI/UX Issues** (keywords: ui, ux, design, layout, style, visual, button, component, css, responsive)
-→ `/ck:fix:ui <detailed-description>`
+→ `/ck-fix-ui <detailed-description>`
 
 **C) CI/CD Issues** (keywords: github actions, pipeline, ci/cd, workflow, deployment, build failed)
-→ `/ck:fix:ci <github-actions-url-or-description>`
+→ `/ck-fix-ci <github-actions-url-or-description>`
 
 **D) Test Failures** (keywords: test, spec, jest, vitest, failing test, test suite)
-→ `/ck:fix:test <detailed-description>`
+→ `/ck-fix-test <detailed-description>`
 
 **E) Log Analysis** (keywords: logs, error logs, log file, stack trace)
-→ `/ck:fix:logs <detailed-description>`
+→ `/ck-fix-logs <detailed-description>`
 
-**F) Multiple Independent Issues** (2+ unrelated issues in different areas)
-→ `/ck:fix:parallel <detailed-description>`
+**F) Complex/Multiple Issues** (keywords: complex, architecture, refactor, major, system-wide, multiple components, 2+ unrelated issues)
+→ `/ck-fix-hard <detailed-description>`
 
-**G) Complex Issues** (keywords: complex, architecture, refactor, major, system-wide, multiple components)
-→ `/ck:fix:hard <detailed-description>`
-
-**H) Simple/Quick Fixes** (default: small bug, single file, straightforward)
-→ `/ck:fix:fast <detailed-description>`
+**G) Simple/Quick Fixes** (default: small bug, single file, straightforward)
+→ `/ck-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 → `/ck:fix:parallel`
+- Can combine routes: e.g., multiple type errors + UI issue → `/ck-fix-hard`
 
 ---
 
@@ -49,4 +46,5 @@ argument-hint: 'Describe the issues to fix'
 
 | Command | Description |
 |---------|-------------|
-| `/ck.test` | Run tests and analyze results |
+| `/ck-test` | Run tests and analyze results |
+| `/ck-git` | Commit changes |

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

@@ -100,5 +100,5 @@ gh pr create --title "type(scope): description" --body "## Summary
 
 | Command | Description |
 |---------|-------------|
-| `/ck.test` | Run tests before push |
-| `/ck.review` | Code review |
+| `/ck-test` | Run tests before push |
+| `/ck-review` | Code review |