@trieungoctam/vibekit 1.0.0

package/skills/core/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/skills/core/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

package/skills/core/code-review/references/task-management-reviews.md

@@ -0,0 +1,140 @@
+# Review Task Management Patterns
+
+Track review pipeline execution via Claude Native Tasks (TaskCreate, TaskUpdate, TaskList).
+
+## When to Create Tasks
+
+| Review Scope | Tasks? | Rationale |
+|--------------|--------|-----------|
+| Single-file fix | No | Scout + review + done, overhead not worth it |
+| Multi-file feature (3+ files) | Yes | Track scout → review → fix → verify chain |
+| Parallel reviewers (2+ scopes) | Yes | Coordinate independent reviews |
+| Review cycle with Critical fixes | Yes | Dependencies between fix → re-verify |
+
+**3-Task Rule:** Skip task creation when review pipeline has <3 meaningful steps.
+
+## Review Pipeline as Tasks
+
+```
+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]
+```
+
+Dependency chain auto-unblocks: scout completes → review starts → issues found → fix starts → verify confirms.
+
+## Task Schemas
+
+### Scout Task
+
+```
+TaskCreate(
+  subject: "Scout edge cases for {feature}",
+  activeForm: "Scouting edge cases",
+  description: "Identify affected files, data flows, boundary conditions. Changed: {files}",
+  metadata: { reviewStage: "scout", feature: "{feature}",
+              changedFiles: "src/auth.ts,src/middleware.ts",
+              priority: "P2", effort: "3m" }
+)
+```
+
+### Review Task
+
+```
+TaskCreate(
+  subject: "Review {feature} implementation",
+  activeForm: "Reviewing {feature}",
+  description: "Code-reviewer subagent reviews {BASE_SHA}..{HEAD_SHA}. Plan: {plan_ref}",
+  metadata: { reviewStage: "review", feature: "{feature}",
+              baseSha: "{BASE_SHA}", headSha: "{HEAD_SHA}",
+              priority: "P1", effort: "10m" },
+  addBlockedBy: ["{scout-task-id}"]
+)
+```
+
+### Fix Task (created after review finds issues)
+
+```
+TaskCreate(
+  subject: "Fix {severity} issues from review",
+  activeForm: "Fixing {severity} review issues",
+  description: "Address: {issue_list}",
+  metadata: { reviewStage: "fix", severity: "critical",
+              issueCount: 3, priority: "P1", effort: "15m" },
+  addBlockedBy: ["{review-task-id}"]
+)
+```
+
+### Verify Task
+
+```
+TaskCreate(
+  subject: "Verify fixes pass tests and build",
+  activeForm: "Verifying fixes",
+  description: "Run test suite, build, confirm 0 failures. Evidence before claims.",
+  metadata: { reviewStage: "verify", priority: "P1", effort: "5m" },
+  addBlockedBy: ["{fix-task-id}"]
+)
+```
+
+## Parallel Review Coordination
+
+For multi-scope reviews (e.g., backend + frontend changed independently):
+
+```
+// Create scoped review tasks — no blockedBy between them
+TaskCreate(subject: "Review backend auth changes",
+  metadata: { reviewStage: "review", scope: "src/api/,src/middleware/",
+              agentIndex: 1, totalAgents: 2, priority: "P1" })
+
+TaskCreate(subject: "Review frontend auth UI",
+  metadata: { reviewStage: "review", scope: "src/components/auth/",
+              agentIndex: 2, totalAgents: 2, priority: "P1" })
+
+// Both run simultaneously via separate code-reviewer subagents
+// Fix task blocks on BOTH completing:
+TaskCreate(subject: "Fix all review issues",
+  addBlockedBy: ["{backend-review-id}", "{frontend-review-id}"])
+```
+
+## Task Lifecycle
+
+```
+Scout:    pending → in_progress → completed (scout report returned)
+Review:   pending → in_progress → completed (reviewer findings returned)
+Fix:      pending → in_progress → completed (all Critical/Important fixed)
+Verify:   pending → in_progress → completed (tests pass, build clean)
+```
+
+### Handling Re-Reviews
+
+When fixes introduce new issues → create new review cycle:
+
+```
+TaskCreate(subject: "Re-review after fixes",
+  addBlockedBy: ["{fix-task-id}"],
+  metadata: { reviewStage: "review", cycle: 2, priority: "P1" })
+```
+
+Limit to 3 cycles. If still failing after cycle 3 → escalate to user.
+
+## Integration with Planning Tasks
+
+Review tasks are **separate from** cook/planning phase tasks.
+
+**When cook spawns review:**
+1. Cook completes implementation phase → creates review pipeline tasks
+2. Review pipeline executes (scout → review → fix → verify)
+3. All review tasks complete → cook marks phase as reviewed
+4. Cook proceeds to next phase
+
+Review tasks reference the phase but don't block it directly — the orchestrator manages handoff.
+
+## Quality Check
+
+After pipeline registration: `Registered [N] review tasks (scout → review → fix → verify chain)`
+
+## Error Handling
+
+If `TaskCreate` fails: log warning, fall back to sequential review without task tracking. Review pipeline functions identically — tasks add visibility, not functionality.

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

@@ -0,0 +1,139 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Why This Matters
+
+From 24 failure memories:
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/skills/core/cook/README.md

@@ -0,0 +1,86 @@
+# Cook Skill
+
+End-to-end feature implementation with smart intent detection.
+
+## Installation
+
+Copy the `cook/` folder to your Claude skills directory:
+```bash
+cp -r cook ~/.claude/skills/
+```
+
+## Usage
+
+```bash
+/cook <natural language task OR plan path>
+```
+
+The skill automatically detects your intent and routes to the appropriate workflow.
+
+## Examples
+
+```bash
+# Interactive mode (default)
+/cook implement user authentication
+
+# Execute existing plan
+/cook plans/260120-auth
+
+# Fast mode (skip research)
+/cook quick fix for login bug
+/cook implement feature --fast
+
+# Auto mode (trust me bro)
+/cook implement dashboard trust me
+/cook implement feature --auto
+
+# Parallel mode (multi-agent)
+/cook implement auth, payments, notifications
+/cook implement feature --parallel
+
+# No-test mode
+/cook implement feature --no-test
+```
+
+## Modes
+
+| Mode | Research | Testing | Review | Use Case |
+|------|----------|---------|--------|----------|
+| interactive | ✓ | ✓ | User approval | Default, full control |
+| auto | ✓ | ✓ | Auto if score≥9.5 | Trusted, hands-off |
+| fast | ✗ | ✓ | Simplified | Quick fixes |
+| parallel | Optional | ✓ | User approval | Multi-feature work |
+| no-test | ✓ | ✗ | User approval | Speed priority |
+| code | ✗ | ✓ | User approval | Existing plans |
+
+## Intent Detection
+
+The skill detects mode from:
+1. **Explicit flags:** `--fast`, `--auto`, `--parallel`, `--no-test`
+2. **Plan paths:** `./plans/*`, `plan.md`, `phase-*.md`
+3. **Keywords:** "fast", "quick", "trust me", "auto", "no test"
+4. **Feature count:** 3+ features → parallel mode
+
+## Workflow
+
+```
+[Intent Detection] → [Research?] → [Plan] → [Implement] → [Test?] → [Review] → [Finalize]
+```
+
+## Files
+
+```
+cook/
+├── SKILL.md                           # Main skill definition
+├── README.md                          # This file
+└── references/
+    ├── intent-detection.md            # Detection rules
+    ├── workflow-steps.md              # Step definitions
+    ├── review-cycle.md                # Review process
+    └── subagent-patterns.md           # Subagent usage
+```
+
+## Version
+
+2.1.0 - Review gates added for human-in-the-loop mode
+2.0.0 - Smart intent detection (hybrid approach)

package/skills/core/cook/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: cook
+description: "ALWAYS activate this skill before implementing EVERY feature, plan, or fix."
+version: 2.1.1
+argument-hint: "[task|plan-path] [--interactive|--fast|--parallel|--auto|--no-test]"
+---
+
+# Cook - Smart Feature Implementation
+
+End-to-end implementation with automatic workflow detection.
+
+**Principles:** YAGNI, KISS, DRY | Token efficiency | Concise reports
+
+## Usage
+
+```
+/cook <natural language task OR plan path>
+```
+
+**IMPORTANT:** If no flag is provided, the skill will use the `interactive` mode by default for the workflow.
+
+**Optional flags to select the workflow mode:** 
+- `--interactive`: Full workflow with user input (**default**)
+- `--fast`: Skip research, scout→plan→code
+- `--parallel`: Multi-agent execution
+- `--no-test`: Skip testing step
+- `--auto`: Auto-approve all steps
+
+**Example:**
+```
+/cook "Add user authentication to the app" --fast
+/cook path/to/plan.md --auto
+```
+
+## Smart Intent Detection
+
+| Input Pattern | Detected Mode | Behavior |
+|---------------|---------------|----------|
+| Path to `plan.md` or `phase-*.md` | code | Execute existing plan |
+| Contains "fast", "quick" | fast | Skip research, scout→plan→code |
+| Contains "trust me", "auto" | auto | Auto-approve all steps |
+| Lists 3+ features OR "parallel" | parallel | Multi-agent execution |
+| Contains "no test", "skip test" | no-test | Skip testing step |
+| Default | interactive | Full workflow with user input |
+
+See `references/intent-detection.md` for detection logic.
+
+## Workflow Overview
+
+```
+[Intent Detection] → [Research?] → [Review] → [Plan] → [Review] → [Implement] → [Review] → [Test?] → [Review] → [Finalize]
+```
+
+**Default (non-auto):** Stops at `[Review]` gates for human approval before each major step.
+**Auto mode (`--auto`):** Skips human review gates, implements all phases continuously.
+**Claude Tasks:** Utilize all these tools `TaskCreate`, `TaskUpdate`, `TaskGet` and `TaskList` during implementation step.
+
+| Mode | Research | Testing | Review Gates | Phase Progression |
+|------|----------|---------|--------------|-------------------|
+| interactive | ✓ | ✓ | **User approval at each step** | One at a time |
+| auto | ✓ | ✓ | Auto if score≥9.5 | All at once (no stops) |
+| fast | ✗ | ✓ | **User approval at each step** | One at a time |
+| parallel | Optional | ✓ | **User approval at each step** | Parallel groups |
+| no-test | ✓ | ✗ | **User approval at each step** | One at a time |
+| code | ✗ | ✓ | **User approval at each step** | Per plan |
+
+## Step Output Format
+
+```
+✓ Step [N]: [Brief status] - [Key metrics]
+```
+
+## Blocking Gates (Non-Auto Mode)
+
+Human review required at these checkpoints (skipped with `--auto`):
+- **Post-Research:** Review findings before planning
+- **Post-Plan:** Approve plan before implementation
+- **Post-Implementation:** Approve code before testing
+- **Post-Testing:** 100% pass + approve before finalize
+
+**Always enforced (all modes):**
+- **Testing:** 100% pass required (unless no-test mode)
+- **Code Review:** User approval OR auto-approve (score≥9.5, 0 critical)
+- **Finalize (MANDATORY - never skip):**
+  1. `project-manager` subagent → run full plan sync-back (all completed tasks/steps across all `phase-XX-*.md`, not only current phase), then update `plan.md` status/progress
+  2. `docs-manager` subagent → update `./docs` if changes warrant
+  3. `TaskUpdate` → mark all Claude Tasks complete after sync-back verification
+  4. Ask user if they want to commit via `git-manager` subagent
+
+## Required Subagents (MANDATORY)
+
+| Phase | Subagent | Requirement |
+|-------|----------|-------------|
+| Research | `researcher` | Optional in fast/code |
+| Scout | `ck:scout` | Optional in code |
+| Plan | `planner` | Optional in code |
+| UI Work | `ui-ux-designer` | If frontend work |
+| Testing | `tester`, `debugger` | **MUST** spawn |
+| Review | `code-reviewer` | **MUST** spawn |
+| Finalize | `project-manager`, `docs-manager`, `git-manager` | **MUST** spawn all 3 |
+
+**CRITICAL ENFORCEMENT:**
+- Steps 4, 5, 6 **MUST** use Task tool to spawn subagents
+- DO NOT implement testing, review, or finalization yourself - DELEGATE
+- If workflow ends with 0 Task tool calls, it is INCOMPLETE
+- Pattern: `Task(subagent_type="[type]", prompt="[task]", description="[brief]")`
+
+## References
+
+- `references/intent-detection.md` - Detection rules and routing logic
+- `references/workflow-steps.md` - Detailed step definitions for all modes
+- `references/review-cycle.md` - Interactive and auto review processes
+- `references/subagent-patterns.md` - Subagent invocation patterns