| name | feature-slice |
| description | Use when implementing a story or user-facing feature on this repo once acceptance criteria exist. Trigger on "implémente la story", "nouvelle feature", "dev cette story", "feature slice". Not for bugfixes, refactors, or infra chores. |
Feature Slice
Builds one story as a vertical slice through clean-stack, using a sequential pipeline of specialized subagents with two human gates. The orchestrator (main loop) never writes feature code itself — it dispatches roles, relays compact reports, and enforces gates.
Hard rules
- No code before Gate 1. The architect's plan must be explicitly approved by the user first. No exceptions, not for "small" stories.
- Never commit, never open a PR. Only on explicit user request after Gate 2.
- Mockups are law. If the story involves UI visuals, mockup image files must exist on disk before the front phase (ask the user for paths, or
docs/stories/<slug>/). Subagents cannot see conversation images — only files they can Read. Pixel-perfect or it's wrong; a blocking technical constraint gets reported before implementing around it.
- One story = one vertical slice. A story touching only one layer of a user-facing feature is mis-split — flag it before starting.
Pipeline
Run roles sequentially with the Agent tool. Each role's final message is a raw handoff report (paths, decisions, deviations — not prose) that feeds the next role's prompt. Skip back or front phases the story doesn't touch.
0. Intake (main loop) — restate the story and acceptance criteria. Fuzzy criteria → stop and brainstorm with the user. UI story without mockup files → ask for the paths now, not at step 4.
1. Explorer (Explore agent) — map what exists: target module, the closest precedent to imitate (aggregate/route/feature), schema impact. Returns: files to imitate, files to touch, gotchas.
2. Architect (Plan agent) — the prompt MUST require event storming first: enumerate the story's domain events — they ARE the business — then derive the aggregate/VOs (or a <Noun>Service when no aggregate; decide by aggregate, not I/O count). Then the slice plan: files per layer (domain → use case → Hono route → query/mutation factory in features/<x>/api/ → hooks → components → 2-file route) and the DoD obligations the implementers must honor: event emits with actor (actorUserId when actor ≠ subject), IInstrumentation spans on new I/O methods, ScopedRepository if the aggregate is owned, migration if schema changes.
→ GATE 1 — present the plan to the user, wait for explicit approval.
3. Back implementer (general-purpose) — receives the plan's back section + explorer brief. Strict TDD (superpowers:test-driven-development): domain → application → route. Layer rules auto-load via apps/api/src/modules/CLAUDE.md the moment it touches module files — its prompt carries the acceptance criteria, not a re-derivation of the rules.
4. Front implementer (general-purpose) — receives the plan's front section + mockup file paths. First action: Read every mockup. Then factory → hooks → components → 2-file route. Rules auto-load via apps/app/src/features/CLAUDE.md.
5. Adversarial reviewer (feature-dev:code-reviewer) — attacks the full diff against the acceptance criteria and the 8 cross-cutting rules in the root CLAUDE.md (silent state change, missing actor, missing span, scope leak…), then the orchestrator runs the gates:
pnpm ci:check && pnpm turbo run build type-check test && pnpm check:duplication && pnpm check:unused
Findings → fix loop: re-dispatch the relevant implementer (trivial fixes: orchestrator fixes directly), re-review. Loop until clean.
6. Demo prep (main loop) — run the app, exercise the slice end-to-end. UI story: Playwright screenshot of the rendered feature presented side-by-side with the mockup, plus the list of every deviation.
→ GATE 2 — the user reviews code and rendered result manually. Stop here. Commit/PR only if explicitly requested.
