From python
Executes implementation tasks from approved plan.json, enforcing TDD, tracking progress via beads, and reporting in batches or autonomously. Use after spec-plan.
npx claudepluginhub martinffx/atelier --plugin pythonThis skill uses the workspace's default tool permissions.
Pick up tasks. Execute them. Track progress. Report. Stop when blocked.
Executes written implementation plans using fresh subagents per task with TDD cycles, mandatory code reviews, and quality gates before proceeding.
Guides implementation of specification tasks with checklists, step-by-step file edits, tests, acceptance criteria validation, and progress tracking. Phase 4 of Spec Kit workflow.
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.
Pick up tasks. Execute them. Track progress. Report. Stop when blocked.
This skill does not make design decisions or modify the plan. If the plan is wrong, go back to spec-plan. If the design is wrong, go back to spec-research.
Before starting, verify these exist:
docs/specs/YYYY-MM-DD-<feature>/spec.mddocs/specs/YYYY-MM-DD-<feature>/plan.jsonIf anything is missing, do not proceed. Tell the human what's needed.
Read plan.json critically before writing code. Look for:
If you find concerns, raise them before starting. Don't guess. Don't assume. Ask.
If the human hasn't specified a mode, ask.
"Implement it all. Don't stop until you're done."
bd update <id> --status in_progress → bd close <id>"Do a few tasks at a time."
"Use subagents."
Default to batched if the human hasn't expressed a preference.
For each task, follow plan.json steps exactly. Find the next ready task:
bd ready --label <feature> --json
Mark it in progress:
bd update <task-id> --status in_progress
Invoke oracle-testing patterns. For every task:
1. Write the failing test (from plan.json step)
2. Run it — verify it fails for the RIGHT reason
3. Write minimal code to make it pass (from plan.json step)
4. Run it — verify it passes
5. Refactor if needed (tests stay green)
6. Commit (with message from plan.json step)
Do NOT write implementation before tests. Do NOT skip "verify it fails." Do NOT write more code than needed to pass the test.
Mark the task done:
bd close <task-id> --reason "Implemented with tests"
When the plan or human references existing implementations ("make it look like the users table"), read the referenced code before making changes. A reference communicates all implicit requirements without spelling them out.
After each batch:
Completed: Tasks T1-T3
- T1: UserEntity with validation ✓
- T2: UserEntity tests (6 passing) ✓
- T3: UserRepository ✓
Test output: 6 passed, 0 failed
Type check: clean
Ready for feedback.
Wait. Don't continue until the human responds.
Expect short, terse corrections:
deduplicateByTitle."Don't ask for elaboration unless genuinely needed.
| Pattern | Example | What to do |
|---|---|---|
| Cherry-pick | "Use X for the first one. Ignore the fourth." | Item-level as directed |
| Trim scope | "Skip task T7." | Mark skipped, move on |
| Protect interfaces | "These signatures must not change." | Adapt callers |
| Override | "Use the library's built-in method." | Direct override |
| Revert | "I reverted. Now just do X." | Respect narrowed scope |
If the human reverts git changes and re-scopes, respect the narrowed scope completely. Don't salvage the previous approach. Don't ask "are you sure?"
STOP immediately when:
When you stop:
Do not guess. Do not work around it. Stop and ask.
If the plan needs to change:
"This needs a plan revision. Want me to go back to spec-plan?"
If the design was wrong:
"This changes design assumptions. Want me to go back to spec-research?"
When all tasks are done, verify and present the work.
bd list --label <feature> --json — all tasks must be closedPresent to the human:
## Feature Complete: {feature name}
**Tasks:** {completed} / {total}
**Tests:** {new tests added}, {total passing}
**Files:** {created}, {modified}
### What was built
- [concise list of what was implemented]
### Verification
- Test suite: ✓ all passing
- Type check: ✓ clean
- Lint: ✓ clean
### Ready for review
Offer the human their options:
Merge — squash and merge into main PR — create a pull request for team review Keep — leave the branch for now, come back later Discard — delete the branch, start over
Don't choose for them. Present options and wait.
If validation finds bugs, loop back to implement. See spec-orchestrator for iteration patterns.