From marvin
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.
npx claudepluginhub ondrej-svec/heart-of-gold-toolkit --plugin marvinThis skill is limited to using the following tools:
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.
Executes coding tasks from plans, specs, or prompts: triages input, scans codebase for patterns/tests, assesses complexity, implements systematically to ship complete features with quality.
Executes coding tasks from plan documents or prompts: triages input complexity, builds task lists, implements systematically following patterns, verifies with tests. Use to ship complete features efficiently.
Executes tech plans via dependency-aware task batching, TDD, incremental commits, section code reviews, and PR creation. Use after planning phases.
Share bugs, ideas, or general feedback.
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 /deep-thought: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)/deep-thought:plan first or describe what to build.Prefer the harness's structured choice UI when available. Otherwise present concise numbered options in plain text.
If anything in the plan is unclear: Ask clarifying questions now — better to ask than build wrong.
If the plan authorizes design-heavy, copy-heavy, or boundary-sensitive work, verify before leaving Phase 0 that the plan already includes:
If those items are missing, stop and return to planning. Do not invent the missing subjective contract during implementation.
When a plan file is provided: default to autonomous mode. Plans are pre-approved decisions — execute without re-litigating them.
/marvin:compound to capture it.docs/solutions/ for the relevant domain before starting implementation — avoid known pitfalls.See ../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../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 visible task tracking from the plan for each major task.
in progress, completed, blocked) and keep the plan checkboxes as the source of truth.For each task in dependency order:
while (unchecked tasks remain):
1. Mark the current task as in progress
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 → mark the task 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 .
If the plan requires a proof slice, do not propagate beyond that slice until its verification passes. If preview review or plan adherence fails, update the plan instead of improvising the missing contract in code.
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]
Ask the user what to do next.
/marvin:review on the changes before merging/marvin:compound if this work has patterns worth preservingIf 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