arthai-marketplace

/implement

Spin up an implementation team from a plan.

Synopsis

/implement <feature-name> [--frontend-only] [--backend-only] [--no-redteam] [--redteam-once] [--redteam-once-strict] [--redteam-strict] [--tasks] [--resume-from] [--phase] [--phases] [--all-phases] [--workflow|--classic]

When to use it

Running in CI/autopilot: when CLAUDE_AUTOPILOT=1 or CI=true, the mode prompt is skipped and you must pass the feature name plus an explicit red-team flag (--no-redteam, --redteam-once, or --redteam-strict) on the command line — otherwise the run exits with a missing-args error.

Quickstart

/implement dark-mode

What you’ll see: a mode prompt (Auto / Guarded / Fast / Strict), then a team builds the plan’s tasks, red team findings get challenged and fixed, QA runs at the level you pick, and the flow ends with an open PR.

Examples

/implement dark-mode                       # full team per the plan's layers, mode prompt
/implement fix-component --frontend-only   # frontend + qa only, no backend agent
/implement add-api --backend-only          # backend + qa only
/implement dark-mode --no-redteam          # Fast mode — build only, skip red team
/implement dark-mode --redteam-once        # Guarded — one red-team pass at the end
/implement dark-mode --redteam-strict      # block on any unresolved HIGH finding
/implement big-feature --phase 2           # multi-phase plan: run only phase 2
/implement big-feature --phases 2-4        # run a contiguous phase range
/implement big-feature --all-phases        # run all remaining phases sequentially

Arguments & flags

Flag Values Default What it does
--frontend-only — off Force frontend-only, even if the plan says both layers. Mutually exclusive with --backend-only — passing both errors out.
--backend-only — off Force backend-only, even if the plan says both layers. Mutually exclusive with --frontend-only — passing both errors out.
--no-redteam — off Fast mode — skip the red team entirely
--redteam-once — off Guarded mode — one red-team pass after the build. Auto-escalates to block-on-HIGH when ≥2 HIGH findings or any HIGH touches auth/payments/migrations/crypto/pii.
--redteam-once-strict — off Same as --redteam-once but disables the auto-escalation — accepts the once-pass verdict as-is even on HIGHs
--redteam-strict — off Strict mode + block on ANY unresolved HIGH finding (1+). Default Strict only blocks when 3+ HIGHs are unresolved. Both modes always block on unresolved CRITICALs.
--phase N number — Multi-phase plans: execute only phase N
--phases N-M range — Multi-phase plans: execute a contiguous range
--all-phases — off Multi-phase plans: execute all remaining pending/failed phases
--tasks "T3,T4" task IDs — Build only the listed task IDs from the plan (unknown IDs warn; zero matches exits)
--resume-from N step number — Resume a previous run at step N with safe defaults; an explicit red-team flag overrides resume’s forced once mode
--workflow — off Experimental. Run red-team finding generation as a 2-task dynamic Workflow with structured findings (needs Claude Code ≥ 2.1.154); any Workflow failure falls back to classic automatically. Not yet recommended for routine use.
--classic — on (default) Today’s SendMessage-based red-team behavior. Use this by default — it’s the default until the --workflow path is validated.

What it does

  1. Plan resolution — if no feature name was given, a picker lists available plans (user-confirmation checkpoint). Loads the plan and the matching PRD spec (user stories + edge cases) for traceability.
  2. Phase detection — multi-phase plans get per-phase state tracking in .claude/plans/<name>.state.json. If the plan changed since the last run, a phase was interrupted, or all phases are complete, the skill asks how to proceed (user-confirmation checkpoint).
  3. Mode selection — unless a red-team flag was passed, asks Auto / Guarded / Fast / Strict (user-confirmation checkpoint). Auto picks from plan size and risk keywords (auth, payments, data migration, security, PII → Strict): fewer than 3 tasks and fewer than 5 files → Fast; fewer than 3 tasks with 5+ files → Guarded; 3-9 tasks with no risk keywords → Guarded; 10+ tasks or any risk keyword present → Strict.
  4. Context gathering — explore-light scans existing code patterns; topic wikis and the knowledge base are consulted so agents match the project instead of inventing patterns.
  5. Spawns the team in parallel — backend and/or frontend per the plan’s layers, plus QA. Backend shares the API contract with frontend before either implements; QA traces every user story and edge case to code.
  6. Red team — red-challenger generates attack scenarios against the diff; red-reviewer checks plan compliance (no scope creep, no gaps). Developers must answer each finding FIXED / DEFENDED / ACKNOWLEDGED. Unresolved CRITICALs block — user-confirmation checkpoint: fix / override / abort. Max 2 cycles.
  7. Phase loop (multi-phase only) — in one-phase-at-a-time mode, pauses between phases and asks whether to proceed (user-confirmation checkpoint); failed phases prompt retry / skip / stop.
  8. Post-implementation workflow — asks what QA level to run (commit / full / staging / skip — user-confirmation checkpoint), runs /qa, restarts local servers and waits for your manual test sign-off (user-confirmation checkpoint: ready / issues), then creates the PR via /pr --skip-qa and asks what’s next.

With --workflow, the red-team finding generation in step 6 runs as a 2-task dynamic Workflow that returns structured findings (severity, file, line) instead of free-text reports — the challenge-defend cycle, verdict gate, escalation rules, and cycle cap are identical either way, and any Workflow failure falls back to classic automatically. Classic is the default until the workflow path is validated.

Agents spawned

Agent Model tier Role
explore-light haiku Pattern scan before coding
backend (python-backend, adaptive to any stack) sonnet Backend tasks
frontend sonnet Frontend tasks
qa sonnet Story/edge-case coverage review + validation
red-challenger (qa-challenger) sonnet Attack scenarios against the diff
red-reviewer (code-reviewer) sonnet Plan-compliance review
completion-verifier sonnet Final plan-vs-diff check

Output & artifacts

Troubleshooting

Problem Fix
no plans found in .claude/plans/ Run /planning <name> then /implementation-plan <name> first
missing required args in non-interactive mode CI/autopilot runs need the feature name plus a red-team flag (and a phase flag for multi-phase plans)
multi-phase plan detected but no phase arg Add --phase N, --phases N-M, or --all-phases
Red team keeps blocking on a finding you accept Reply path is offered at the block prompt — choose override to mark it ACKNOWLEDGED, or use --redteam-once for advisory-only HIGHs
State file ... is corrupted Accept the reset-to-pending prompt; completed work in git is untouched