thanh-kit 2.5.0 → 2.5.2

package/templates/skills/code-review/SKILL.md

@@ -1,143 +1,147 @@
 ---
-name: code-review
-description: Use when receiving code review feedback (especially if unclear or technically questionable), when completing tasks or major features requiring review before proceeding, or before making any completion/success claims. Covers three practices - receiving feedback with technical rigor over performative agreement, requesting reviews via code-reviewer subagent, and verification gates requiring evidence before any status claims. Essential for subagent-driven development, pull requests, and preventing false completion claims.
+name: ck:code-review
+description: "Review code quality, receive feedback with technical rigor, verify completion claims. Use before PRs, after implementing features, when claiming task completion. Includes scout-based edge case detection and native Task pipeline orchestration."
+argument-hint: "[context] OR codebase [parallel]"
 ---
 
 # Code Review
 
 Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.
 
-## Overview
+## Default (No Arguments)
 
-Code review requires three distinct practices:
+If invoked with context (recent changes/PR), proceed with review. If invoked WITHOUT arguments, use `AskUserQuestion` to present available review operations:
 
-1. **Receiving feedback** - Technical evaluation over performative agreement
-2. **Requesting reviews** - Systematic review via code-reviewer subagent
-3. **Verification gates** - Evidence before any completion claims
+| Operation | Description |
+|-----------|-------------|
+| `(default)` | Review recent changes/PR |
+| `codebase` | Full codebase scan & analysis |
+| `codebase parallel` | Parallel multi-reviewer audit |
 
-Each practice has specific triggers and protocols detailed in reference files.
+Present as options via `AskUserQuestion` with header "Review Operation", question "What would you like to do?".
 
 ## Core Principle
 
-Always honoring **YAGNI**, **KISS**, and **DRY** principles.
+**YAGNI**, **KISS**, **DRY** always. Technical correctness over social comfort.
 **Be honest, be brutal, straight to the point, and be concise.**
 
-**Technical correctness over social comfort.** Verify before implementing. Ask before assuming. Evidence before claims.
+Verify before implementing. Ask before assuming. Evidence before claims.
 
-## When to Use This Skill
+## Practices
 
-### Receiving Feedback
-Trigger when:
-- Receiving code review comments from any source
-- Feedback seems unclear or technically questionable
-- Multiple review items need prioritization
-- External reviewer lacks full context
-- Suggestion conflicts with existing decisions
-
-**Reference:** `references/code-review-reception.md`
-
-### Requesting Review
-Trigger when:
-- Completing tasks in subagent-driven development (after EACH task)
-- Finishing major features or refactors
-- Before merging to main branch
-- Stuck and need fresh perspective
-- After fixing complex bugs
-
-**Reference:** `references/requesting-code-review.md`
-
-### Verification Gates
-Trigger when:
-- About to claim tests pass, build succeeds, or work is complete
-- Before committing, pushing, or creating PRs
-- Moving to next task
-- Any statement suggesting success/completion
-- Expressing satisfaction with work
-
-**Reference:** `references/verification-before-completion.md`
+| Practice | When | Reference |
+|----------|------|-----------|
+| Receiving feedback | Unclear feedback, external reviewers, needs prioritization | `references/code-review-reception.md` |
+| Requesting review | After tasks, before merge, stuck on problem | `references/requesting-code-review.md` |
+| Verification gates | Before any completion claim, commit, PR | `references/verification-before-completion.md` |
+| Edge case scouting | After implementation, before review | `references/edge-case-scouting.md` |
+| **Task-managed reviews** | Multi-file features (3+ files), parallel reviewers, fix cycles | `references/task-management-reviews.md` |
 
 ## Quick Decision Tree
 
 ```
 SITUATION?
 │
-├─ Received feedback
-│  ├─ Unclear items? → STOP, ask for clarification first
-│  ├─ From human partner? → Understand, then implement
-│  └─ From external reviewer? → Verify technically before implementing
-│
-├─ Completed work
-│  ├─ Major feature/task? → Request code-reviewer subagent review
-│  └─ Before merge? → Request code-reviewer subagent review
-│
-└─ About to claim status
-   ├─ Have fresh verification? → State claim WITH evidence
-   └─ No fresh verification? → RUN verification command first
+├─ Received feedback → STOP if unclear, verify if external, implement if human partner
+├─ Completed work → Scout edge cases → Request code-reviewer subagent
+├─ Multi-file feature (3+ files) → Create review pipeline tasks (scout→review→fix→verify)
+└─ About to claim status → RUN verification command FIRST
 ```
 
-## Receiving Feedback Protocol
+## Receiving Feedback
 
-### Response Pattern
-READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
+**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
 
-### Key Rules
-- ❌ No performative agreement: "You're absolutely right!", "Great point!", "Thanks for [anything]"
-- ❌ No implementation before verification
-- ✅ Restate requirement, ask questions, push back with technical reasoning, or just start working
-- ✅ If unclear: STOP and ask for clarification on ALL unclear items first
-- ✅ YAGNI check: grep for usage before implementing suggested "proper" features
+**Rules:**
+- No performative agreement: "You're absolutely right!", "Great point!"
+- No implementation before verification
+- Restate, ask questions, push back with reasoning, or just work
+- YAGNI check: grep for usage before implementing "proper" features
 
-### Source Handling
-- **Human partner:** Trusted - implement after understanding, no performative agreement
-- **External reviewers:** Verify technically correct, check for breakage, push back if wrong
+**Source handling:**
+- Human partner: Trusted - implement after understanding
+- External reviewers: Verify technically, check breakage, push back if wrong
 
 **Full protocol:** `references/code-review-reception.md`
 
-## Requesting Review Protocol
+## Requesting Review
 
-### When to Request
-- After each task in subagent-driven development
-- After major feature completion
-- Before merge to main
+**When:** After each task, major features, before merge
 
-### Process
-1. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
-2. Dispatch code-reviewer subagent via Task tool with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
-3. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later
+**Process:**
+1. **Scout edge cases first** (see below)
+2. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
+3. Dispatch code-reviewer subagent with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
+4. Fix Critical immediately, Important before proceeding
 
 **Full protocol:** `references/requesting-code-review.md`
 
-## Verification Gates Protocol
+## Edge Case Scouting
+
+**When:** After implementation, before requesting code-reviewer
+
+**Process:**
+1. Invoke `/ck:scout` with edge-case-focused prompt
+2. Scout analyzes: affected files, data flows, error paths, boundary conditions
+3. Review scout findings for potential issues
+4. Address critical gaps before code review
 
-### The Iron Law
-**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**
+**Full protocol:** `references/edge-case-scouting.md`
 
-### Gate Function
-IDENTIFY command → RUN full command → READ output → VERIFY confirms claim → THEN claim
+## Task-Managed Review Pipeline
 
-Skip any step = lying, not verifying
+**When:** Multi-file features (3+ changed files), parallel code-reviewer scopes, review cycles with Critical fix iterations.
 
-### Requirements
-- Tests pass: Test output shows 0 failures
-- Build succeeds: Build command exit 0
-- Bug fixed: Test original symptom passes
-- Requirements met: Line-by-line checklist verified
+**Pipeline:** scout → review → fix → verify (each a Task with dependency chain)
 
-### Red Flags - STOP
-Using "should"/"probably"/"seems to", expressing satisfaction before verification, committing without verification, trusting agent reports, ANY wording implying success without running verification
+```
+TaskCreate: "Scout edge cases"         → pending
+TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
+TaskCreate: "Fix critical issues"      → pending, blockedBy: [review]
+TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]
+```
+
+**Parallel reviews:** Spawn scoped code-reviewer subagents for independent file groups (e.g., backend + frontend). Fix task blocks on all reviewers completing.
+
+**Re-review cycles:** If fixes introduce new issues, create cycle-2 review task. Limit 3 cycles, escalate to user after.
+
+**Full protocol:** `references/task-management-reviews.md`
+
+## Verification Gates
+
+**Iron Law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+
+**Gate:** IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim
+
+**Requirements:**
+- Tests pass: Output shows 0 failures
+- Build succeeds: Exit 0
+- Bug fixed: Original symptom passes
+- Requirements met: Checklist verified
+
+**Red Flags:** "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports
 
 **Full protocol:** `references/verification-before-completion.md`
 
 ## Integration with Workflows
 
-- **Subagent-Driven:** Review after EACH task, verify before moving to next
-- **Pull Requests:** Verify tests pass, request code-reviewer review before merge
-- **General:** Apply verification gates before any status claims, push back on invalid feedback
+- **Subagent-Driven:** Scout edge cases → Review after EACH task → Verify before next
+- **Pull Requests:** Scout → Verify tests → Code-reviewer review → Merge
+- **Task Pipeline:** Create review tasks with dependencies → auto-unblock through chain
+- **Cook Handoff:** Cook completes phase → review pipeline tasks → all complete → cook proceeds
+
+## Codebase Analysis Subcommands
+
+| Subcommand | Reference | Purpose |
+|------------|-----------|---------|
+| `/ck:code-review codebase` | `references/codebase-scan-workflow.md` | Scan & analyze the codebase |
+| `/ck:code-review codebase parallel` | `references/parallel-review-workflow.md` | Ultrathink edge cases, then parallel verify |
 
 ## Bottom Line
 
-1. Technical rigor over social performance - No performative agreement
-2. Systematic review processes - Use code-reviewer subagent
-3. Evidence before claims - Verification gates always
+1. Technical rigor over social performance
+2. Scout edge cases before review
+3. Task-manage reviews for multi-file features
+4. Evidence before claims
 
-Verify. Question. Then implement. Evidence. Then claim.
+Verify. Scout. Question. Then implement. Evidence. Then claim.

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

@@ -1,209 +1,113 @@
----
-name: receiving-code-review
-description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
----
-
-# Code Review Reception
-
-## Overview
-
-Code review requires technical evaluation, not emotional performance.
-
-**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
-
-## The Response Pattern
-
-```
-WHEN receiving code review feedback:
-
-1. READ: Complete feedback without reacting
-2. UNDERSTAND: Restate requirement in own words (or ask)
-3. VERIFY: Check against codebase reality
-4. EVALUATE: Technically sound for THIS codebase?
-5. RESPOND: Technical acknowledgment or reasoned pushback
-6. IMPLEMENT: One item at a time, test each
-```
-
-## Forbidden Responses
-
-**NEVER:**
-- "You're absolutely right!" (explicit CLAUDE.md violation)
-- "Great point!" / "Excellent feedback!" (performative)
-- "Let me implement that now" (before verification)
-
-**INSTEAD:**
-- Restate the technical requirement
-- Ask clarifying questions
-- Push back with technical reasoning if wrong
-- Just start working (actions > words)
-
-## Handling Unclear Feedback
-
-```
-IF any item is unclear:
-  STOP - do not implement anything yet
-  ASK for clarification on unclear items
-
-WHY: Items may be related. Partial understanding = wrong implementation.
-```
-
-**Example:**
-```
-your human partner: "Fix 1-6"
-You understand 1,2,3,6. Unclear on 4,5.
-
-❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
-✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
-```
-
-## Source-Specific Handling
-
-### From your human partner
-- **Trusted** - implement after understanding
-- **Still ask** if scope unclear
-- **No performative agreement**
-- **Skip to action** or technical acknowledgment
-
-### From External Reviewers
-```
-BEFORE implementing:
-  1. Check: Technically correct for THIS codebase?
-  2. Check: Breaks existing functionality?
-  3. Check: Reason for current implementation?
-  4. Check: Works on all platforms/versions?
-  5. Check: Does reviewer understand full context?
-
-IF suggestion seems wrong:
-  Push back with technical reasoning
-
-IF can't easily verify:
-  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
-
-IF conflicts with your human partner's prior decisions:
-  Stop and discuss with your human partner first
-```
-
-**your human partner's rule:** "External feedback - be skeptical, but check carefully"
-
-## YAGNI Check for "Professional" Features
-
-```
-IF reviewer suggests "implementing properly":
-  grep codebase for actual usage
-
-  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
-  IF used: Then implement properly
-```
-
-**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
-
-## Implementation Order
-
-```
-FOR multi-item feedback:
-  1. Clarify anything unclear FIRST
-  2. Then implement in this order:
-     - Blocking issues (breaks, security)
-     - Simple fixes (typos, imports)
-     - Complex fixes (refactoring, logic)
-  3. Test each fix individually
-  4. Verify no regressions
-```
-
-## When To Push Back
-
-Push back when:
-- Suggestion breaks existing functionality
-- Reviewer lacks full context
-- Violates YAGNI (unused feature)
-- Technically incorrect for this stack
-- Legacy/compatibility reasons exist
-- Conflicts with your human partner's architectural decisions
-
-**How to push back:**
-- Use technical reasoning, not defensiveness
-- Ask specific questions
-- Reference working tests/code
-- Involve your human partner if architectural
-
-**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
-
-## Acknowledging Correct Feedback
-
-When feedback IS correct:
-```
-✅ "Fixed. [Brief description of what changed]"
-✅ "Good catch - [specific issue]. Fixed in [location]."
-✅ [Just fix it and show in the code]
-
-❌ "You're absolutely right!"
-❌ "Great point!"
-❌ "Thanks for catching that!"
-❌ "Thanks for [anything]"
-❌ ANY gratitude expression
-```
-
-**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
-
-**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
-
-## Gracefully Correcting Your Pushback
-
-If you pushed back and were wrong:
-```
-✅ "You were right - I checked [X] and it does [Y]. Implementing now."
-✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
-
-❌ Long apology
-❌ Defending why you pushed back
-❌ Over-explaining
-```
-
-State the correction factually and move on.
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Performative agreement | State requirement or just act |
-| Blind implementation | Verify against codebase first |
-| Batch without testing | One at a time, test each |
-| Assuming reviewer is right | Check if breaks things |
-| Avoiding pushback | Technical correctness > comfort |
-| Partial implementation | Clarify all items first |
-| Can't verify, proceed anyway | State limitation, ask for direction |
-
-## Real Examples
-
-**Performative Agreement (Bad):**
-```
-Reviewer: "Remove legacy code"
-❌ "You're absolutely right! Let me remove that..."
-```
-
-**Technical Verification (Good):**
-```
-Reviewer: "Remove legacy code"
-✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
-```
-
-**YAGNI (Good):**
-```
-Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
-✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
-```
-
-**Unclear Item (Good):**
-```
-your human partner: "Fix items 1-6"
-You understand 1,2,3,6. Unclear on 4,5.
-✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
-```
-
-## The Bottom Line
-
-**External feedback = suggestions to evaluate, not orders to follow.**
-
-Verify. Question. Then implement.
-
-No performative agreement. Technical rigor always.
+---
+name: receiving-code-review
+description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement
+---
+
+# Code Review Reception
+
+**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
+
+## Response Pattern
+
+```
+1. READ: Complete feedback without reacting
+2. UNDERSTAND: Restate requirement (or ask)
+3. VERIFY: Check against codebase reality
+4. EVALUATE: Technically sound for THIS codebase?
+5. RESPOND: Technical acknowledgment or reasoned pushback
+6. IMPLEMENT: One at a time, test each
+```
+
+## Forbidden Responses
+
+❌ "You're absolutely right!" / "Great point!" / "Thanks for [anything]"
+❌ "Let me implement that now" (before verification)
+
+✅ Restate technical requirement
+✅ Ask clarifying questions
+✅ Push back with technical reasoning
+✅ Just start working (actions > words)
+
+## Handling Unclear Feedback
+
+```
+IF any item unclear:
+  STOP - don't implement anything
+  ASK for clarification on ALL unclear items
+
+WHY: Items may be related. Partial understanding = wrong implementation.
+```
+
+## Source-Specific Handling
+
+**Human partner:** Trusted - implement after understanding, no performative agreement
+
+**External reviewers:**
+```
+BEFORE implementing:
+  1. Technically correct for THIS codebase?
+  2. Breaks existing functionality?
+  3. Reason for current implementation?
+  4. Works all platforms/versions?
+
+IF wrong: Push back with technical reasoning
+IF can't verify: State limitation, ask direction
+IF conflicts with partner's decisions: Stop, discuss first
+```
+
+## YAGNI Check
+
+```
+IF reviewer suggests "implementing properly":
+  grep codebase for actual usage
+  IF unused: "This isn't called. Remove it (YAGNI)?"
+  IF used: Implement properly
+```
+
+## Implementation Order
+
+```
+1. Clarify unclear items FIRST
+2. Implement: blocking → simple → complex
+3. Test each individually
+4. Verify no regressions
+```
+
+## When To Push Back
+
+- Breaks existing functionality
+- Reviewer lacks full context
+- Violates YAGNI (unused feature)
+- Technically incorrect for stack
+- Legacy/compatibility reasons
+- Conflicts with architectural decisions
+
+**How:** Technical reasoning, specific questions, reference working tests
+
+## Acknowledging Correct Feedback
+
+✅ "Fixed. [Brief description]"
+✅ "Good catch - [issue]. Fixed in [location]."
+✅ Just fix it (actions > words)
+
+❌ ANY gratitude or performative expression
+
+## Correcting Wrong Pushback
+
+✅ "You were right - checked [X], it does [Y]. Implementing."
+❌ Long apology, defending, over-explaining
+
+## Quick Reference
+
+| Mistake | Fix |
+|---------|-----|
+| Performative agreement | State requirement or act |
+| Blind implementation | Verify against codebase |
+| Batch without testing | One at a time |
+| Assuming reviewer right | Check if breaks things |
+| Avoiding pushback | Technical correctness > comfort |
+
+## Bottom Line
+
+External feedback = suggestions to evaluate, not orders.
+Verify. Question. Then implement.

package/templates/skills/code-review/references/codebase-scan-workflow.md

@@ -0,0 +1,29 @@
+# Codebase Scan Workflow
+
+Think harder to scan the codebase and analyze it follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules:
+<tasks>$ARGUMENTS</tasks>
+
+## Role Responsibilities
+- You are an elite software engineering expert who specializes in system architecture design and technical decision-making.
+- You operate by: **YAGNI**, **KISS**, and **DRY**.
+- Sacrifice grammar for concision. List unresolved questions at end.
+
+## Workflow
+
+### Research
+* Use 2 `researcher` subagents in parallel to search up to 5 sources
+* Keep every research report concise (≤150 lines)
+* Use `/ck:scout` slash command to search the codebase
+
+### Code Review
+* Use multiple `code-reviewer` subagents in parallel to review code
+* If issues found, ask main agent to improve and repeat until tests pass
+* When complete, report summary to user
+
+### Plan
+* Use `planner` subagent to analyze reports and create improvement plan
+* Save overview at `plan.md`, phase files as `phase-XX-phase-name.md`
+
+### Final Report
+* Summary of changes, guide user to get started, suggest next steps
+* Ask user if they want to commit and push