cokit-cli 1.0.8 → 1.2.0

package/prompts/ck-debug.prompt.md

@@ -1,14 +1,114 @@
 ---
 agent: 'agent'
-description: 'Debugging technical issues and providing solutions.'
-tools: ['search/codebase', 'search/changes', 'read/problems', 'read/terminalLastCommand']
+description: 'Debug systematically with root cause analysis before fixes'
+argument-hint: 'Describe the issue to debug'
 ---
 
-**Reported Issues**:
-${input}
+## Context
+Issue to debug:
+<issue>${input}</issue>
 
-find the root cause of the issues, then analyze and explain the reports to the user.
+## Core Principle
 
-**IMPORTANT**: **Do not** implement the fix automatically.
-**IMPORTANT:** 
-**IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+**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 |

package/prompts/ck-docs.prompt.md

@@ -0,0 +1,101 @@
+---
+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 |

package/prompts/ck-fix.prompt.md

@@ -1,7 +1,7 @@
 ---
 agent: 'agent'
-description: 'Analyze and fix issues [INTELLIGENT ROUTING]'
-tools: ['search/codebase', 'search/changes', 'read/problems', 'read/terminalLastCommand']
+description: 'Analyze and fix issues with intelligent routing'
+argument-hint: 'Describe the issues to fix'
 ---
 
 **Analyze issues and route to specialized fix command:**
@@ -10,35 +10,43 @@ tools: ['search/codebase', 'search/changes', 'read/problems', 'read/terminalLast
 ## Decision Tree
 
 **1. Check for existing plan:**
-- If markdown plan exists →  <path-to-plan>`
+- If markdown plan exists → `/ck:code <path-to-plan>`
 
 **2. Route by issue type:**
 
 **A) Type Errors** (keywords: type, typescript, tsc, type error)
-→ `/fix:types`
+→ `/ck:fix:types`
 
 **B) UI/UX Issues** (keywords: ui, ux, design, layout, style, visual, button, component, css, responsive)
-→ `/fix:ui <detailed-description>`
+→ `/ck:fix:ui <detailed-description>`
 
 **C) CI/CD Issues** (keywords: github actions, pipeline, ci/cd, workflow, deployment, build failed)
-→ `/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)
-→ `/fix:test <detailed-description>`
+→ `/ck:fix:test <detailed-description>`
 
 **E) Log Analysis** (keywords: logs, error logs, log file, stack trace)
-→ `/fix:logs <detailed-description>`
+→ `/ck:fix:logs <detailed-description>`
 
 **F) Multiple Independent Issues** (2+ unrelated issues in different areas)
-→ `/fix:parallel <detailed-description>`
+→ `/ck:fix:parallel <detailed-description>`
 
 **G) Complex Issues** (keywords: complex, architecture, refactor, major, system-wide, multiple components)
-→ `/fix:hard <detailed-description>`
+→ `/ck:fix:hard <detailed-description>`
 
 **H) Simple/Quick Fixes** (default: small bug, single file, straightforward)
-→ `/fix:fast <detailed-description>`
+→ `/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 → `/fix:parallel`
+- Can combine routes: e.g., multiple type errors + UI issue → `/ck:fix:parallel`
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck.test` | Run tests and analyze results |

package/prompts/ck-git.prompt.md

@@ -0,0 +1,104 @@
+---
+agent: 'agent'
+description: 'Git operations with conventional commits'
+argument-hint: 'cm | cp | pr | merge'
+tools: ['execute/runInTerminal', 'execute/getTerminalOutput']
+---
+
+## Context
+Git operation:
+<operation>${input}</operation>
+
+## Arguments
+
+| Arg | Description |
+|-----|-------------|
+| `cm` | Stage files & create commits |
+| `cp` | Stage files, create commits and push |
+| `pr` | Create Pull Request [to-branch] [from-branch] |
+| `merge` | Merge [to-branch] [from-branch] |
+
+**Defaults:**
+- `to-branch`: main
+- `from-branch`: current branch
+
+## Core Workflow
+
+### Step 1: Stage + Analyze
+```bash
+git add -A && git diff --cached --stat && git diff --cached --name-only
+```
+
+### Step 2: Security Check
+Scan for secrets before commit:
+```bash
+git diff --cached | grep -iE "(api[_-]?key|token|password|secret|credential)"
+```
+**If secrets found:** STOP, warn user, suggest `.gitignore`.
+
+### Step 3: Split Decision
+
+**Split commits if:**
+- Different types mixed (feat + fix, code + docs)
+- Multiple scopes (auth + payments)
+- Config/deps + code mixed
+- FILES > 10 unrelated
+
+**Single commit if:**
+- Same type/scope, FILES ≤ 3, LINES ≤ 50
+
+### Step 4: Commit
+```bash
+git commit -m "type(scope): description"
+```
+
+## Commit Types
+
+| Type | Description |
+|------|-------------|
+| `feat` | New feature |
+| `fix` | Bug fix |
+| `docs` | Documentation only |
+| `style` | Formatting, no code change |
+| `refactor` | Code change, no feature/fix |
+| `perf` | Performance improvement |
+| `test` | Adding/updating tests |
+| `chore` | Maintenance tasks |
+
+## Output Format
+```
+✓ staged: N files (+X/-Y lines)
+✓ security: passed
+✓ commit: HASH type(scope): description
+✓ pushed: yes/no
+```
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Secrets detected | Block commit, show files |
+| No changes | Exit cleanly |
+| Push rejected | Suggest `git pull --rebase` |
+| Merge conflicts | Suggest manual resolution |
+
+## Pull Request Format
+
+```bash
+gh pr create --title "type(scope): description" --body "## Summary
+- Change 1
+- Change 2
+
+## Test Plan
+- [ ] Test A
+- [ ] Test B"
+```
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck.test` | Run tests before push |
+| `/ck.review` | Code review |

package/prompts/ck-help.prompt.md

@@ -0,0 +1,140 @@
+---
+agent: 'agent'
+description: 'CoKit usage guide - just type naturally'
+argument-hint: 'Category, command name, or task description'
+tools: ['execute/runInTerminal', 'execute/getTerminalOutput']
+---
+
+Think harder.
+All-in-one ClaudeKit guide. Run the script and present output based on type markers.
+
+## Intent Validation
+
+The script uses keyword matching with smart weighting. After getting results, **validate** against these heuristics:
+
+| Sentence Pattern | Primary Intent | Example |
+|------------------|----------------|---------|
+| `[action verb] my [object]` | The action verb | "commit my changes" → git |
+| `[context] [subject noun]` | The subject noun | "setup notifications" → notifications |
+| `[noun] [noun]` | Last noun (topic) | "discord webhook" → notifications |
+
+**Action verbs** (high intent when first): fix, test, commit, push, build, create, review, deploy, run, check, find, plan, refactor
+
+**Context words** (low intent, modify subject): setup, add, start, new, my, the, configure
+
+**Override script only if:** result clearly mismatches the sentence pattern above. Otherwise trust the algorithm.
+
+## Translation
+
+**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 $HOME/.copilot/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 (~/.copilot/.ck.json) for personal preferences like language, issue prefix style
+- Use local ($HOME/.copilot/.ck.json) 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
+
+- **`/ck.plan` → `/cook`**: Plan first, then execute the plan
+- **`/cook`**: Standalone - plans internally, no separate `/ck.plan` needed
+- **NEVER** suggest `/ck.plan` → `/cook` (cook has its own planning)
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck.brainstorm` | Explore ideas |
+| `/ck.plan` | Create plan |

package/prompts/ck-journal.prompt.md

@@ -0,0 +1,17 @@
+---
+agent: 'agent'
+description: 'Write journal entries from recent changes and memories'
+---
+
+Use the `journal-writer` subagent to explore the memories and recent code changes, and write some journal entries.
+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.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck.brainstorm` | Explore ideas |
+| `/ck.plan` | Create plan |

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

@@ -1,11 +1,11 @@
 ---
 agent: 'agent'
 description: 'No research. Only analyze and create an implementation plan'
-tools: ['search/codebase', 'search/changes', 'read/problems']
+argument-hint: 'Task description or requirements'
 ---
 
 Think.
-
+Activate `planning` skill.
 
 ## Your mission
 <task>
@@ -20,15 +20,24 @@ Check the `## Plan Context` section in the injected context:
 - 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}`
+Use `planner` subagent to:
+1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node $HOME/.copilot/scripts/set-active-plan.cjs {plan-dir}`
    If reusing: Use the active plan path from Plan Context.
-   Make sure you pass the directory path to every  during the process.
+   Make sure you pass the directory path to every subagent 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.
+3. Analyze the codebase by reading `codebase-summary.md`, `code-standards.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.
 
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** After plan creation, you MUST remind the user:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run `/cook {plan-path}` to begin implementation.
+
+This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan.
+
 ## Output Requirements
 
 **Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
@@ -56,48 +65,21 @@ Use  to:
   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.
+- Save the overview access point at `{plan-dir}/ck.plan.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:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
 - **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**: **Do not** start implementing.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck.test` | Run tests and analyze results |
+| `/ck.fix` | Analyze and fix issues |