workflow-intake

name

workflow-intake

description

Single entry point — classify ANY incoming prompt into a lifecycle route (build/change the product through the 9 phases) OR a direct route (one-off task dispatched straight to a skill), set mode, then dispatch. Nothing dead-ends. Use when: a new prompt arrives and the route is unknown, starting any harness session, deciding between bootstrap/feature/bugfix, onboarding a legacy repo, a one-off ask (explain/fix/review/research/design/test/config), or a request is too vague to act on yet.

Incoming request: $ARGUMENTS

One-Liner

Never act before you classify: read state → pick a route → set mode → dispatch. The router owns no work itself; it guarantees every run starts in the right mode AND that no request dead-ends — there is always a route, including a direct catch-all for one-off asks that don't belong to the lifecycle.

Two families of route:

• Lifecycle (A) — the request builds or changes the product. Runs the full 9-phase machinery: creates/advances a US, sets persona/autonomy/collab, tracks a session, runs review + tests + verify.
• Direct (B) — the request is a one-off task (understand, fix, review, research, design, test, config). Dispatched straight to the matching skill chain. No US, no full gates, lightweight trace.

Classify the prompt, (for lifecycle) confirm with the user, set the run's mode, then dispatch. Every gate uses the ask-user capability (../../resources/agent-tool-mapping.md).

Phase 0 — Read current state (always first)

./harness status      # backlog, WIP, blocked
./harness resume      # computed next step (when a session was in progress)

Empty-request guard: if the prompt is not actionable (., ok, hi, continue, blank, a greeting) — do NOT classify or dispatch. Report the state above and ask what the user wants. Never auto-start bootstrap just because the repo is empty. Gate: current backlog/WIP/blocked state is in hand, and the prompt is actionable (not empty).

Phase 1 — Classify & confirm

First decide the family with one question: does this request build or change the product through the lifecycle (A), or is it a one-off task to act on now (B)? Then pick the case within that family.

Dispatch = read and follow the linked SKILL.md (do not act on the bare name).

Family A — Lifecycle routes (full 9-phase machinery; continue to Phase 2–4)

Case	Signal	Dispatch
1. New project	empty/greenfield repo; "build me a …"	workflow-bootstrap
2. Execute a US	a backlog US id; "do F12"	analyse US → split child-tasks F<id>-T<n> → workflow-feature / workflow-bugfix
3. Add feature	existing harness repo + new capability	read source (core-explain) → BA delta → add US → workflow-feature
4. Legacy onboard	"add harness to a non-harness project"	survey → docs → safe harness init → seed backlog

Family B — Direct routes (one-off; skip Phase 2–4, dispatch now, lightweight trace)

Case	Signal	Dispatch
5. Understand	"explain / where / how does X work", read-only inspection	core-explore → core-explain
6. Diagnose & fix	a concrete defect with no backlog US; "this is broken, fix it"	debug-diagnose → core-fix
7. Review	"review this diff / PR / security / refactor / QA"	check-code-review / check-pr-review / check-security-review / check-refactor / check-qa
8. Standalone craft	one-off design, test-authoring, or language task with no lifecycle	design: design-api/design-architecture/design-database/design-ui · test: test-unit/test-integration/test-e2e · language: resolve via experts-resolver.sh
9. Ops & config	harness/agent config, commit msg, PR, release, deploy	[update-config (host)] · / / /

Confirm policy:

• Family A — always confirm the case with the user (click-select) before dispatching; re-classify on correction.
• Family B — dispatch immediately; confirm only when the sub-type is genuinely ambiguous.
• Escalation — if a direct task turns out to need lifecycle treatment (touches many files, needs review + tests + verify, or the user wants it tracked), stop and re-route to Family A (case 2/3).

Gate: exactly one route is chosen; for Family A the user has confirmed it (click-select); for Family B a skill chain (or the catch-all) is selected so the request never dead-ends.

Phases 2–4 are Family A (lifecycle) only. Family B (direct) routes skip them: no persona/autonomy/collab ceremony and no required session — dispatch the chosen skill chain now and record a one-line trace (.harness/trace.md). Start a session only if the task escalates to Family A.

Phase 2 — Persona & autonomy (persist to context.json)

Per ../../resources/persona-mode.md and ../../resources/autonomy-mode.md:

Always ask for user_role — never default it. Unless the user has explicitly stated their persona this session (e.g. "I'm non-technical", "treat me as a developer"), use the ask-user capability (../../resources/agent-tool-mapping.md) to have them pick before continuing. A value already sitting in context.json from a prior session does not count as answered — confirm it. Do not present Developer as a pre-selected default.

Ask: "How should I work with you?" → Developer / Non-Technical / Product.

Only after the user picks, persist it:

./harness config set user_role <chosen>           # Developer | Non-Technical | Product
./harness config set auto_advance false            # true for Non-Technical

• Developer → gated, exhaustive questioning, trade-offs surfaced.
• Non-Technical → auto-advance between USs, requirement-level questions in plain language, technical defaults chosen + logged.
• Autonomy defaults to gated; switch to auto only if the user explicitly asks for an unattended run. Record the mode in the task-state Mode: field.

Gate: user_role was chosen by the user this session (not silently defaulted); user_role + auto_advance are persisted to config and reflected in the task-state Mode:.

Phase 3 — Collaboration mode

Record solo (default, global WIP=1) or team (per-assignee claim + branch + PR gate, see workflow-team) in the task-state Collab: field. Detect team when the user mentions multiple people/agents or features.json already has an assignee/branch; when ambiguous, ask-user.

Gate: the task-state Collab: field reads solo or team.

Phase 4 — Start session

./harness session start --goal "<intent>"

Gate: a session is active and control has been handed to the dispatched workflow.

Cross-cutting rules (every route)

• Step-gate — after each phase, confirm before advancing per ../../resources/step-gate.md; in auto, log the decision instead.
• Full gates — every executed US runs review + the required test types + verify.
• Caveman (on by default) — apply opt-caveman to every inter-agent prompt and subagent result, and write long artifacts to files; this is a standing rule for all routes, not opt-in (../../resources/token-budget.md).
• Tracking — record each step as a harness task; bookend with session start/stop.
• Task-state — right after ./harness start <id>, expand .harness/tasks/<id>.md to the full template and update + commit it at every phase boundary (../../resources/task-state.md).