cokit-cli 1.0.0 → 1.0.2

package/skills/code-review/SKILL.md

@@ -1,86 +0,0 @@
----
-name: code-review
-description: Code review practices with technical rigor and verification. Use when receiving feedback, completing features, or before claiming work complete.
----
-
-# Code Review
-
-Guide proper code review practices emphasizing technical rigor and verification.
-
-## Core Principles
-
-- **YAGNI**, **KISS**, **DRY**
-- Technical correctness over social comfort
-- Evidence before claims
-
-## When to Use
-
-### Receiving Feedback
-- Code review comments arrive
-- Feedback seems unclear or questionable
-- Suggestion conflicts with existing decisions
-
-### Requesting Review
-- After completing major features
-- Before merging to main
-- After fixing complex bugs
-
-### Verification Gates
-- About to claim work is complete
-- Before committing or pushing
-- Moving to next task
-
-## Receiving Feedback Protocol
-
-**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND
-
-### Key Rules
-- No performative agreement ("Great point!", "You're right!")
-- Verify technically before implementing
-- Push back with reasoning if wrong
-- Ask for clarification on ALL unclear items first
-
-### YAGNI Check
-Before implementing suggested "improvements":
-- Grep for actual usage
-- Is it needed now?
-- Does it add complexity?
-
-## Requesting Review Checklist
-
-Before requesting review:
-- [ ] Code compiles/lints clean
-- [ ] Tests pass (fresh run)
-- [ ] Changes focused and minimal
-- [ ] No unrelated changes
-
-During review focus on:
-- Security vulnerabilities
-- Error handling completeness
-- Test coverage adequacy
-- Performance implications
-
-## Verification Gates
-
-**Iron Law:** NO COMPLETION CLAIMS WITHOUT VERIFICATION
-
-### Process
-1. Identify verification command
-2. Run full command
-3. Read actual output
-4. Verify confirms claim
-5. Then (and only then) claim
-
-### Red Flags
-Stop if using:
-- "should work"
-- "seems fixed"
-- "probably passing"
-
-These mean: RUN VERIFICATION FIRST
-
-## References
-
-See `./references/` for detailed protocols:
-- `code-review-reception.md` - Handling feedback
-- `verification-before-completion.md` - Verification gates

package/skills/code-review/references/code-review-reception.md

@@ -1,76 +0,0 @@
-# Code Review Reception
-
-How to properly receive and respond to code review feedback.
-
-## Response Pattern
-
-READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
-
-## Step 1: Read
-
-- Read entire comment
-- Note specific concerns
-- Identify any questions
-
-## Step 2: Understand
-
-- What exactly is being asked?
-- What's the underlying concern?
-- Is context missing?
-
-## Step 3: Verify
-
-- Is the concern technically valid?
-- Does the suggestion work?
-- Would it break anything?
-
-## Step 4: Evaluate
-
-- Does it improve the code?
-- Is it necessary now (YAGNI)?
-- Worth the complexity?
-
-## Step 5: Respond
-
-Options:
-- **Implement:** If valid and valuable
-- **Push back:** If technically incorrect
-- **Clarify:** If unclear
-- **Defer:** If valuable but not now
-
-## Anti-Patterns
-
-**Never say:**
-- "You're absolutely right!"
-- "Great catch!"
-- "Thanks for the suggestion!"
-
-These are performative, not technical.
-
-**Instead say:**
-- "Implementing [specific change]"
-- "This would break X because Y"
-- "Can you clarify what you mean by Z?"
-
-## Handling Disagreement
-
-If you disagree:
-1. State your technical reasoning
-2. Provide evidence or examples
-3. Propose alternative if applicable
-4. Accept if they provide better reasoning
-
-## Priority Handling
-
-- **Critical:** Security, data loss, crashes → Fix immediately
-- **Important:** Bugs, performance → Fix before proceeding
-- **Minor:** Style, naming → Note for later
-
-## YAGNI Check
-
-Before implementing "improvements":
-```
-grep -r "feature_name" src/
-```
-
-If no usage found → Push back or defer

package/skills/code-review/references/verification-before-completion.md

@@ -1,86 +0,0 @@
-# Verification Before Completion
-
-Verification gates require evidence before any status claims.
-
-## The Iron Law
-
-**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**
-
-"Should work" is not evidence.
-Run it. Read it. Then claim it.
-
-## Gate Process
-
-1. **IDENTIFY** - What command verifies this claim?
-2. **RUN** - Execute the full command
-3. **READ** - Read the actual output
-4. **VERIFY** - Output confirms claim?
-5. **CLAIM** - Only then state completion
-
-## Common Claims & Verification
-
-### "Tests pass"
-```bash
-npm test
-# Read output - 0 failures?
-```
-
-### "Build succeeds"
-```bash
-npm run build
-# Exit code 0?
-```
-
-### "Bug is fixed"
-```bash
-# Run original failing test
-# Does it pass now?
-```
-
-### "Linting clean"
-```bash
-npm run lint
-# No errors?
-```
-
-## Red Flags
-
-Stop immediately if saying:
-- "should work now"
-- "seems to be fixed"
-- "probably passing"
-- "looks good"
-- "I think it's done"
-
-These mean: **RUN VERIFICATION FIRST**
-
-## Evidence Format
-
-Bad:
-> "Tests pass"
-
-Good:
-> "Tests pass - ran `npm test`, output shows 45/45 passing"
-
-## Before Claiming Complete
-
-Checklist:
-- [ ] Tests pass (fresh run, not cached)
-- [ ] No new warnings
-- [ ] Feature works manually
-- [ ] Edge cases handled
-- [ ] No regressions
-
-## Before Committing
-
-Checklist:
-- [ ] All above verified
-- [ ] No unrelated changes
-- [ ] Commit message accurate
-- [ ] Branch is correct
-
-## Bottom Line
-
-Verify. Then claim.
-Not: Claim. Then verify.
-Not: Claim. Assume verified.

package/skills/debugging/SKILL.md

@@ -1,70 +0,0 @@
----
-name: debugging
-description: Systematic debugging framework with root cause investigation. Use when encountering bugs, test failures, unexpected behavior, or before claiming work complete.
----
-
-# Debugging
-
-Comprehensive debugging framework combining systematic investigation and verification.
-
-## Core Principle
-
-**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST**
-
-Random fixes waste time and create new bugs. Find the root cause, fix at source, verify before claiming success.
-
-## When to Use
-
-- Test failures or bugs
-- Unexpected behavior
-- Performance issues
-- Build failures
-- Before claiming work complete
-
-## The Four Phases
-
-### Phase 1: Root Cause Investigation
-1. Read error messages completely
-2. Reproduce the issue consistently
-3. Check recent changes
-4. Gather evidence before theorizing
-
-### Phase 2: Pattern Analysis
-1. Find working examples
-2. Compare with failing case
-3. Identify differences
-
-### Phase 3: Hypothesis and Testing
-1. Form a theory
-2. Test minimally
-3. Verify theory is correct
-
-### Phase 4: Implementation
-1. Create a test that fails
-2. Fix once at root cause
-3. Verify test passes
-
-## Quick Reference
-
-```
-Bug reported → Phase 1 (investigate)
-  Error deep in stack? → Trace backward to source
-  Found root cause? → Phase 4 (fix at source)
-  About to claim success? → Verify first!
-```
-
-## Red Flags
-
-Stop if thinking:
-- "Quick fix for now"
-- "Just try changing X"
-- "Should work now"
-
-**All mean:** Return to Phase 1.
-
-## References
-
-See `./references/` for detailed guides:
-- `systematic-debugging.md` - Full 4-phase process
-- `root-cause-tracing.md` - Backward tracing technique
-- `verification.md` - Verification protocol

package/skills/debugging/references/root-cause-tracing.md

@@ -1,65 +0,0 @@
-# Root Cause Tracing
-
-Technique for finding where bugs originate, not where they manifest.
-
-## Core Concept
-
-Bugs often appear deep in execution but originate elsewhere. Trace backward through the call stack to find the original source.
-
-## The Backward Trace
-
-When you see an error:
-
-1. **Note the error location**
-   - Where did it crash/fail?
-   - This is the symptom, not cause
-
-2. **Ask: Where did this data come from?**
-   - What function called this?
-   - What set this variable?
-
-3. **Trace one level back**
-   - Check the caller
-   - Verify data at that point
-
-4. **Repeat until source found**
-   - Keep asking "where from?"
-   - Stop when you find invalid data entry point
-
-## Example
-
-```
-Error: Cannot read property 'name' of undefined
-  at renderUser (line 50)
-  at processUsers (line 30)
-  at handleResponse (line 15)
-  at fetchUsers (line 5)
-```
-
-**Bad approach:** Fix at line 50 with null check
-**Good approach:** Trace back - why is user undefined at line 30? Where did it come from?
-
-## Questions to Ask
-
-At each level:
-- What is the value here?
-- Is it what I expect?
-- Who set it / passed it?
-- Was it validated?
-
-## Finding the Root
-
-Root cause is found when:
-- You find where invalid data first entered
-- Or where a valid value became invalid
-- Or where an assumption was violated
-
-Fix at that point, not downstream.
-
-## Common Root Causes
-
-- Missing input validation
-- Incorrect API response handling
-- Race condition
-- State mutation
-- Incorrect assumption about data shape

package/skills/debugging/references/systematic-debugging.md

@@ -1,74 +0,0 @@
-# Systematic Debugging
-
-Four-phase framework ensuring proper investigation before fixes.
-
-## Phase 1: Root Cause Investigation
-
-Before ANY fix attempt:
-
-1. **Read the full error**
-   - Stack trace, line numbers, error type
-   - Don't skim - read word by word
-
-2. **Reproduce consistently**
-   - Can you trigger it reliably?
-   - What are the exact steps?
-
-3. **Check recent changes**
-   - What changed since it last worked?
-   - git diff, recent commits
-
-4. **Gather evidence**
-   - Add logging if needed
-   - Check inputs and outputs
-   - Don't guess - observe
-
-## Phase 2: Pattern Analysis
-
-1. **Find working example**
-   - Similar code that works
-   - Previous version that worked
-
-2. **Compare systematically**
-   - Line by line comparison
-   - What's different?
-
-3. **Identify key difference**
-   - What's the minimal difference?
-   - What assumption changed?
-
-## Phase 3: Hypothesis and Testing
-
-1. **Form specific theory**
-   - "The bug is caused by X because Y"
-   - Must be testable
-
-2. **Test minimally**
-   - Smallest change to prove/disprove
-   - Don't fix yet - just test theory
-
-3. **Verify theory**
-   - Did prediction match result?
-   - If not, return to Phase 1
-
-## Phase 4: Implementation
-
-1. **Write failing test first**
-   - Test should fail before fix
-   - Proves you understand bug
-
-2. **Make minimal fix**
-   - Fix at root cause
-   - Don't add workarounds
-
-3. **Verify fix works**
-   - Test passes now
-   - No regressions
-   - Fresh run, not cached
-
-## Key Rules
-
-- Complete each phase before proceeding
-- No fixes without Phase 1 evidence
-- Theory must be testable
-- Verify every claim

package/skills/debugging/references/verification.md

@@ -1,74 +0,0 @@
-# Verification Protocol
-
-Run verification commands and confirm output before claiming success.
-
-## Core Rule
-
-**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**
-
-"Should work" is not evidence. Run it. Read the output. Then claim.
-
-## Verification Steps
-
-### 1. Run Fresh
-
-- Clear cache if applicable
-- Run from clean state
-- Don't rely on previous runs
-
-### 2. Read Output
-
-- Read the actual output
-- Don't assume it passed
-- Check for warnings too
-
-### 3. Confirm Expectations
-
-- Did it do what you expected?
-- All tests pass (not just most)?
-- No new warnings/errors?
-
-### 4. Document Evidence
-
-- Copy relevant output
-- Note what was verified
-- Timestamp if needed
-
-## What to Verify
-
-Before claiming "fixed":
-- [ ] Tests pass (fresh run)
-- [ ] No new errors in logs
-- [ ] Feature works manually
-- [ ] Edge cases handled
-
-Before claiming "complete":
-- [ ] All acceptance criteria met
-- [ ] Tests cover new code
-- [ ] No regressions
-- [ ] Documentation updated
-
-## Anti-Patterns
-
-**Don't do:**
-- "Tests passed earlier"
-- "It worked on my machine"
-- "Should be fine now"
-- Skipping verification because confident
-
-**Do instead:**
-- Run fresh every time
-- Read actual output
-- Verify on clean state
-- Question assumptions
-
-## Verification Checklist
-
-```
-[ ] Ran command fresh (not cached)
-[ ] Read full output (not skimmed)
-[ ] Output matches expectations
-[ ] No warnings or errors
-[ ] Tested edge case
-[ ] Documented result
-```

package/skills/docs-seeker/SKILL.md

@@ -1,91 +0,0 @@
----
-name: docs-seeker
-description: Find and reference technical documentation. Use when needing API docs, library references, or implementation examples.
----
-
-# Docs Seeker
-
-Find relevant technical documentation efficiently.
-
-## When to Use
-
-- Need API documentation
-- Looking for library examples
-- Researching best practices
-- Finding implementation guides
-- Unknown technology referenced
-
-## Search Strategy
-
-### 1. Identify What's Needed
-
-- API reference?
-- Tutorial/guide?
-- Code examples?
-- Best practices?
-
-### 2. Search Sources
-
-Priority order:
-1. Official documentation
-2. GitHub repositories
-3. Stack Overflow (verified answers)
-4. Technical blogs (reputable)
-
-### 3. Validate Information
-
-- Check date (is it current?)
-- Check source (is it authoritative?)
-- Check version (matches your version?)
-
-## Documentation Types
-
-### API Reference
-- Function signatures
-- Parameters and return types
-- Error codes
-
-### Tutorials
-- Step-by-step guides
-- Getting started
-- Common patterns
-
-### Examples
-- Working code samples
-- Real-world usage
-- Edge case handling
-
-## Search Tips
-
-### For Libraries
-```
-[library name] documentation
-[library name] [specific feature] example
-[library name] [version] migration guide
-```
-
-### For APIs
-```
-[service] API reference
-[service] [endpoint] documentation
-[service] authentication guide
-```
-
-### For Errors
-```
-[error message] [language/framework]
-[error code] [library name]
-```
-
-## Quality Checks
-
-- [ ] Source is official/reputable?
-- [ ] Information is current?
-- [ ] Version matches?
-- [ ] Examples work?
-
-## References
-
-See `./references/` for detailed guides:
-- `search-patterns.md` - Search strategies
-- `source-evaluation.md` - Evaluating sources

package/skills/planning/SKILL.md

@@ -1,82 +0,0 @@
----
-name: planning
-description: Create technical implementation plans through research, analysis, and design. Use when planning features, architecting systems, or breaking down complex requirements.
----
-
-# Planning
-
-Create detailed implementation plans before writing code.
-
-## Core Principles
-
-- **YAGNI**, **KISS**, **DRY**
-- Plan quality determines implementation success
-- Research before designing
-
-## When to Use
-
-- Planning new feature implementations
-- Architecting system designs
-- Evaluating technical approaches
-- Breaking down complex requirements
-- Assessing technical trade-offs
-
-## Planning Workflow
-
-### 1. Research & Analysis
-- Understand requirements fully
-- Research existing solutions
-- Identify constraints and risks
-
-### 2. Codebase Understanding
-- Read existing code patterns
-- Identify integration points
-- Note dependencies
-
-### 3. Solution Design
-- Design architecture
-- Consider alternatives
-- Evaluate trade-offs
-
-### 4. Plan Documentation
-- Write clear plan document
-- Break into phases
-- Define success criteria
-
-### 5. Review & Refine
-- Verify completeness
-- Check actionability
-- Get stakeholder input
-
-## Output Requirements
-
-- **DO NOT** implement code - only create plans
-- Plans must be self-contained
-- Include code snippets for clarity
-- Provide multiple options when applicable
-
-## Plan Structure
-
-```
-plans/
-└── YYMMDD-plan-name/
-    ├── plan.md           # Main plan
-    ├── phase-01-xxx.md   # Phase details
-    ├── phase-02-xxx.md
-    └── research/         # Research notes
-```
-
-## Quality Standards
-
-- Thorough and specific
-- Consider maintainability
-- Address security concerns
-- Detailed enough for any developer
-- Validate against existing patterns
-
-## References
-
-See `./references/` for detailed guides:
-- `research-phase.md` - Research methodology
-- `solution-design.md` - Design patterns
-- `plan-organization.md` - Plan structure