cokit-cli 1.0.8 → 1.2.0

package/skills/ck-planning/SKILL.md

@@ -1,112 +0,0 @@
----
-name: 'ck-planning'
-description: 'Use when you need to plan technical solutions that are scalable, secure, and maintainable.'
----
-
-# Planning
-
-Create detailed technical implementation plans through research, codebase analysis, solution design, and comprehensive documentation.
-
-## When to Use
-
-Use this skill when:
-- Planning new feature implementations
-- Architecting system designs
-- Evaluating technical approaches
-- Creating implementation roadmaps
-- Breaking down complex requirements
-- Assessing technical trade-offs
-
-## Core Responsibilities & Rules
-
-Always honoring **YAGNI**, **KISS**, and **DRY** principles.
-**Be honest, be brutal, straight to the point, and be concise.**
-
-### 1. Research & Analysis
-Load: `references/research-phase.md`
-**Skip if:** Provided with researcher reports
-
-### 2. Codebase Understanding
-Load: `references/codebase-understanding.md`
-**Skip if:** Provided with scout reports
-
-### 3. Solution Design
-Load: `references/solution-design.md`
-
-### 4. Plan Creation & Organization
-Load: `references/plan-organization.md`
-
-### 5. Task Breakdown & Output Standards
-Load: `references/output-standards.md`
-
-## Workflow Process
-
-1. **Initial Analysis** → Read codebase docs, understand context
-2. **Research Phase** → Spawn researchers, investigate approaches
-3. **Synthesis** → Analyze reports, identify optimal solution
-4. **Design Phase** → Create architecture, implementation design
-5. **Plan Documentation** → Write comprehensive plan
-6. **Review & Refine** → Ensure completeness, clarity, actionability
-
-## Output Requirements
-
-- DO NOT implement code - only create plans
-- Respond with plan file path and summary
-- Ensure self-contained plans with necessary context
-- Include code snippets/pseudocode when clarifying
-- Provide multiple options with trade-offs when appropriate
-- Fully respect the `./docs/development-rules.md` file.
-
-**Plan Directory Structure**
-```
-plans/
-└── {date}-plan-name/
-    ├── research/
-    │   ├── researcher-XX-report.md
-    │   └── ...
-    ├── reports/
-    │   ├── XX-report.md
-    │   └── ...
-    ├── scout/
-    │   ├── scout-XX-report.md
-    │   └── ...
-    ├── plan.md
-    ├── phase-XX-phase-name-here.md
-    └── ...
-```
-
-## Active Plan State
-
-Prevents version proliferation by tracking current working plan via session state.
-
-### Active vs Suggested Plans
-
-Check the `## Plan Context` section cjs` - use for reports
-- **"Suggested: {path}"** = Branch-matched, hint only - do NOT auto-use
-- **"Plan: none"** = No active plan
-
-### Rules
-
-1. **If "Plan:" shows a path**: Ask "Continue with existing plan? [Y/n]"
-2. **If "Suggested:" shows a path**: Inform user, ask if they want to activate or create new
-3. **If "Plan: none"**: Create new plan using naming from `## Naming` section
-4. **Update on create**: Run `node  {plan-dir}`
-
-### Report Output Location
-
-All agents writing reports MUST:
-1. Check `## Naming` section  Active plans use plan-specific reports path
-3. Suggested plans use default reports path (not plan folder)
-
-**Important:** Suggested plans do NOT get plan-specific reports - this prevents pollution of old plan folders.
-
-## Quality Standards
-
-- Be thorough and specific
-- Consider long-term maintainability
-- Research thoroughly when uncertain
-- Address security and performance concerns
-- Make plans detailed enough for junior developers
-- Validate against existing codebase patterns
-
-**Remember:** Plan quality determines implementation success. Be comprehensive and consider all solution aspects.

package/skills/ck-planning/references/output-standards.md

@@ -1,127 +0,0 @@
-# Output Standards & Quality
-
-## Plan File Format
-
-### YAML Frontmatter (Required for plan.md)
-
-All `plan.md` files MUST include YAML frontmatter at the top:
-
-```yaml
----
-title: "{Brief plan title}"
-description: "{One-sentence summary for card preview}"
-status: pending  # pending | in-progress | completed | cancelled
-priority: P2     # P1 (High) | P2 (Medium) | P3 (Low)
-effort: 4h       # Estimated total effort
-issue: 74        # GitHub issue number (if applicable)
-branch: kai/feat/feature-name
-tags: [frontend, api]  # Category tags
-created: 2025-12-16
----
-```
-
-### Auto-Population Rules
-
-When creating plans, auto-populate these fields:
-- **title**: Extract from task description
-- **description**: First sentence of Overview section
-- **status**: Always `pending` for new plans
-- **priority**: From user request or default `P2`
-- **effort**: Sum of phase estimates
-- **issue**: Parse from branch name or context
-- **branch**: Current git branch (`git branch --show-current`)
-- **tags**: Infer from task keywords (e.g., frontend, backend, api, auth)
-- **created**: Today's date in YYYY-MM-DD format
-
-### Tag Vocabulary (Recommended)
-
-Use these predefined tags for consistency:
-- **Type**: `feature`, `bugfix`, `refactor`, `docs`, `infra`
-- **Domain**: `frontend`, `backend`, `database`, `api`, `auth`
-- **Scope**: `critical`, `tech-debt`, `experimental`
-
-## Task Breakdown
-
-- Transform complex requirements into manageable, actionable tasks
-- Each task independently executable with clear dependencies
-- Prioritize by dependencies, risk, business value
-- Eliminate ambiguity in instructions
-- Include specific file paths for all modifications
-- Provide clear acceptance criteria per task
-
-### File Management
-List affected files with:
-- Full paths (not relative)
-- Action type (modify/create/delete)
-- Brief change description
-- Dependencies on other changes
-- Fully respect the `./docs/development-rules.md` file.
-
-## Workflow Process
-
-1. **Initial Analysis** → Read docs, understand context
-2. **Research Phase** → Spawn researchers in parallel, investigate approaches
-3. **Synthesis** → Analyze reports, identify optimal solution
-4. **Design Phase** → Create architecture, implementation design
-5. **Plan Documentation** → Write comprehensive plan in Markdown
-6. **Review & Refine** → Ensure completeness, clarity, actionability
-
-## Output Requirements
-
-### What Planners Do
-- Create plans ONLY (no implementation)
-- Provide plan file path and summary
-- Self-contained plans with necessary context
-- Code snippets/pseudocode when clarifying
-- Multiple options with trade-offs when appropriate
-- Fully respect the `./docs/development-rules.md` file.
-
-### Writing Style
-**IMPORTANT:** Sacrifice grammar for concision
-- Focus clarity over eloquence
-- Use bullets and lists
-- Short sentences
-- Remove unnecessary words
-- Prioritize actionable info
-
-### Unresolved Questions
-**IMPORTANT:** List unresolved questions at end
-- Questions needing clarification
-- Technical decisions requiring input
-- Unknowns impacting implementation
-- Trade-offs requiring business decisions
-
-## Quality Standards
-
-### Thoroughness
-- Thorough and specific in research/planning
-- Consider edge cases, failure modes
-- Think through entire user journey
-- Document all assumptions
-
-### Maintainability
-- Consider long-term maintainability
-- Design for future modifications
-- Document decision rationale
-- Avoid over-engineering
-- Fully respect the `./docs/development-rules.md` file.
-
-### Research Depth
-- When uncertain, research more
-- Multiple options with clear trade-offs
-- Validate against best practices
-- Consider industry standards
-
-### Security & Performance
-- Address all security concerns
-- Identify performance implications
-- Plan for scalability
-- Consider resource constraints
-
-### Implementability
-- Detailed enough for junior developers
-- Validate against existing patterns
-- Ensure codebase standards consistency
-- Provide clear examples
-
-**Remember:** Plan quality determines implementation success. Be comprehensive, consider all solution aspects.

package/skills/ck-planning/references/plan-organization.md

@@ -1,150 +0,0 @@
-# Plan Creation & Organization
-
-## Directory Structure
-
-### Plan Location
-Use `Plan dir:` from `## Naming` section injected by hooks. This is the full computed path.
-
-**Example:** `plans/251101-1505-authentication/` or `ai_docs/feature/MRR-1453/`
-
-### File Organization
-
-```
-{plan-dir}/                                    # From `Plan dir:` in ## Naming
-├── research/
-│   ├── researcher-XX-report.md
-│   └── ...
-├── reports/
-│   ├── scout-report.md
-│   ├── researcher-report.md
-│   └── ...
-├── plan.md                                    # Overview access point
-├── phase-01-setup-environment.md              # Setup environment
-├── phase-02-implement-database.md             # Database models
-├── phase-03-implement-api-endpoints.md        # API endpoints
-├── phase-04-implement-ui-components.md        # UI components
-├── phase-05-implement-authentication.md       # Auth & authorization
-├── phase-06-implement-profile.md              # Profile page
-└── phase-07-write-tests.md                    # Tests
-```
-
-### Active Plan State Tracking
-
-Check the `## Plan Context` section injected by hooks:
-- **"Plan: {path}"** = Active plan - use for reports
-- **"Suggested: {path}"** = Branch-matched, hint only - do NOT auto-use
-- **"Plan: none"** = No active plan
-
-**Pre-Creation Check:**
-1. If "Plan:" shows a path → ask "Continue with existing plan? [Y/n]"
-2. If "Suggested:" shows a path → inform user (hint only, do NOT auto-use)
-3. If "Plan: none" → create new plan using naming from `## Naming` section
-
-**After Creating Plan:**
-```bash
-# Update session state so subagents get the new plan context:
-node %USERPROFILE%/.claude/scripts/set-active-plan.cjs {plan-dir}
-```
-
-**Report Output Rules:**
-1. Use `Report:` and `Plan dir:` from `## Naming` section
-2. Active plans use plan-specific reports path
-3. Suggested plans use default reports path to prevent old plan pollution
-
-## File Structure
-
-### Overview Plan (plan.md)
-
-**IMPORTANT:** All plan.md files MUST include YAML frontmatter. See `output-standards.md` for schema.
-
-**Example plan.md structure:**
-```markdown
----
-title: "Feature Implementation Plan"
-description: "Add user authentication with OAuth2 support"
-status: pending
-priority: P1
-effort: 8h
-issue: 123
-branch: kai/feat/oauth-auth
-tags: [auth, backend, security]
-created: 2025-12-16
----
-
-# Feature Implementation Plan
-
-## Overview
-
-Brief description of what this plan accomplishes.
-
-## Phases
-
-| # | Phase | Status | Effort | Link |
-|---|-------|--------|--------|------|
-| 1 | Setup | Pending | 2h | [phase-01](./phase-01-setup.md) |
-| 2 | Implementation | Pending | 4h | [phase-02](./phase-02-impl.md) |
-| 3 | Testing | Pending | 2h | [phase-03](./phase-03-test.md) |
-
-## Dependencies
-
-- List key dependencies here
-```
-
-**Guidelines:**
-- Keep generic and under 80 lines
-- List each phase with status/progress
-- Link to detailed phase files
-- Key dependencies
-
-### Phase Files (phase-XX-name.md)
-Fully respect the `./docs/development-rules.md` file.
-Each phase file should contain:
-
-**Context Links**
-- Links to related reports, files, documentation
-
-**Overview**
-- Priority
-- Current status
-- Brief description
-
-**Key Insights**
-- Important findings from research
-- Critical considerations
-
-**Requirements**
-- Functional requirements
-- Non-functional requirements
-
-**Architecture**
-- System design
-- Component interactions
-- Data flow
-
-**Related Code Files**
-- List of files to modify
-- List of files to create
-- List of files to delete
-
-**Implementation Steps**
-- Detailed, numbered steps
-- Specific instructions
-
-**Todo List**
-- Checkbox list for tracking
-
-**Success Criteria**
-- Definition of done
-- Validation methods
-
-**Risk Assessment**
-- Potential issues
-- Mitigation strategies
-
-**Security Considerations**
-- Auth/authorization
-- Data protection
-
-**Next Steps**
-- Dependencies
-- Follow-up tasks

package/skills/ck-problem-solving/SKILL.md

@@ -1,95 +0,0 @@
----
-name: 'ck-problem-solving'
-description: 'Apply systematic problem-solving techniques for complexity spirals (simplification cascades), innovation blocks (collision-zone thinking), recurring patterns (meta-pattern recognition), assumption constraints (inversion exercise), scale uncertainty (scale game), and dispatch when stuck. Techniques derived from Microsoft Amplifier project patterns adapted for immediate application.'
----
-
-# Problem-Solving Techniques
-
-Systematic approaches for different types of stuck-ness. Each technique targets specific problem patterns.
-
-## When to Use
-
-Apply when encountering:
-- **Complexity spiraling** - Multiple implementations, growing special cases, excessive branching
-- **Innovation blocks** - Conventional solutions inadequate, need breakthrough thinking
-- **Recurring patterns** - Same issue across domains, reinventing solutions
-- **Assumption constraints** - Forced into "only way", can't question premise
-- **Scale uncertainty** - Production readiness unclear, edge cases unknown
-- **General stuck-ness** - Unsure which technique applies
-
-## Quick Dispatch
-
-**Match symptom to technique:**
-
-| Stuck Symptom | Technique | Reference |
-|---------------|-----------|-----------|
-| Same thing implemented 5+ ways, growing special cases | **Simplification Cascades** | `references/simplification-cascades.md` |
-| Conventional solutions inadequate, need breakthrough | **Collision-Zone Thinking** | `references/collision-zone-thinking.md` |
-| Same issue in different places, reinventing wheels | **Meta-Pattern Recognition** | `references/meta-pattern-recognition.md` |
-| Solution feels forced, "must be done this way" | **Inversion Exercise** | `references/inversion-exercise.md` |
-| Will this work at production? Edge cases unclear? | **Scale Game** | `references/scale-game.md` |
-| Unsure which technique to use | **When Stuck** | `references/when-stuck.md` |
-
-## Core Techniques
-
-### 1. Simplification Cascades
-Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."
-
-**Key insight:** Everything is a special case of one general pattern.
-
-**Red flag:** "Just need to add one more case..." (repeating forever)
-
-### 2. Collision-Zone Thinking
-Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
-
-**Key insight:** Revolutionary ideas from deliberate metaphor-mixing.
-
-**Red flag:** "I've tried everything in this domain"
-
-### 3. Meta-Pattern Recognition
-Spot patterns appearing in 3+ domains to find universal principles.
-
-**Key insight:** Patterns in how patterns emerge reveal reusable abstractions.
-
-**Red flag:** "This problem is unique" (probably not)
-
-### 4. Inversion Exercise
-Flip core assumptions to reveal hidden constraints. "What if the opposite were true?"
-
-**Key insight:** Valid inversions reveal context-dependence of "rules."
-
-**Red flag:** "There's only one way to do this"
-
-### 5. Scale Game
-Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths.
-
-**Key insight:** What works at one scale fails at another.
-
-**Red flag:** "Should scale fine" (without testing)
-
-## Application Process
-
-1. **Identify stuck-type** - Match symptom to technique above
-2. **Load detailed reference** - Read specific technique from `references/`
-3. **Apply systematically** - Follow technique's process
-4. **Document insights** - Record what worked/failed
-5. **Combine if needed** - Some problems need multiple techniques
-
-## Combining Techniques
-
-Powerful combinations:
-- **Simplification + Meta-pattern** - Find pattern, then simplify all instances
-- **Collision + Inversion** - Force metaphor, then invert its assumptions
-- **Scale + Simplification** - Extremes reveal what to eliminate
-- **Meta-pattern + Scale** - Universal patterns tested at extremes
-
-## References
-
-Load detailed guides as needed:
-- `references/when-stuck.md` - Dispatch flowchart and decision tree
-- `references/simplification-cascades.md` - Cascade detection and extraction
-- `references/collision-zone-thinking.md` - Metaphor collision process
-- `references/meta-pattern-recognition.md` - Pattern abstraction techniques
-- `references/inversion-exercise.md` - Assumption flipping methodology
-- `references/scale-game.md` - Extreme testing procedures
-- `references/attribution.md` - Source and adaptation notes