cokit-cli 1.0.9 → 1.2.2

package/prompts/ck-cook.prompt.md

@@ -1,97 +1,96 @@
----
-agent: 'agent'
-description: 'Implement a feature [step by step]'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'web/githubRepo', 'read/terminalLastCommand']
----
-
-Think harder to plan & start working on these tasks follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules:
-<tasks>${input}</tasks>
-
----
-
-## 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  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**: Ask probing questions to fully understand the user's request, constraints, and true objectives. 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. 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.
-
-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.
-
-5. **Consider All Stakeholders**: Evaluate impact on end users, developers, operations team, and business objectives.
-
----
-
-## Workflow:
-
-### Fullfill the request
-
-* If you have any questions, ask the user to clarify them.
-* 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.
-
-
-* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
-*  analyze reports from `researcher` and s to create an implementation plan using 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).
-
-### Implementation
-
-* Use   to implement the plan step by step, follow the implementation plan in `.s` directory.
-* implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
-  * Use `media-processing` skill for image editing (crop, resize, remove background) if 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, mocks, cheats, tricks, temporary solutions, just to pass the build or github actions**, tests should be real and cover all possible cases.
-* run the tests, make sure it works, .
-* If there are issues or failed tests, 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, 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 "Testing" 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.
-
-### 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.
-
-### Onboarding
-
-* Instruct the user to get started with the feature if needed (for example: grab the API key, set up the environment variables, etc).
-* Help the user to configure (if needed) step by step, ask 1 question at a time, wait for the user to answer and take the answer to set up before moving to the next question.
-* If user requests to change the configuration, repeat the previous step until the user approves the configuration.
-
-### 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 changes to git repository, if yes, commit 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.
-- **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 or similar tools as needed.
+---
+agent: 'agent'
+description: 'Smart feature implementation with automatic workflow detection'
+argument-hint: 'Task description or path to plan file'
+---
+
+## Context
+Task or plan path:
+<task>${input}</task>
+
+**Principles:** YAGNI, KISS, DRY | Token efficiency | Concise reports
+
+## Smart Intent Detection
+
+| Input Pattern | Detected Mode | Behavior |
+|---------------|---------------|----------|
+| Path to `plan.md` or `phase-*.md` | code | Execute existing plan |
+| Contains "fast", "quick" | fast | Skip research, scout→plan→code |
+| Contains "trust me", "auto" | auto | Auto-approve all steps |
+| Lists 3+ features OR "parallel" | parallel | Multi-agent execution |
+| Contains "no test", "skip test" | no-test | Skip testing step |
+| Default | interactive | Full workflow with user input |
+
+## Workflow Overview
+
+```
+[Intent Detection] → [Research?] → [Review] → [Plan] → [Review] → [Implement] → [Simplify] → [Review] → [Test?] → [Review] → [Finalize]
+```
+
+**Default (non-auto):** Stops at `[Review]` gates for human approval before each major step.
+**Auto mode (`--auto`):** Skips human review gates, implements all phases continuously.
+
+| Mode | Research | Testing | Review Gates | Phase Progression |
+|------|----------|---------|--------------|-------------------|
+| interactive | ✓ | ✓ | **User approval at each step** | One at a time |
+| auto | ✓ | ✓ | Auto if score≥9.5 | All at once (no stops) |
+| fast | ✗ | ✓ | User approval at each step | One at a time |
+| parallel | Optional | ✓ | User approval at each step | Parallel groups |
+| no-test | ✓ | ✗ | User approval at each step | One at a time |
+| code | ✗ | ✓ | User approval at each step | Per plan |
+
+## Step Output Format
+
+```
+✓ Step [N]: [Brief status] - [Key metrics]
+```
+
+## Blocking Gates (Non-Auto Mode)
+
+Human review required at these checkpoints (skipped with `--auto`):
+- **Post-Research:** Review findings before planning
+- **Post-Plan:** Approve plan before implementation
+- **Post-Implementation:** Approve code before testing
+- **Post-Testing:** 100% pass + approve before finalize
+
+**Always enforced (all modes):**
+- **Testing:** 100% pass required (unless no-test mode)
+- **Code Review:** User approval OR auto-approve (score≥9.5, 0 critical)
+- **Finalize:** project-manager AND docs-manager must complete
+
+## Required Agents
+
+| Phase | Agent |
+|-------|-------|
+| Research | `@researcher` (parallel, optional in fast) |
+| Scout | `@scout` |
+| Plan | `@planner` |
+| UI Work | `@ui-ux-designer` |
+| Implement | `@fullstack-developer` (parallel mode) |
+| Simplify | `@code-simplifier` (post-implement) |
+| Testing | `@tester`, `@debugger` |
+| Review | `@code-reviewer` |
+| Finalize | `project-manager`, `@docs-manager`, `@git-manager` |
+
+## Process
+
+1. **Detect Mode**: Analyze input to determine workflow mode
+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)
+6. **Simplify**: `@code-simplifier` refines implemented code for clarity
+7. **Test**: Run tests and validate
+8. **Review**: Code review with quality gates
+9. **Finalize**: Update docs, commit changes
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests |
+| `/ck-review` | Code review |
+| `/ck-git` | Commit changes |
+| `/ck-spec-implement` | Spec-driven implementation instead |

package/prompts/ck-debug.prompt.md

@@ -1,14 +1,115 @@
----
-agent: 'agent'
-description: 'Debugging technical issues and providing solutions.'
-tools: ['search/codebase', 'search/changes', 'read/problems', 'read/terminalLastCommand']
----
-
-**Reported Issues**:
-${input}
-
-find the root cause of the issues, then analyze and explain the reports to the user.
-
-**IMPORTANT**: **Do not** implement the fix automatically.
-**IMPORTANT:** 
-**IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+---
+agent: 'agent'
+description: 'Debug systematically with root cause analysis before fixes'
+argument-hint: 'Describe the issue to debug'
+---
+
+## Context
+Issue to debug:
+<issue>${input}</issue>
+
+## Core Principle
+
+**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST**
+
+Random fixes waste time and create new bugs. Find the root cause, fix at source, validate at every layer, verify before claiming success.
+
+## When to Use
+
+**Always use for:** Test failures, bugs, unexpected behavior, performance issues, build failures, integration problems, before claiming work complete
+
+**Especially when:** Under time pressure, "quick fix" seems obvious, tried multiple fixes, don't fully understand issue, about to claim success
+
+## The Four Phases
+
+### Phase 1: Root Cause Investigation
+1. Read error messages completely
+2. Reproduce the issue consistently
+3. Check recent changes (git diff, git log)
+4. Gather evidence before theorizing
+
+### Phase 2: Pattern Analysis
+1. Find working examples in codebase
+2. Compare working vs broken code
+3. Identify what's different
+4. Document findings
+
+### Phase 3: Hypothesis and Testing
+1. Form theory based on evidence
+2. Test with minimal changes
+3. Verify hypothesis is correct
+4. Document confirmation
+
+### Phase 4: Implementation
+1. Create test that catches the bug
+2. Fix at the root cause (not symptom)
+3. Verify fix works
+4. Ensure no regressions
+
+**Key rule:** Complete each phase before proceeding. No fixes without Phase 1.
+
+## Root Cause Tracing
+
+When error appears deep in execution:
+1. Start at error location
+2. Trace backward level-by-level
+3. Find where invalid data originated
+4. Fix at source, not at symptom
+
+## Defense-in-Depth
+
+After finding root cause, validate at every layer:
+1. **Entry validation** - Input sanitization
+2. **Business logic** - State validation
+3. **Environment guards** - Config validation
+4. **Debug instrumentation** - Logging
+
+## Verification
+
+**Iron law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+
+1. Run the command
+2. Read the output
+3. Then claim the result
+
+## Red Flags
+
+Stop and follow process if thinking:
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- "It's probably X, let me fix that"
+- "Should work now" / "Seems fixed"
+- "Tests pass, we're done"
+
+**All mean:** Return to systematic process.
+
+## Output Format
+
+```markdown
+## Debug Report
+
+### Issue Summary
+- What: [Brief description]
+- When: [When it occurs]
+- Impact: [Severity]
+
+### Root Cause
+[Explanation of actual cause]
+
+### Fix Applied
+[What was changed and why]
+
+### Verification
+[Evidence that fix works]
+```
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-test` | Run tests to verify |
+| `/ck-fix` | Apply fix |
+| `/ck-git` | Commit fix |
+| `/ck-spec-analyze` | Analyze spec consistency |

package/prompts/ck-docs.prompt.md

@@ -1,51 +1,102 @@
----
-agent: 'agent'
-description: 'Documentation workflow - init, summarize, or update docs'
-tools: ['search/codebase', 'search/changes']
----
-
-# Documentation Workflow
-
-## Usage
-
-- `/ck-docs` or `/ck-docs init` - Create initial documentation
-- `/ck-docs summarize [topics]` - Summarize codebase documentation
-- `/ck-docs update` - Update existing documentation
-
-## Commands
-
-### init (default)
-Analyze codebase and create initial documentation:
-
-1. **Scout codebase** - Run `ls -la` to identify project directories
-2. **Create docs** in `docs/` directory:
-   - `project-overview-pdr.md` - Project overview and PDR
-   - `codebase-summary.md` - Codebase summary
-   - `code-standards.md` - Code structure and standards
-   - `system-architecture.md` - System architecture
-3. **Update** `README.md` (keep under 300 lines)
-
-### summarize [topics]
-Analyze codebase based on `./docs/codebase-summary.md` and respond with summary report.
-
-Arguments:
-- `topics` - Focused topics (default: all)
-
-### update
-Analyze codebase and update existing documentation:
-
-1. **Scout codebase** for changes
-2. **Update docs** in `docs/` directory:
-   - `README.md` (keep under 300 lines)
-   - `project-overview-pdr.md`
-   - `codebase-summary.md`
-   - `code-standards.md`
-   - `system-architecture.md`
-   - `project-roadmap.md`
-   - `deployment-guide.md` [optional]
-   - `design-guidelines.md` [optional]
-
-## Notes
-- Use `docs/` directory as source of truth
-- Do not scan entire codebase unless explicitly requested
-- **DO NOT** start implementing - documentation only
+---
+agent: 'agent'
+description: 'Search library/framework documentation via context7'
+argument-hint: 'Library name or documentation query'
+tools: ['web/fetch']
+---
+
+## Context
+Documentation query:
+<query>${input}</query>
+
+## Your Role
+
+Search and retrieve up-to-date documentation for libraries, frameworks, and packages using context7.com llms.txt standard.
+
+## When to Use
+
+- Need API documentation for a library
+- Looking for code examples and patterns
+- Checking latest features or deprecations
+- Understanding library configuration
+- Finding best practices for a framework
+
+## Workflow
+
+### 1. Detect Query Type
+
+**Topic-specific query** (e.g., "How do I use date picker in shadcn?")
+- Extract: library name + topic keyword
+- Faster search path: 2-3 URLs
+
+**General library query** (e.g., "Documentation for Next.js")
+- Comprehensive search: 8+ URLs
+- May need multiple agents
+
+### 2. Search Strategy
+
+**For topic-specific queries:**
+1. Search context7 for library + topic
+2. Retrieve 2-3 most relevant URLs
+3. Read and summarize findings
+
+**For general queries:**
+1. Search context7 for library
+2. Analyze URL list for categorization
+3. Prioritize: critical > important > supplementary
+4. Deploy parallel reads if many URLs
+
+### 3. URL Priority
+
+| Category | Examples | Priority |
+|----------|----------|----------|
+| Critical | Getting started, core API | Read first |
+| Important | Configuration, common patterns | Read second |
+| Supplementary | Advanced, edge cases | Read if needed |
+
+## Output Format
+
+```markdown
+## Documentation Summary
+
+### Library: [Name] v[Version]
+
+### Quick Answer
+[Direct answer to user's question]
+
+### Key Points
+- Point 1
+- Point 2
+- Point 3
+
+### Code Example
+```language
+// Relevant code example
+```
+
+### Related Topics
+- [Topic 1](url)
+- [Topic 2](url)
+
+### Sources
+- [Doc Title](url)
+```
+
+## Best Practices
+
+1. **Be specific** - Include version numbers when relevant
+2. **Show examples** - Code examples are more useful than descriptions
+3. **Note deprecations** - Warn about deprecated APIs
+4. **Link sources** - Always provide source URLs
+5. **Stay current** - Prefer latest documentation
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-ask` | Ask technical questions |
+| `/ck-plan` | Create implementation plan |
+| `/ck-cook` | Implement feature |
+| `/ck-spec-specify` | Write detailed feature spec |

package/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/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/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 |