cokit-cli 1.0.8 → 1.0.9

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

@@ -1,150 +1,150 @@
-# 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
+# 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:
+# Update plan context via session state management
+```
+
+**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-planning/references/research-phase.md

@@ -1,49 +1,49 @@
-# Research & Analysis Phase
-
-**When to skip:** If provided with researcher reports, skip this phase.
-
-## Core Activities
-
-### Parallel Researcher Agents
-- Spawn multiple `researcher` agents in parallel to investigate different approaches
-- Wait for all researcher agents to report back before proceeding
-- Each researcher investigates a specific aspect or approach
-
-### Sequential Thinking
-- Use `sequential-thinking` skill for dynamic and reflective problem-solving
-- Structured thinking process for complex analysis
-- Enables multi-step reasoning with revision capability
-
-### Documentation Research
-- Use `docs-seeker` skill to read and understand documentation
-- Research plugins, packages, and frameworks
-- Find latest technical documentation using llms.txt standard
-
-### GitHub Analysis
-- Use `gh` command to read and analyze:
-  - GitHub Actions logs
-  - Pull requests
-  - Issues and discussions
-- Extract relevant technical context from GitHub resources
-
-### Remote Repository Analysis
-When given GitHub repository URL, generate fresh codebase summary:
-```bash
-# usage: 
-repomix --remote <github-repo-url>
-# example: 
-repomix --remote https://github.com/mrgoonie/human-mcp
-```
-
-### Debugger Delegation
-- Delegate to `debugger` agent for root cause analysis
-- Use when investigating complex issues or bugs
-- Debugger agent specializes in diagnostic tasks
-
-## Best Practices
-
-- Research breadth before depth
-- Document findings for synthesis phase
-- Identify multiple approaches for comparison
-- Consider edge cases during research
-- Note security implications early
+# Research & Analysis Phase
+
+**When to skip:** If provided with researcher reports, skip this phase.
+
+## Core Activities
+
+### Parallel Researcher Agents
+- Spawn multiple `researcher` agents in parallel to investigate different approaches
+- Wait for all researcher agents to report back before proceeding
+- Each researcher investigates a specific aspect or approach
+
+### Sequential Thinking
+- Use `sequential-thinking` skill for dynamic and reflective problem-solving
+- Structured thinking process for complex analysis
+- Enables multi-step reasoning with revision capability
+
+### Documentation Research
+- Use `docs-seeker` skill to read and understand documentation
+- Research plugins, packages, and frameworks
+- Find latest technical documentation using llms.txt standard
+
+### GitHub Analysis
+- Use `gh` command to read and analyze:
+  - GitHub Actions logs
+  - Pull requests
+  - Issues and discussions
+- Extract relevant technical context from GitHub resources
+
+### Remote Repository Analysis
+When given GitHub repository URL, generate fresh codebase summary:
+```bash
+# usage: 
+repomix --remote <github-repo-url>
+# example: 
+repomix --remote https://github.com/mrgoonie/human-mcp
+```
+
+### Debugger Delegation
+- Delegate to `debugger` agent for root cause analysis
+- Use when investigating complex issues or bugs
+- Debugger agent specializes in diagnostic tasks
+
+## Best Practices
+
+- Research breadth before depth
+- Document findings for synthesis phase
+- Identify multiple approaches for comparison
+- Consider edge cases during research
+- Note security implications early

package/skills/ck-planning/references/solution-design.md

@@ -1,63 +1,63 @@
-# Solution Design
-
-## Core Principles
-
-Follow these fundamental principles:
-- **YAGNI** (You Aren't Gonna Need It) - Don't add functionality until necessary
-- **KISS** (Keep It Simple, Stupid) - Prefer simple solutions over complex ones
-- **DRY** (Don't Repeat Yourself) - Avoid code duplication
-
-## Design Activities
-
-### Technical Trade-off Analysis
-- Evaluate multiple approaches for each requirement
-- Compare pros and cons of different solutions
-- Consider short-term vs long-term implications
-- Balance complexity with maintainability
-- Assess development effort vs benefit
-- Recommend optimal solution based on current best practices
-
-### Security Assessment
-- Identify potential vulnerabilities during design phase
-- Consider authentication and authorization requirements
-- Assess data protection needs
-- Evaluate input validation requirements
-- Plan for secure configuration management
-- Address OWASP Top 10 concerns
-- Consider API security (rate limiting, CORS, etc.)
-
-### Performance & Scalability
-- Identify potential bottlenecks early
-- Consider database query optimization needs
-- Plan for caching strategies
-- Assess resource usage (memory, CPU, network)
-- Design for horizontal/vertical scaling
-- Plan for load distribution
-- Consider asynchronous processing where appropriate
-
-### Edge Cases & Failure Modes
-- Think through error scenarios
-- Plan for network failures
-- Consider partial failure handling
-- Design retry and fallback mechanisms
-- Plan for data consistency
-- Consider race conditions
-- Design for graceful degradation
-
-### Architecture Design
-- Create scalable system architectures
-- Design for maintainability
-- Plan component interactions
-- Design data flow
-- Consider microservices vs monolith trade-offs
-- Plan API contracts
-- Design state management
-
-## Best Practices
-
-- Document design decisions and rationale
-- Consider both technical and business requirements
-- Think through the entire user journey
-- Plan for monitoring and observability
-- Design with testing in mind
-- Consider deployment and rollback strategies
+# Solution Design
+
+## Core Principles
+
+Follow these fundamental principles:
+- **YAGNI** (You Aren't Gonna Need It) - Don't add functionality until necessary
+- **KISS** (Keep It Simple, Stupid) - Prefer simple solutions over complex ones
+- **DRY** (Don't Repeat Yourself) - Avoid code duplication
+
+## Design Activities
+
+### Technical Trade-off Analysis
+- Evaluate multiple approaches for each requirement
+- Compare pros and cons of different solutions
+- Consider short-term vs long-term implications
+- Balance complexity with maintainability
+- Assess development effort vs benefit
+- Recommend optimal solution based on current best practices
+
+### Security Assessment
+- Identify potential vulnerabilities during design phase
+- Consider authentication and authorization requirements
+- Assess data protection needs
+- Evaluate input validation requirements
+- Plan for secure configuration management
+- Address OWASP Top 10 concerns
+- Consider API security (rate limiting, CORS, etc.)
+
+### Performance & Scalability
+- Identify potential bottlenecks early
+- Consider database query optimization needs
+- Plan for caching strategies
+- Assess resource usage (memory, CPU, network)
+- Design for horizontal/vertical scaling
+- Plan for load distribution
+- Consider asynchronous processing where appropriate
+
+### Edge Cases & Failure Modes
+- Think through error scenarios
+- Plan for network failures
+- Consider partial failure handling
+- Design retry and fallback mechanisms
+- Plan for data consistency
+- Consider race conditions
+- Design for graceful degradation
+
+### Architecture Design
+- Create scalable system architectures
+- Design for maintainability
+- Plan component interactions
+- Design data flow
+- Consider microservices vs monolith trade-offs
+- Plan API contracts
+- Design state management
+
+## Best Practices
+
+- Document design decisions and rationale
+- Consider both technical and business requirements
+- Think through the entire user journey
+- Plan for monitoring and observability
+- Design with testing in mind
+- Consider deployment and rollback strategies