arthai-marketplace

Workflow Comparison — Which Skill Should I Run?

The toolkit ships several orchestration workflows. They overlap in places and diverge in others. This guide answers two questions:

  1. Given my situation, which one should I run?
  2. What does each one actually do, and what does it produce?

Looking for the catalog of every skill? See skills-reference.

TL;DR Decision Tree

What do you have?
│
├── A clear goal but no clear plan? ─────────────────► /goal <objective>
│       e.g. "Cut homepage LCP under 2s"
│       e.g. "Make this endpoint return paginated results"
│
├── A backlog of issues to drain? ───────────────────► /autopilot
│       e.g. "Work through these 8 issues while I'm away"
│
├── A spec / well-defined feature to ship? ──────────► /planning → /implementation-plan → /implement
│       e.g. "Refactor the auth module per this PRD"
│       e.g. "Add user avatars (acceptance criteria below)"
│
├── A specific bug to fix (with reproduction)? ──────► /fix
│       e.g. "Fix #141 short session credit refund"
│
├── CI is broken? ───────────────────────────────────► /ci-fix
│       e.g. "build is red on main"
│
├── Need to deploy something? ──────────────────────► /deploy
│       e.g. "ship this to staging"
│
├── A tweet I want to evaluate as a feature? ────────► /monitor-tweet
│       e.g. "@anthropic just announced X — relevant?"
│
└── Already mid-session and lost track? ────────────► /continue
        re-reads state, picks up where you left off

The distinction that trips people up most: /goal vs /autopilot vs /implement.

You have… Run
One objective, fuzzy path /goal
Multiple issues, ranked queue /autopilot
One feature, written-down plan /implement (after /planning → /implementation-plan)
One bug, clear repro /fix

The Workflows

/goal — Speed-First Single Objective

When to use it: You know where you want to land but not how to get there. Exploratory, single objective. Fast.

How it works:

/goal <objective>
   │
   ▼
SCOUT  ── reads .claude/knowledge/shared/* + project-profile.md + prior goals FIRST,
   │      then targeted codebase scan to fill gaps
   ▼
CLARIFY  ── 3-5 context-aware questions (skips what the KB already answered)
   │      ◄── user answers (or "go" for defaults)
   ▼
CONFIRM PLAN  ── present clarified plan, wait for y/n/d
   │      ◄── user says "y"
   ▼
LOOP: pick action ──► execute ──► VERIFY (mandatory: lint + types + tests)
   │                                       ──► capture evidence (with verified flag)
   │                                       ──► self-evaluate done_when
   │  (auto-continue between turns via Stop hook)              │
   ▼                                                            ▼
all subtasks done + all evidence verified + requirements satisfied
   │
   ▼
ready for /pr (HARD STOP) ──► after /pr: append to goals-history.md

Example:

/goal Cut homepage LCP below 2s on mobile

→ Scout reads app/page.tsx, identifies hero image and analytics blocker, proposes 4 subtasks each with done_when clauses, kicks off the first action. After 5–7 turns of scout → edit → test → measure, stops at PR creation.

State: .claude/.goals/current.json (one active goal at a time) Stops at: PR creation (you run /pr yourself) Auto-continues between: every turn, via goal-auto-continue Stop hook Lifecycle: /goal pause, /goal resume, /goal clear, /goal status Produces: branch, commits, evidence log, PR-ready summary

Best for: “Make X happen” objectives where the what is clear but the how is exploratory.

/autopilot — Rigor-First Backlog Loop

When to use it: You have a queue of issues and want them worked through with risk gating, evidence capture, and a PR per item.

How it works:

/autopilot
   │
   ▼
ASSESS ─► CLASSIFY ─► VERIFY ─► PLAN ─► IMPLEMENT ─► QA ─► SELF-REVIEW ─► PR
   │       (P0–P5)    (risk    (repro?)        ▲                            │
   │                   0–12)                   │                            │
   │                                           │                            ▼
   ▼                                           │                       AWAITING_MERGE
priority_queue                                 │                            │
                                               └─ auto-continue between ────┘
                                                  phases via Stop hook

Example:

/autopilot --urgent-first

→ Ranks open issues P0–P5, picks the most urgent, scores blast-radius/ reversibility/confidence/domain-sensitivity (0–12), refuses if score >= 11, escalates if >= 9, otherwise verifies repro, plans, implements with the right team (backend/frontend/QA agents as needed), runs tests, scope-guards, creates PR. Stops for merge approval. After merge, picks the next item.

State: .claude/.workflow-state.json Stops at: PR creation per item (mandatory human gate); blocks on risk escalation, scope drift, QA failures after 2 attempts, or per-item budget breach (>6 agents). Auto-continues between: assess → classify → verify → plan → implement → qa → self-review → pr (via autopilot-auto-continue Stop hook). Stays silent at human-gate phases (awaiting_merge, blocked, paused). Evidence: evidence[] array — git-diffs, test results, lint, types, PR link, review status. PR body is assembled directly from evidence (no recall). Completion criteria: completion_criteria[] — each criterion has a done_when clause the model self-evaluates against captured evidence. Produces: PR per item, evidence trail, session summary

Best for: Backlog burndown when you want a consistent process per item, and the items are well-shaped enough to not need bespoke planning.

/planning — PRD Generation (Phase 1 of 2)

When to use it: You have a feature to build and want a written PRD (user stories, journey, edge cases, success criteria) before any architecture decisions are made.

How it works: spawn a product-manager (Sonnet) to write the PRD, with a brief feasibility-only note from the architect (no API design, no task breakdown, no debate). Design Thinker feeds UX context into the PM by default (skip with --no-design); GTM Expert can contribute positioning (--gtm).

Produces: .claude/specs/<feature>.md — the PRD, plus a design spec HTML by default.

Best for: Getting the user stories and scope reviewed before spending a debate cycle on architecture. Follow with /implementation-plan once the PRD looks right.

/implementation-plan — Architecture & Design (Phase 2 of 2)

When to use it: You have a reviewed PRD (from /planning) and want the full architecture debate before code is touched.

How it works: reads .claude/specs/<feature>.md → spawns architect (Opus) + product-manager (Opus) + Devil’s Advocate → debates tradeoffs → finalizes plan. --design adds Design Thinker + Design Critic; --gtm adds a GTM Expert. --fast/--lite/--lite-strict control debate depth (see Arguments & flags).

Produces: .claude/plans/<feature>.md with scope, milestones, files, risks.

Best for: Non-trivial features where the plan itself is the deliverable.

/implement — Spec-Driven Team Build

When to use it: You have a plan (from /planning → /implementation-plan, or hand-written at .claude/plans/<feature>.md) and want a team to build it.

How it works: read the plan → spawn parallel agent team (backend + frontend + QA + red team) → each agent owns its layer → QA validates → red team challenges → finalize → ready for /qa commit and /pr.

Produces: code, tests, ready for PR.

Best for: Multi-layer features once a plan exists. Heavier than /goal — appropriate when you want explicit per-agent ownership and a paper trail of debate.

/fix — Formal Bug-Fix Pipeline

When to use it: A specific bug with a reproduction or issue number.

How it works: RCA → scope lock → behavior contract → fix → differential test → regression proof.

Produces: minimal-scope fix, regression test, PR.

Best for: Targeted bugs where you want guard-rails preventing scope creep.

/ci-fix — CI Failure Remediation

When to use it: CI is red and you want it fixed without manual debugging.

How it works: fetch failing run → diagnose → fix → re-run (3 attempts max). Exhausted? → Discord alert + escalate.

Produces: fix commits, green CI (or escalation).

Best for: Build-on-fire situations.

/deploy — Deployment Pipeline

When to use it: Ready to ship to local, staging, or preview.

How it works: read /calibrate deployment knowledge → run platform- specific deploy → post-deploy health check → report.

Produces: deployed environment, health-check evidence.

Best for: Routine deploys. Refuses production — those go through your team’s review process.

/monitor-tweet — Tweet-to-PR Pipeline (partner installs only — requires source-repo access)

When to use it: You saw a tweet about a feature/idea and want to evaluate whether the toolkit should adopt it.

How it works: TRIAGE (extract idea, research feasibility, audit toolkit + arth) → present findings + BOTH repo options → user approves target + direction → build → review → /pr (auto).

Produces: PR (toolkit or arth) implementing the tweet’s idea.

Best for: Triaging external feature ideas without manually researching every one.

Quick Reference: Example Scenarios

Situation Run
“Work through these 8 issues while I’m away” /autopilot
“Make this API endpoint return paginated results” /goal
“Refactor the auth module, here’s the spec” /planning → /implementation-plan → /implement
“CI is broken on main” /ci-fix
“Deploy to staging” /deploy staging <service>
“Write the PRD before building” /planning
“Debate the architecture before building” /implementation-plan (after /planning)
“Fix bug #141” /fix #141
“Saw an interesting tweet” /monitor-tweet "<tweet text>"
“Cut LCP under 2s” /goal Cut LCP under 2s on mobile
“Get the build green” /ci-fix
“Pick up where I left off” /continue
“What should I work on?” /onboard

Auto-Continue & State

Both /goal and /autopilot use Stop hooks that nudge the model to auto-continue between phases without the user having to type “continue”:

Both hooks stay silent at human-gate moments (PR review, blocked, paused, awaiting merge, done). Both have loop-guards: after a fixed number of consecutive Stop events with no progress (12 for /goal, 15 for /autopilot), the hook bails and waits for the user.

The triage-router (UserPromptSubmit) detects active state and routes follow-up messages back to the active workflow. If the user types an unrelated slash command, the active workflow auto-pauses and the new request runs normally.

State files:

Workflow State file
/goal .claude/.goals/current.json (+ archive/)
/autopilot .claude/.workflow-state.json
/planning .claude/specs/<feature>.md
/implementation-plan .claude/plans/<feature>.md
/implement .claude/.implement-state.json
/fix .claude/.fix-scope-lock.json, .fix-behavior-contract.md

Choosing Between /goal and /autopilot

Both are autonomous loops. Both stop at PR creation. Both auto-continue. The difference is shape of the work:

Dimension /goal /autopilot
Number of items 1 freeform objective N issues (P0–P5 ranked queue)
Pace Action → action → action → PR Item → PR → wait → next item
Risk gating Implicit (escalate when needed) Explicit CLASSIFY phase per item
Default model Inline + Sonnet only when needed Sonnet team per item
Best for “Find the path to X” “Drain my queue”
Spawn budget 6 agents/goal 6 agents/item
Stops at PR for the goal (once) PR per item (every time)

If your work is “I have a destination, figure out the path” — that’s /goal.

If your work is “I have a stack of well-scoped tickets, work them” — that’s /autopilot.

If your work is “I have a written spec, build it” — that’s /implement.