@manhnv319/codexkit 0.1.0

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

@@ -0,0 +1,147 @@
+---
+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.
+
+## Default (No Arguments)
+
+If invoked with context (recent changes/PR), proceed with review. If invoked WITHOUT arguments, use `AskUserQuestion` to present available review operations:
+
+| Operation | Description |
+|-----------|-------------|
+| `(default)` | Review recent changes/PR |
+| `codebase` | Full codebase scan & analysis |
+| `codebase parallel` | Parallel multi-reviewer audit |
+
+Present as options via `AskUserQuestion` with header "Review Operation", question "What would you like to do?".
+
+## Core Principle
+
+**YAGNI**, **KISS**, **DRY** always. Technical correctness over social comfort.
+**Be honest, be brutal, straight to the point, and be concise.**
+
+Verify before implementing. Ask before assuming. Evidence before claims.
+
+## Practices
+
+| 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 → 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
+
+**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
+
+**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
+- External reviewers: Verify technically, check breakage, push back if wrong
+
+**Full protocol:** `references/code-review-reception.md`
+
+## Requesting Review
+
+**When:** After each task, major features, before merge
+
+**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`
+
+## Edge Case Scouting
+
+**When:** After implementation, before requesting code_reviewer
+
+**Process:**
+1. Invoke `$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
+
+**Full protocol:** `references/edge-case-scouting.md`
+
+## Task-Managed Review Pipeline
+
+**When:** Multi-file features (3+ changed files), parallel code_reviewer scopes, review cycles with Critical fix iterations.
+
+**Pipeline:** scout → review → fix → verify (each a Task with dependency chain)
+
+```
+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:** 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 |
+|------------|-----------|---------|
+| `$code-review codebase` | `references/codebase-scan-workflow.md` | Scan & analyze the codebase |
+| `$code-review codebase parallel` | `references/parallel-review-workflow.md` | Ultrathink edge cases, then parallel verify |
+
+## Bottom Line
+
+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. Scout. Question. Then implement. Evidence. Then claim.

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

@@ -0,0 +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
+---
+
+# 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/.agents/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

package/.agents/skills/code-review/references/edge-case-scouting.md

@@ -0,0 +1,119 @@
+---
+name: edge-case-scouting
+description: Use after implementation, before code review to proactively find edge cases, side effects, and potential issues via scout skill - catches problems code_reviewer might miss
+---
+
+# Edge Case Scouting
+
+Proactive detection of edge cases, side effects, and potential issues before code review.
+
+## Purpose
+
+Code reviews catch obvious issues but miss subtle side effects. Scout detects:
+- Files affected by changes reviewer might not check
+- Data flow paths that could break
+- Boundary conditions and error paths
+- Integration issues across modules
+
+## When to Use
+
+**Mandatory:** Multi-file features, shared utility refactors, complex bug fixes
+**Optional:** Single-file changes, docs, config
+
+## Process
+
+### 1. Identify Changed Files
+```bash
+git diff --name-only HEAD~1
+```
+
+### 2. Invoke Scout
+```
+/scout edge cases for recent changes.
+
+Changed: {files from git diff}
+
+Find:
+1. Files importing/depending on changed modules
+2. Data flow paths through modified functions
+3. Error handling paths not tested
+4. Boundary conditions (null, empty, max)
+5. Race conditions in async code
+6. State management side effects
+```
+
+### 3. Analyze & Act
+
+| Finding | Action |
+|---------|--------|
+| Affected file not in scope | Add to review |
+| Data flow risk | Verify or add test |
+| Edge case | Add test or verify |
+| Missing test | Add before review |
+
+### 4. Document for Review
+```
+Scout findings:
+- {issues found}
+- Verified: {what checked}
+- Addressed: {what fixed}
+- Needs review: {remaining}
+```
+
+## Scout Prompts
+
+**Feature:**
+```
+Scout edge cases for {feature}.
+Changed: {files}
+Find: consumers, error states, untested inputs, performance, compatibility
+```
+
+**Bug fix:**
+```
+Scout side effects of fix in {file}.
+Bug: {description}, Fix: {approach}
+Find: other paths using logic, dependent features, similar bugs
+```
+
+**Refactor:**
+```
+Scout breaking changes in {module}.
+Before: {old}, After: {new}
+Find: importers, behavior diffs, removed functionality
+```
+
+## What Scout Catches
+
+| Issue | Why Missed | Scout Detects |
+|-------|------------|---------------|
+| Indirect deps | Not in diff | Traces imports |
+| Race conditions | Hard static review | Analyzes flow |
+| State mutations | Hidden side effects | Tracks data |
+| Missing null checks | Assumed safe | Boundary analysis |
+| Integration breaks | Out of scope | Cross-module search |
+
+## Red Flags
+
+- Shared utility changed but only one caller tested
+- Error path leads to unhandled rejection
+- State modified in place without notification
+- Breaking change without migration
+
+## Example
+
+```
+1. Done: Add cache to UserService.getUser()
+2. Diff: src/services/user-service.ts
+3. Scout: "edge cases for caching in getUser()"
+4. Report:
+   - ProfileComponent expects fresh data on edit
+   - AdminPanel loops getUser() (memory risk)
+   - No cache clear on updateUser()
+5. Fix: Add invalidation, maxSize
+6. Document for code_reviewer
+```
+
+## Bottom Line
+
+Scout before review. Don't trust "simple changes" - scout them anyway.

package/.agents/skills/code-review/references/parallel-review-workflow.md

@@ -0,0 +1,69 @@
+# Parallel Review Workflow
+
+**Ultrathink** to exhaustively list ALL potential edge cases, then dispatch parallel `code_reviewer` agents to verify: <scope>$ARGUMENTS</scope>
+
+**IMPORTANT:** Activate needed skills. Ensure token efficiency. Sacrifice grammar for concision.
+
+## Workflow
+
+### 1. Ultrathink Edge Cases
+
+Main agent deeply analyzes the scope to LIST all potential edge cases FIRST:
+- Read `codebase-summary.md` for context
+- Use `/ck:scout` to find relevant files
+- **Think exhaustively** about what could go wrong:
+  - Null/undefined scenarios
+  - Boundary conditions (off-by-one, empty, max values)
+  - Error handling gaps
+  - Race conditions, async edge cases
+  - Input validation holes
+  - Security vulnerabilities
+  - Resource leaks
+  - Untested code paths
+
+**Output format:**
+```markdown
+## Edge Cases Identified
+
+### Category: [scope-area]
+1. [edge case description] → files: [file1, file2]
+```
+
+### 2. Categorize & Assign
+
+Group edge cases by similar scope for parallel verification:
+- Each category → one `code_reviewer` agent
+- Max 6 categories (merge small ones)
+- Each reviewer gets specific edge cases to VERIFY, not discover
+
+### 3. Parallel Verification
+
+Launch N `code_reviewer` subagents simultaneously:
+- Pass: category name, list of edge cases, relevant files
+- Task: **VERIFY** if each edge case is properly handled in code
+- Report: which edge cases are handled vs unhandled
+
+### 4. Aggregate Results
+
+```markdown
+## Edge Case Verification Report
+
+### Summary
+- Total edge cases: X
+- Handled: Y
+- Unhandled: Z
+- Partial: W
+
+### Unhandled Edge Cases (Need Fix)
+| # | Edge Case | File | Status |
+|---|-----------|------|--------|
+```
+
+### 5. Auto-Fix Pipeline
+
+**IF** unhandled/partial edge cases found:
+- Ask: "Found N unhandled edge cases. Fix with /ck:fix --parallel? [Y/n]"
+
+### 6. Final Report
+- Summary of verification
+- Ask: "Commit? [Y/n]" → use `git_manager`

package/.agents/skills/code-review/references/requesting-code-review.md

@@ -0,0 +1,116 @@
+---
+name: requesting-code-review
+description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code_reviewer subagent to review implementation against plan or requirements before proceeding
+---
+
+# Requesting Code Review
+
+Dispatch code_reviewer subagent to catch issues before they cascade.
+
+**Core principle:** Scout first, review often.
+
+## When to Request Review
+
+**Mandatory:**
+- After each task in subagent-driven development
+- After completing major feature
+- Before merge to main
+
+**Optional but valuable:**
+- When stuck (fresh perspective)
+- Before refactoring (baseline check)
+- After fixing complex bug
+
+## How to Request
+
+**0. Scout edge cases first (NEW):**
+```
+Before dispatching code_reviewer, invoke /ck:scout to find:
+- Files affected by changes (not just modified files)
+- Data flow paths that could break
+- Edge cases and boundary conditions
+- Potential side effects
+
+See: references/edge-case-scouting.md
+```
+
+**1. Get git SHAs:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Dispatch code_reviewer subagent:**
+
+Use Task tool with `code_reviewer` type, fill template at `code_reviewer.md`
+
+**Placeholders:**
+- `{WHAT_WAS_IMPLEMENTED}` - What you just built
+- `{PLAN_OR_REQUIREMENTS}` - What it should do
+- `{BASE_SHA}` - Starting commit
+- `{HEAD_SHA}` - Ending commit
+- `{DESCRIPTION}` - Brief summary
+
+**3. Act on feedback:**
+- Fix Critical issues immediately
+- Fix Important issues before proceeding
+- Note Minor issues for later
+- Push back if reviewer is wrong (with reasoning)
+
+## Example
+
+```
+[Just completed Task 2: Add verification function]
+
+You: Let me request code review before proceeding.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Dispatch code_reviewer subagent]
+  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
+  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+
+[Subagent returns]:
+  Strengths: Clean architecture, real tests
+  Issues:
+    Important: Missing progress indicators
+    Minor: Magic number (100) for reporting interval
+  Assessment: Ready to proceed
+
+You: [Fix progress indicators]
+[Continue to Task 3]
+```
+
+## Integration with Workflows
+
+**Subagent-Driven Development:**
+- Review after EACH task
+- Catch issues before they compound
+- Fix before moving to next task
+
+**Executing Plans:**
+- Review after each batch (3 tasks)
+- Get feedback, apply, continue
+
+**Ad-Hoc Development:**
+- Review before merge
+- Review when stuck
+
+## Red Flags
+
+**Never:**
+- Skip review because "it's simple"
+- Ignore Critical issues
+- Proceed with unfixed Important issues
+- Argue with valid technical feedback
+
+**If reviewer wrong:**
+- Push back with technical reasoning
+- Show code/tests that prove it works
+- Request clarification
+
+See template at: requesting-code-review/code_reviewer.md