From python
Routes tasks to appropriate spec skills like spec-research or spec-plan based on type, orchestrates workflow phases from research to finish. Use when starting conversations or tasks.
npx claudepluginhub martinffx/atelier --plugin pythonThis skill uses the workspace's default tool permissions.
<EXTREMELY-IMPORTANT>
Routes requests into spec-first workflows before substantial work like editing files, running state-changing commands, debugging, reviewing, planning, setup, updates, or architecture decisions.
Establishes spex SDD methodology: workflow routing, process discipline, spec-first principle, skill discovery. Invoke at start of spex conversations to select workflow skills.
Guides spec-driven development through phases: research, requirements, design, tasks, autonomous task-by-task implementation. Decomposes large epics into ordered specs with progress tracking.
Share bugs, ideas, or general feedback.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
You have skills. You MUST use them. Not "should." Not "when convenient." MUST.
Invoke relevant skills BEFORE any response or action. Even a 1% chance a skill might apply means you invoke it. If an invoked skill turns out to be wrong for the situation, you don't need to follow it. But you must check.
Never write code until the human has reviewed and approved a written plan.
Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The spec can be short, the plan can be brief, but you MUST present them and get approval.
Every feature produces two artifacts in docs/specs/YYYY-MM-DD-<feature>/:
spec.md ← spec-research (requirements + research + architecture)
plan.json ← spec-plan (tasks, dependencies → feeds beads)
spec-research → Discovery + research + architecture → spec.md
spec-plan → Implementation plan + tasks → plan.json
spec-implement → Execute tasks, track progress, report
spec-finish → Post-implementation validation
code-subagents → Parallel dispatch, two-stage review
oracle-architect → DDD patterns, component responsibilities
oracle-testing → TDD patterns, boundary testing
spec-research → spec-plan → spec-implement → spec-finish
spec-research (research-heavy) → spec-plan (targeted) → spec-implement
oracle-testing
oracle-architect
If genuinely trivial (typo, single-line config, variable rename) — skip the pipeline. But be honest. If there's any doubt, plan it.
| After completing... | The ONLY next step is... |
|---|---|
| spec-research | spec-plan |
| spec-plan | spec-implement |
| spec-implement | spec-finish |
Do NOT jump from requirements to code. Do NOT jump from research to implementation.
The workflow is not purely linear. Expect backflows:
If you loop 2+ times on the same issue, stop and ask the human:
"We've looped on [issue] twice. Should we reconsider the approach?"
| What you're thinking | Why it's wrong |
|---|---|
| "This is too simple for a plan" | Simple tasks have the most unexamined assumptions |
| "I already know how to do this" | Knowing how ≠ having the human's approval for how |
| "The human seems impatient" | Wasting time on wrong code is worse than planning |
| "I'll just do a quick prototype" | Prototypes become production. Plan it. |
| "I need to explore the code first" | That's the research phase. Write it in spec.md. |
| "Let me just fix this one thing" | One thing becomes three. Plan it. |
| "I can plan in my head" | Plans in your head can't be reviewed or annotated |
| "This is just a refactor" | Refactors touch more code than features. Plan it. |
| "I'll write the plan after" | Post-hoc plans are fiction. Plan before. |
| "I need more context first" | Skills tell you HOW to gather context. Check first. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I know what that skill says" | Skills evolve. Read current version. Invoke it. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
Process skills (spec-research, spec-plan, spec-implement, spec-finish): Follow exactly. Don't adapt away discipline.
Knowledge skills (oracle-architect, oracle-testing): Adapt principles to context. These inform decisions within the workflow.
Process skills come first. Knowledge skills get invoked by process skills when needed.
"Add X" or "Fix Y" doesn't mean skip workflows. Instructions say WHAT, not HOW. The skills define HOW.