Execute a plan from start to ship — read tasks, implement in dependency order, test continuously, commit incrementally, run quality checks, and push. The plan's checkboxes are the tracker. Triggers: work, execute plan, implement, start work, build, ship, finalize, release, push, ready to ship, done building.
Execute a plan and ship it. This is the ONLY skill that writes code. Read tasks, implement in dependency order, test after every change, commit incrementally, quality checks, push.
This skill MAY: read code, write code, edit files, run tests, run linters, commit, push, create PRs.
This skill MAY NOT: skip the plan, skip tests, ship with known failures, commit .env or secrets.
This skill requires a plan. If no plan exists, suggest /plan first. Don't improvise implementation from scratch.
| Shortcut | Why It Fails | The Cost |
|---|---|---|
| "Skip reading the plan — I'll figure it out" | The plan has context, decisions, and dependencies you'll miss | Build the wrong thing → rework |
| "Giant commits — I'll sort it out later" | Hard to review, hard to revert, hide bugs | Technical debt + review burden |
| "Tests at the end — I'm in flow" |
| Late testing finds problems when fixing them is most expensive |
| Cascading failures |
| "Ship without quality checks — small change" | Small changes touch auth, data, or boundaries more often than you think | Bug in production from a "safe" change |
Entry: User invoked /work with a plan path or no arguments.
If invoked with a plan path:
If invoked without a path:
docs/plans/ (or project override path) for the most recent active plan (status: approved or status: in_progress in frontmatter)If anything in the plan is unclear: Use AskUserQuestion for clarifications now — better to ask than build wrong.
When a plan file is provided: default to autonomous mode. Plans are pre-approved decisions — execute without re-litigating them.
/compound to capture it.docs/solutions/ for the relevant domain before starting implementation — avoid known pitfalls.See ../../super-integration/knowledge/autonomy-modes.md for confidence-gated escalation.
Exit: Plan loaded, tasks understood, ready to set up environment.
Entry: Plan loaded.
Auto-load relevant knowledge for the task:
../knowledge/ci-cd-patterns.md../../super-intelligence/knowledge/infrastructure-ops.mdCheck current state:
git branch --show-current
git status --short
Follow the project's branching conventions (check CLAUDE.md). Pull latest changes before starting.
If on a feature branch: Continue on it. If on main/default branch: Check CLAUDE.md for branching rules.
Update plan status to in_progress if it was approved.
Exit: Branch ready, latest code pulled.
Entry: Environment set up.
Create trackable tasks from the plan using TaskCreate for each major task:
For each task in dependency order:
while (unchecked tasks remain):
1. TaskUpdate status → "in_progress" (shows spinner to user)
2. Read the task and any referenced files
3. Look for similar patterns in the codebase (grep, glob)
4. Implement following existing conventions
5. Run relevant tests
6. If tests pass → TaskUpdate status → "completed"
7. Check off the task in the plan ([ ] → [x])
8. Evaluate: commit now or continue?
Commit heuristic: Commit when you've completed a logical unit — a model, a service, a component, a migration. Don't commit partial units. If the commit message would be "WIP", keep working.
When tests fail: Fix immediately. Don't move to the next task with broken tests. If a test failure reveals a plan problem, update the plan.
Follow existing patterns:
Stage specific files — never git add .
Exit: All tasks checked off, all tests passing.
Entry: All tasks complete.
Run quality checks before shipping:
Tests:
# Run the project's test suite (check CLAUDE.md for the command)
# All tests must pass
Linting:
# Run the project's linter (check CLAUDE.md for the command)
# Fix any violations
Convention check:
If any check fails: Fix before proceeding. Do not ship with known issues.
Exit: All quality checks pass.
Entry: Quality checks pass.
Pre-ship gate — all must be true:
[x]).env, credentials, or secrets stagedIf any gate fails: Fix it. Don't ship with known issues.
Push and create PR if the project uses branches:
git push origin <branch>
# If using branches:
gh pr create --title "{short title}" --body "{summary + testing notes}"
Update plan status to complete.
Exit: Code pushed.
Entry: Code shipped.
Present the summary:
All tasks complete. Shipped.
Summary:
- [x] Task 1 — what was done
- [x] Task N — what was done
Acceptance criteria: all met / [list any that need verification]
Use AskUserQuestion with:
If user selects "Generate release notes":
| Audience | Focus |
|---|---|
| Customer | What they can do now that they couldn't before |
| Engineering | What changed, which services, why, test coverage |
| Business | Business value, metrics affected |
Before shipping, verify:
complete