/continue

The operational heart of the system. When the developer types /continue (or "continue working" / "המשך לעבוד"), execute the thirteen steps below.

By default /continue is step-by-step: it pauses after each step for a quick confirm/adjust before moving on, so the developer keeps the wheel. The sibling /continue-yolo runs the same thirteen steps autonomously — no between-step pauses, stopping only at the mandatory step-6 plan pause and hard gates. Pick /continue to supervise; /continue-yolo when you trust the run.

Each step maps to a known failure mode of ad-hoc AI usage. Do not skip steps; if a step's infrastructure is not yet wired (flagged Not yet wired below), degrade explicitly — state what is missing and continue manually. Never fake a missing dependency with a placeholder (see the feedback_no_placeholder_workarounds personal-memory convention).

Source of truth for the loop: ai-engineering-strategy.md §8. This command is the executable form.

Invocation modes

The developer never needs to memorize step numbers. They say what they want in plain language ("open the PR", "let's plan this", "what's next") and you map it to the right step — that mapping is the [bewith continue-intent] guidance, your job, not theirs. The numbered forms below are an internal addressing mechanism and a power-user shortcut; lead with the action in words.

/continue takes an optional argument that controls where it starts and whether it pauses:

Invocation	Starts at	Pauses between steps?
/continue	the right step for the task's current state (resume), else step 1	yes (default)
/continue <n> · /continue step <n>	step <n> only — runs that one step, then stops	n/a (single step)
/continue from <n>	step <n>, then onward	yes
/continue-yolo (sibling command)	resume / step 1	no — autonomous; step 6 + hard gates only

Resume: with no argument, infer the current step from task + branch + PR state (e.g. a pushed branch with an open PR → you're at step 11) and start there rather than re-running completed steps. State which step you're resuming at before running it.

Pause behavior: between-step pausing is the default for bare /continue. A developer who wants bare /continue to run through can set continueStepPause: false in ~/.bewith/config.json (then /continue behaves like /continue-yolo). /continue-yolo always runs through regardless of the config. Step 6 (the plan) always pauses in every mode — it is a Hard-Floor pause, not a between-step one.

Missing essentials: each step lists what it Needs. When you start mid-loop (/continue <n> / from <n>) or resume, first check the step's Needs; if a prerequisite is missing, name the step that produces it and offer to run that first — never fabricate the missing input (a placeholder plan, an invented file set, a fake agent load). This is the step-level form of the no-placeholder rule.

Step index

#	Step	Needs (essentials)
1	Load Governance (lazy)	the repo's CLAUDE.md (outside a repo: the workspace root from ~/.bewith/config.json)
2	Identify the active task	a task for the actor with a repo pointer + a readable design reference (hard gates)
3	Reconcile state	the task from step 2 — read its content, not its tags
4	Evaluate policies	the task's intended file set + the plugin policies/
5	Load required expert agents	required_agents from step 4
6	Build/update the plan ⟵ always pauses	the task + policy context (steps 2–4)
7	Create/update the branch	the approved plan + task id (step 6)
8	Implement in chunks	the plan + branch (steps 6–7)
9	Run local verification	a working tree with changes + the repo's verify scripts
10	Open the pull request	committed chunks on a pushed branch (steps 8–9)
11	Handle code review	an open PR (step 10) + review comments
12	Wait for merge	an approved PR
13	Monitor and close	a merged PR + a target environment to watch

The thirteen steps

Step 1 — Load Governance (lazy)

Read the repo's CLAUDE.md (router + global rules only, ~10–15KB). Do not load every agent/skill now — that happens at step 5, after policies tell you what is needed. This prevents loading 400KB of context for a one-line change.

Launched outside a repo? If /continue is invoked from a directory that is not a repo (e.g. $HOME), there is no CLAUDE.md to read and no repo context — don't run the loop blind. First resolve the workspace root: read the bewith CLI config at ~/.bewith/config.json, take its sandboxDir, and the workspace root is that directory's parent (workspaceRoot = dirname(sandboxDir) — the repos are checked out as siblings of sandbox). Discover the repos under it. The task you pick in step 2 names the repo it targets; cd into that repo and load its CLAUDE.md, then continue. If you cannot resolve a workspace root (no config, no sandboxDir), or the task names no repo (see step 2), stop and ask rather than guessing a directory.

Step 2 — Identify the active task

Check for an in-progress GitHub Issue assigned to the current actor; if found, read its "AI Context" block. Otherwise fetch the actor's open ClickUp tasks and present the list — do not auto-pick (prevents "AI started the wrong ticket"). If multiple users are assigned to one task, stop and ask who is doing the work (prevents the claim race).

No CU in context (ad-hoc / work-first start). When work began without a CU-id — Claude or the developer started building directly, not from a ticket — do not proceed CU-less; the step-10 PR-title gate blocks at the end anyway, so resolve traceability up front. In order: (a) ask the developer for the CU; (b) if they don't have one, search ClickUp for an existing match — first their open tasks (reuse /next-task / /status), then a broader search across open tasks not assigned to them (the work may already be ticketed under someone else or sitting unassigned); (c) if a match is found, confirm it with the developer and link it; (d) if none exists, offer to open a new task (assigned to the developer, in the active sprint) and use its CU. Proceed only once a CU is resolved. In the standard task-first flow this branch is a no-op — the CU is already known.

A seeded task is a candidate, not an approval (confirm gate). A task passed as an argument (/continue CU-1234) or otherwise pre-selected is a candidate: state the pick with a one-line rationale and wait for explicit approval before step 3. This confirm holds in every non-yolo mode; only /continue-yolo skips it (and even yolo keeps the step-6 plan pause). Treating a seed as pre-approval is the "agent started an unapproved ticket and ran ahead" failure — the costliest trust break for adoption.

Before committing to a task, three pickup gates — derive what the task is and whether it's ready from its content, never from a guess:

Read the task from its content, not its tags. Determine the task's scope and readiness from the content — the linked PRD, the Design Doc, the GitHub Issue body / "AI Context" — and from concrete artifacts (does a branch exist? a PR? commits?). Labels and status tags (ai: in-progress, waiting for spec review, priority chips) are hints, not the source of truth: they're set by humans in a hurry, drift, and contradict each other. When a tag and the content disagree, the content wins — surface the discrepancy (see step 3) rather than acting on the tag. (What each label should mean, and when a tag is authoritative, is a separate mechanism worth defining on its own; for pickup, read the content.)

No repo pointer → ask, don't guess (hard gate). A task is only actionable once you know which repo it targets. Find it in the content: a Project/repo field, a linked GitHub Issue, or a repo named in the "AI Context" / PRD / Design Doc. If none exist, stop and ask which repo — never infer it from the title. A missing repo pointer is a Definition-of-Ready gap (product-rd-handoff.md), not a detail to fill in by guessing — proceeding writes the right change to the wrong place. Once the repo is known, state-sync records the Issue↔ClickUp link so the next session inherits it (and resolves OBS-1's "which repo").

An unreadable design reference is a blocker, not a guess (hard gate — the highest-risk failure mode). If the task's design reference is a link you cannot fully read — a client-rendered claude.ai artifact that WebFetch truncates, a Figma frame with no Dev-Mode access, a binary the tools can't open — STOP and say so plainly: "I cannot read the design reference — blocker." Do not infer the spec from the link's title, URL, or surrounding prose and proceed. This assume-and-proceed path manufactures a plausible-but-wrong spec that survives all the way to shipped code — it is the single most expensive way the loop can fail. The handoff contract requires a machine-consumable design reference (code/components, not pixels — product-rd-handoff.md); one you can't read fails the Definition of Ready. The gate holds at pickup and again at step 6 — you cannot plan from a spec you have not read.

These three are hard gates: they block in every mode, including /continue-yolo (which otherwise stops only at the step-6 plan). A blocked pickup is reported and waits for the human — it is never resolved by assuming.

Step 3 — Reconcile state

Compare the GitHub Issue's updated_at with the local cache (.claude/session/active-context.json if present). If the Issue is newer, pull and reconcile — the Issue body wins ties. This makes mobile-resume and coworker-handoff transparent. Full algorithm: ai-engineering-strategy.md §14.3.1.

Reconcile contradictory readiness signals. Per step 2, state comes from content — so when the signals disagree, that contradiction is itself a pickup blocker. The classic case: a task tagged both ai: in-progress and waiting for spec review, with no branch and no commits. The tags say "being built"; the content (no branch, an unreviewed spec) says "not ready". Don't pick a side silently — surface the contradiction and ask which is current. A genuinely in-progress task has a branch and commits to show for it; their absence is the tell that the in-progress tag is stale.

Partial wiring: the active-context.json cache is not built yet. The state-sync skill (write side) is wired. Until the cache exists, reconcile from the GitHub Issue body directly and note that the local cache step was skipped.

Step 4 — Evaluate policies

Determine the files the task will touch. Run the Policy Engine against that file set: match every policy whose triggered_by globs hit. The policy files ship in the plugin, not the consumer repo — resolve their directory the way agent-guard step 2 describes (the installed plugin's policies/, or the working tree inside bewith-docs), then match the globs against the changed-file set. Aggregate from the matches: required_agents, required_gates, risk score, auto_workflows, and any human_approval_required conditions.

If a matched policy returns human_approval_required and the developer's configurable autonomy is gated for that class (autonomy-model.md), stop and request approval. Otherwise proceed.

Step 5 — Load the required expert agents

Invoke the agent-guard skill with the aggregated required_agents from step 4. It verifies every required agent is in context and loads any that are missing. Loading happens here, not at session start, because step 4 just told you what you need. Typical agent context: 50–70KB, not the whole roster.

Step 6 — Build or update the plan ⟵ the Hard-Floor pause

Read any existing plan in the Issue body; if absent, draft one — a numbered list of concrete steps (files to touch, tests to add, contracts to update, migrations to write). Present the plan and wait for human approval or correction. This pause holds in every mode — /continue, /continue from <n>, and even /continue-yolo — and regardless of autonomy settings: catching a wrong plan here is far cheaper than fixing wrong code later. (In bare /continue you're already pausing between steps; this is the one pause /continue-yolo cannot skip.) On approval, write the plan to the Issue body and proceed.

Step 7 — Create or update the branch

Check the current branch. If it matches the task's expected name ({actor}/{type}/{slug}_CU-{id}), continue; otherwise create it. The format is enforced by git-hooks/branch-name-check.sh regardless of who creates the branch.

Not yet wired: the working-state lease (§15.6) is deferred — the lease store/API live outside this repo and are not built. Until they are, skip lease acquisition and rely on the worktree pattern for concurrent-session safety.

Step 8 — Implement in chunks

Implement the plan one chunk at a time. After each chunk: write that chunk's tests (per the repo's testing strategy), stage and commit with a CU-id reference, and invoke the state-sync skill at meaningful checkpoints — it writes the "AI Context" block to the GitHub Issue and mirrors a condensed copy to the ClickUp ai_context field, keeping both trackers in step.

For a chunk with non-trivial logic, drive it test-first via test-driven-development (failing test → minimum code → refactor) rather than writing tests after. When a chunk requires heavy context (large reads, a browser session, wide log/DB output), apply delegate-heavy-context — push it into a subagent and move large intermediate context as files, not pasted into the thread, so the loop stays cheap across chunks.

Partial wiring: the per-machine local cache (.claude/session/active-context.json) is not built. state-sync writes the authoritative GitHub Issue + ClickUp mirror today; until the cache exists it skips the local-cache write and says so.

Step 9 — Run local verification

Run /verify — the repo's verification (verify.sh if present, otherwise the defined lint / test / typecheck / build scripts, and contract validation where it applies). If something fails: fix it when the fix is small and clearly in scope; escalate to the developer when it is non-trivial or out of scope.

When a failure resists a quick fix — you've tried and it still fails — switch to systematic-debugging (reproduce → isolate → hypothesize+instrument → fix+verify, hard stop after 3 failed attempts) instead of repeated guess-and-check. Three failed fixes is the signal to re-isolate, not to try a fourth variation.

Step 10 — Open the pull request

Push the branch and open a PR. The title ends with the CU-id token (bare CU-<id> is the convention, uniform with the branch suffix _CU-<id>, e.g. fix(scope): summary CU-86c9v71z4; [CU-<id>] is also accepted). The closes #N reference (the GitHub Issue) and the ClickUp task link go in the body, not the title. Body also summarizes the change, lists test results, and references any ADRs. Default PR state is draft unless the developer asked for review (see the feedback_autonomous_pr personal-memory convention — open the PR without asking, but keep it draft by default).

CI wiring available: the ai-pr-review.yml workflow template auto-runs code-reviewer on the diff once a repo adopts it (informational, not a merge gate). In repos that haven't adopted it, run /pr-review inline before marking the PR ready.

Step 11 — Handle code review

If the PR gets review comments, run /address-review: it pulls every comment (any reviewer), applies the convergent ones (clear fixes) after sign-off, and escalates the divergent ones (approach disagreements) back to you as a question rather than coding them away silently. Do not auto-merge. A configurable gate may require explicit human approval before pushing review-response commits or posting reply threads.

Step 12 — Wait for merge

Wait for the human to merge (or merge yourself only if so configured). On merge, the Issue closes via closes #N. Run state-sync once more to flush a final "AI Context" summarizing what shipped — to both the GitHub Issue and the ClickUp mirror, so the daily/progress summary reflects the close.

Step 13 — Monitor and close

After merge, run the watch-deploy skill — it watches the deployment to its target environment and the (vendor-neutral) observability stack for the post-deploy window. If it succeeds and telemetry is clean, run /done — it invokes process-guardian to confirm the Definition of Done before moving the ClickUp status to "Done" (configurable gate; default autonomous after a clean deploy).

Partial wiring: the dedicated incident-response workflow is not built. watch-deploy flags a regression and routes it to devops-infra/observability; until the incident workflow lands, drive the response manually from there.

The loop is complete. You are ready for the next /continue.

What's wired today vs. coming this week

Wired now: the invocation modes (step-by-step /continue, autonomous /continue-yolo, single-step /continue <n>, /continue from <n>, the continueStepPause config, and per-step Needs/missing-essentials checks), lazy governance load, task identification (ClickUp/GitHub), policy evaluation, agent loading via agent-guard, the planning pause, branch creation + hook enforcement, chunked implementation, state-sync (GitHub Issue + ClickUp mirror, steps 8/12), the /verify / /pr-review / /done commands (steps 9/10/13), the ai-pr-review.yml CI template (step 10), watch-deploy (step 13), PR open, review handling, process-guardian DoD check.

Still deferred (external infra or out of scope, referenced by name so no rewrite is needed when they arrive): the per-machine local cache active-context.json (steps 3, 8) and the working-state lease (step 7) — both need a store outside this repo; the worktree pattern + "ClickUp assignee = owner" cover concurrency until then. The dedicated incident-response workflow (step 13) — watch-deploy routes regressions to the owners in the meantime.

Each "Not yet wired" note degrades to a manual action and a one-line statement of what was skipped — never a placeholder.

Cross-references

• ai-engineering-strategy.md §8 — the canonical thirteen-step definition this command executes.
• agent-guard — step 5: enforces required_agents from matched policies.
• policy-engine.md + policies/*.yaml — step 4 inputs.
• autonomy-model.md — the Hard-Floor + configurable gates that can stop the loop.
• session-safety.md — the worktree pattern standing in for the lease until it ships.
• process-guardian — step 13 Definition-of-Done gate.
• state-management.md — the "AI Context" block format (steps 3, 8, 12).