bonnguyenitc

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

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

Use when you have a spec or requirements for a multi-step task, before touching code

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when executing implementation plans with independent tasks in the current session

Implement an approved plan step by step, following the project's conventions, and verify each step. Use after a plan exists, when asked to "implement this", "code it up", or "build the feature". Writes minimal, surgical code matching existing style and runs the success checks. Final stage of the spec → plan → coding workflow.

Diagnose and fix a bug methodically, and track the investigation in the owning task. Use when something is broken, a test fails, behavior is wrong, or asked to "debug X", "fix this bug", "why is this failing". Reproduces, finds root cause, fixes minimally, verifies, and records it in tasks/TASK-<ID>/debug.md. Attaches to the spec → plan → coding → review workflow whenever a defect appears.

Design an implementation plan from an understood spec before writing code. Use after the spec is understood, when asked to "plan this feature", "how should we implement X", or "break this down into steps". Produces an ordered, verifiable step-by-step plan with files to touch, approach, tradeoffs, and per-step success checks. Second stage of the spec → plan → coding workflow.

Pick up an in-progress task exactly where it was left off — locate it, report where it stands, and continue from the current stage. Use when returning after a break or context reset, or when asked to "resume", "continue the task", "pick up where we left off", "tiếp tục task", "đang làm tới đâu rồi". Entry point over the stage skills; the interactive counterpart to ship.

Wrap up a finished change — self-review the diff, run the full test/lint gate, verify against acceptance criteria, update docs, then prepare commit/PR. Use after coding is done, when asked to "review my changes", "wrap up", "finalize", or "is this ready to merge". Final stage of the spec → plan → coding → review workflow.

Take a feature request from idea to reviewed, ready-to-commit code in one run — spec → plan → coding → review (+ debug on defects) — without asking at each stage. Use when given a request like "/ship implement login", "ship this feature", "do the whole flow for X", "làm hết flow cho chức năng X". Orchestrator over the stage skills; never runs explore-source.

Read and fully understand a spec, ticket, PRD, or feature request before any planning or coding. Use when given requirements to implement, when asked to "understand this spec", "what does this ticket mean", or as the first step of a feature. Extracts goals, requirements, acceptance criteria, edge cases, and open questions. First stage of the spec → plan → coding workflow.

Shelve a task out of the active set by moving its whole folder into tasks/archive/, history intact, so active scans stay clean. Use for finished or abandoned tasks, or when asked to "archive", "shelve", "put this task away", "lưu trữ task", "dọn task xong". Reversible — resume-task restores it. Lifecycle skill, not a stage.