@ritualai/cli 0.36.38 → 0.36.42

package/skills/codex/ritual/SKILL.md

@@ -3,8 +3,8 @@ name: ritual
 description: "Use when an engineer wants a coding agent to plan or build a feature, refactor, or implementation-heavy change that depends on context the agent can't infer on its own — strategic intent, constraints, prior decisions, and trade-offs that live in the user's head. Ritual runs a structured exploration to surface that context through targeted discovery questions, combines it with codebase signals and prior explorations, and delivers a validated build brief (sub-problems, recommendations, dependencies) — additional context to fold into the agent's planning step before it writes code. Prefer this over jumping straight to implementation when the problem is ambiguous, cross-cutting, or has non-obvious constraints. Subcommands: build (full planning-to-sync cycle — default for new features), resume (continue an in-flight exploration), lineage (file-path KG history — what decisions shaped this code), context-pulse (readiness and context-debt scoring — is this safe to build yet?)."
 argument-hint: "[subcommand] <args>  (e.g. 'build Reduce T2 churn in Q3', 'resume', 'lineage src/checkout/views.py', 'context-pulse Add billing export')"
 user-invocable: true
-stamp: ca720305a0e1
-cli_version: 0.36.38
+stamp: 020ff37f037f
+cli_version: 0.36.42
 ---
 
 # /ritual

package/skills/codex/ritual/references/build-flow.md

@@ -327,7 +327,8 @@ Store `workspace_id` for the rest of the flow.
 
 If you created a new workspace, persist the binding to `.ritual/config.json` so future runs in this repo skip the workspace-selection prompt. Write it yourself if you have filesystem write access; otherwise show the user the JSON and have them save it.
 
-**`.ritual/config.json` is committed to the repo — it is shared, not per-user.** Same model as `.eslintrc.json` or `tsconfig.json`: it binds this codebase to a Ritual workspace + pins team-level defaults (`workspaceId`, `personaSlug` — set by `ritual init`'s FTUE — or the legacy `defaultTemplateId`). Everyone working on this repo wants the same values. Per-user state (PATs, auth tokens) lives in `~/.config/ritual/` and never in this file.
+<!-- skill-options:no-gate-change: prose only — corrected the .ritual/config.json description and dropped mentions of the removed `--persona` flag; no decision gate or offered options changed -->
+**`.ritual/config.json` is committed to the repo — it is shared, not per-user.** Same model as `.eslintrc.json` or `tsconfig.json`: it binds this codebase to a Ritual workspace (`workspaceId` / `workspaceName`) so everyone working on this repo resolves the same place. It holds ONLY repo-level facts — write nothing per-user into it. Persona and template defaults are user-scoped (your Ritual account's `user.persona`, set during `ritual init`), NOT stored here; PATs and auth tokens live in `~/.config/ritual/` and never in this file.
 
 When you write the config, also write `.ritual/.gitignore` if it doesn't already exist so any future per-user state files in this directory get ignored while `config.json` itself stays tracked:
 
@@ -620,12 +621,12 @@ Steps:
 <!-- skill-options:no-gate-change: f.1 is an OPTIONAL skippable sub-prompt nested in Step 1.5 step 6 (default skip); adds no tracked pause gate or Step header, so the structural fingerprint is unchanged (check-skill-options-contract green). -->
    f.1 **Unchosen-candidates gate (2026-06-14, unchosen-options → discovery worktrees).** The candidates the user did NOT pick are paths worth not silently dropping. Render ONE compact, SKIPPABLE prompt — for each unchosen candidate, the user can spin up **discovery now** (a background worktree reasons it to a build brief) or **log it as a future job**. Promote DELIBERATELY: the default is to drop. (This gate is itself skipped in autonomous/worktree mode — never spawn discovery recursively.)
 
+      <!-- skill-options:no-gate-change: prose-only copy tightening of the discover/next-job/skip descriptions; option tokens + gate unchanged -->
       ```text
-      You picked #{k}. The other {M} — want to keep any going?
-        • `discover <nums>`  — spin up discovery NOW in a background git worktree: an agent reasons it
-                               end-to-end to a build brief (reasoning only, no code). e.g. `discover 1`
-        • `next-job <nums>`  — just log it as a future job (a draft exploration in this workspace; nothing runs)
-        • `skip`             — drop them (default)
+      You picked #{k}. For the rest:
+        • `discover <nums>`  — explore unpicked option(s) in parallel; returns a build brief, no code.
+        • `next-job <nums>`  — save as future work.
+        • `skip`             — drop them. Default.
       ```
 
       Resolve the reply, then continue to Step 2 for the picked candidate:
@@ -700,7 +701,7 @@ Steps:
 
 #### Step 2 — Template selection (server-side, silent)
 
-> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy — the FTUE picker is gone; set only via `ritual init --persona`) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
+> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy fallback — no longer set during onboarding; not CLI-settable) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
 
 **For the agent: there is no template-selection step. Skip this Step entirely and go to Step 3.** Don't read `.ritual/config.json` for persona, don't try to call `list_templates` (it's not registered), don't render a "Using persona X" confirmation.
 
@@ -731,7 +732,7 @@ All atomic in one HTTP request. See `apps/api/src/modules/explorations/explorati
 
 Recognized roles (use the role keyword the API returns, not a paraphrase): `engineering`, `product`, `design`, `marketing`, `delivery`, `operations`.
 
-If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now; `ritual init --persona <slug>` only changes the legacy personal default).
+If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now).
 
 Proceed to Step 3.
 
@@ -1317,14 +1318,14 @@ Then summarize the created siblings in the dense-list format. Do not pause after
 
 Longest phase because generation is async + the user picks per-Area. (Internally the API field is `matter_id`; user-facing copy always says Area.)
 
-**Step 6 → Step 7 transition anti-pattern (load-bearing):** after `create_exploration` succeeds in Step 6, you MUST NOT render Step 8's *"Reply `run` to continue"* CTA. Required next actions, in order, before Step 8 is allowed:
+**Step 6 → Step 7 transition anti-pattern (load-bearing):** after `create_exploration` succeeds in Step 6, you MUST NOT jump to Step 8's answering/run — discovery questions must be generated, picked, and committed first. Required next actions, in order, before Step 8 is allowed:
 
 1. Call `mcp__ritual__suggest_discovery_questions(exploration_id)` (Step 7.1) — no user input needed; just kick it off.
 2. Poll `mcp__ritual__get_discovery_state(exploration_id)` until `ready: true` (Step 7.2).
 3. Render the **Area rail + Area 1's questions together** and walk Area-by-Area per § 7.3.1 (the rail orients; a rail with NO questions under it — a bare index — is the failure mode).
 4. `[USER PAUSE]` — the suggested-12 landing (§ 7.3.1): the user replies `proceed` (commit the 12), `expert` (walk + adjust; floor 6 to run, aim 15–20, no cap), or `pause`.
 5. Commit all picked Areas in ONE `mcp__ritual__accept_discovery_questions_batch` call (Step 7.4) — never one parallel call per Area.
-6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 and render the *"Reply `run` to continue"* CTA.
+6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 — but only **after the Step 7.4 `accept_discovery_questions_batch` response returns** (you need its `materialized[]` question ids to run against). For engineering/delivery/operations, then **auto-fire the run** (answer the picked questions + `submit_all_answers`, or the server fallback) — no `run` CTA, no pause. For product/design/PRD flows, render the `1`/`2` run-mode choice (stop-after-answers review vs run-through). Never start answering/running before the accept resolves.
 
 **Picking is a deliberate step-through, not a bulk action (load-bearing):** the user going Area by Area and choosing the questions that matter IS the value of discovery — that per-question judgment shapes the whole downstream chain. So **nudge the user to step through and pick**; don't lead with bulk shortcuts.
 - **Nudge to step through.** Walk the user Area-by-Area (drop into Area 1, `next`/`prev`) and invite deliberate picks per Area, with `show more` to expand an Area. The framing is "which of these should we dig into?", not "want all of them?".
@@ -1337,7 +1338,7 @@ Longest phase because generation is async + the user picks per-Area. (Internally
 - Calling `start_agentic_run` before at least 6 discovery picks have been committed for this exploration (via `accept_discovery_questions_batch`, or `accept_discovery_questions`). There is no skip-discovery exception.
 - Silently auto-picking all generated questions and proceeding to Step 8 — observed in agent output 2026-05-15 as "the engineering-mode default is to run, which skips the per-question picker." There is no such default; the picker is mandatory.
 - **Offering "or I'll default to taking all of them" (or any accept-all fallback), then committing the full set on an ambiguous reply** — observed 2026-06-05 (a `proceed` at this gate → `accept_discovery_questions_batch` with all 68 questions → a ~25-min run the user never chose). Accept-all is a legitimate choice **only when the user explicitly asks for it** — it is NEVER the default you offer, and NEVER the fallback. The default you offer + fall back to is always **the suggested 12 rendered on the landing**. An ambiguous reply (`proceed`/`go`/`ok`) at the pick gate means **accept those 12**, not the full set — structurally safe because the 12 are on screen in full.
-- Rendering "Next: run discovery through recommendations / Reply `run` to continue" anywhere in the chat before Step 7.4 has completed.
+- Starting Step 8 — auto-firing the answers (engineering) or rendering the product/design run-mode choice — anywhere in the chat before Step 7.4 has committed the picks.
 
 The picker is **not** a UI suggestion — it's the load-bearing decision gate where the user expresses what to investigate. Skipping it converts the agentic run into an automated "answer everything" pass and erases the user's judgment.
 
@@ -1623,28 +1624,24 @@ it's `/ritual build`.**
 
 Pick the path honestly; don't claim to answer from code you didn't read.
 
-<!-- skill-options:no-gate-change: Step 8 answerer is chosen by real repo-linkage (recon ran / code open), not by the /ritual build invocation; agent-answers when repo-linked, server-run fallback. Includes prose guidance on answer length (~300-600 words), that attached code is OPTIONAL illustrative reference (not part of the answer, not a verbatim copy), and a hard no-secrets/no-PII redaction rule for the BYO answerer. The run/pause gate + its options are unchanged — no new pause gate or Step header. -->
+<!-- skill-options:no-gate-change: Step 8 answerer is chosen by real repo-linkage (recon ran / code open), not by the /ritual build invocation; agent-answers when repo-linked, server-run fallback. Includes prose guidance on answer length (~300-600 words), that attached code is OPTIONAL illustrative reference (not part of the answer, not a verbatim copy), and a hard no-secrets/no-PII redaction rule for the BYO answerer. As of 2026-06-21 the engineering/delivery/operations run gate is REMOVED (auto-proceed after the §7.4 commit) — the options-contract drops that gate; no new pause gate or Step header is added. -->
 
-For `engineering`, `delivery`, and `operations` roles, show:
+For `engineering`, `delivery`, and `operations` roles there is **no run confirmation**: the user already chose "generate answers and recommendations" when they proceeded from the discovery pick gate (§ 7.3.1), so a second "ready to run?" prompt is redundant friction. **Auto-proceed with no `run`/`pause` CTA and no wait for a reply.**
+
+<!-- skill-options:no-gate-change: prose only — adds a strict accept-returns-before-run ordering precondition to Step 8 (and the §7-transition rule); no decision gate, offered option, or Step header is added, removed, or changed. -->
+**Strict ordering (load-bearing — do NOT skip, reorder, or parallelize):** the run begins **only after the Step 7.4 `accept_discovery_questions_batch` call has RETURNED its response**. That accept is what commits the picks and returns `materialized[]` (the committed question rows + their `id`s); you answer those exact ids. Do NOT call `write_answer_context`, `submit_all_answers`, or `start_agentic_run` before the accept resolves, and never fire them in parallel with it — there is no committed question set to run against until the accept returns. Removing the old `run` gate removed a human turn, NOT this dependency: await the accept, read `materialized[]`, then run. Once you have the accept response, print one non-blocking status line so the hand-off isn't silent, then begin:
 
 ```text
 Ritual build
 ✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Run discovery
-
-I'll answer the picked questions from the codebase, then generate
-recommendations. This usually takes a few minutes.
-
-Reply `run` to answer → generate recommendations.
-Reply `pause` to stop here.
+Answering your picked questions, then generating recommendations.
+This usually takes a few minutes — I'll keep working; nothing needed from you.
 ```
 
-(Match the first line to the path you'll actually take: repo-linked → "I'll answer the picked questions from the codebase…"; fallback → "Ritual will source answers for the picked questions…". Don't claim to answer from code if you're taking the server path.)
-
-Visible CTA is `run`. Accept `r`, `go`, `continue`, or `next` as aliases. Per `references/cli-output-contract.md` § Surface-aware continuation prompts, do NOT treat empty input as proceed inside agent chat.
+(Match the line to the path you'll actually take: repo-linked → "Answering your picked questions from the codebase…"; fallback → "Ritual is sourcing answers for the picked questions…". Don't claim to answer from code if you're taking the server path.)
 
-On `run`, **if you're genuinely repo-linked (per the check above), answer the questions yourself** (BYO-answerer; do NOT call `start_agentic_run`):
+**If you're genuinely repo-linked (per the check above), answer the questions yourself** (BYO-answerer; do NOT call `start_agentic_run`):
 1. The Step 7.4 accept (`accept_discovery_questions_batch`) returned `materialized[]` — the committed questions with their row `id`s. (If you didn't keep them, the same ids are what you passed to accept.)
 2. For each saved question, call `mcp__ritual__write_answer_context(question_id, content)` with an answer grounded in your reading of the codebase — the files you read at Step 5.7, the actual code, real constraints. Answer in PARALLEL where your agent supports it (e.g. one subagent per Area). The content is provisional + provenance-tagged agentic until saved; only the final saved set drives recommendations.
    - **Length:** keep each answer to **~300–600 words by default** — tight and grounded, not an essay. Go longer only when the question genuinely needs it.
@@ -1652,7 +1649,7 @@ On `run`, **if you're genuinely repo-linked (per the check above), answer the qu
    - **Never leak secrets or sensitive data.** A snippet is **illustrative, not a verbatim copy** — it only has to convey the shape/idea, so simplify and elide freely. **NEVER** include API keys, tokens, passwords, connection strings, credentials, `.env` values, real customer data, or PII — even if they're literally in the file you read. Replace them with obvious placeholders (`process.env.X`, `"<api-key>"`, `"user@example.com"`). The same goes for the prose: describe constraints without pasting secret values.
 3. When every committed question has answer context, call `mcp__ritual__submit_all_answers(exploration_id)` — it commits the set and triggers recommendation generation. Then go to the recommendation wait (Step 8.1, agent-answered path).
 
-**Fallback — server answers (no repo / nothing to ground in):** call `mcp__ritual__start_agentic_run` with `scope_type: 'exploration'` + `exploration_id`, then follow the server polling path (8.0 → 8.1).
+**Fallback — server answers (no repo / nothing to ground in):** only after the Step 7.4 accept has returned (the run needs the committed question set it produced), call `mcp__ritual__start_agentic_run` with `scope_type: 'exploration'` + `exploration_id`, then follow the server polling path (8.0 → 8.1).
 
 For `product`, `design`, or explicitly PRD-style flows where answer review is useful, offer two choices without time estimates (this path uses the SERVER answer engine so the user can review each generated answer — Step 8.5):
 

package/skills/codex/ritual/references/cli-output-contract.md

@@ -456,13 +456,11 @@ Visible CTA is `use`. Accept `lock`, `l`, `go`, `continue`, or `next` as backwar
 
 ### Engineering run mode
 
-For engineering / agentic-coding templates, do not offer answers-only review and do not mention time estimates. Use:
+For engineering / agentic-coding templates there is **no run CTA and no pause** — once the discovery picks are committed, auto-fire the run (answer the questions then `submit_all_answers`, or the server fallback) and proceed straight to recommendations. Do not offer answers-only review and do not ask the user to start the run. Print one non-blocking status line instead of a prompt:
 
 ```text
-Next: run discovery through recommendations.
-
-Reply `run` to continue.
-Reply `pause` to stop here.
+Answering your picked questions, then generating recommendations.
+This usually takes a few minutes — I'll keep working; nothing needed from you.
 ```
 
 ### Shipped work visibility

package/skills/codex/ritual/references/lite-flow.md

@@ -1,5 +1,5 @@
 <!-- GENERATED from references/build-flow.md by apps/cli/scripts/generate-lite-flow.js — DO NOT EDIT. -->
-<!-- source-sha: 251c9793521c8486 -->
+<!-- source-sha: eb820034fbf3ad8e -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -419,7 +419,8 @@ Store `workspace_id` for the rest of the flow.
 
 If you created a new workspace, persist the binding to `.ritual/config.json` so future runs in this repo skip the workspace-selection prompt. Write it yourself if you have filesystem write access; otherwise show the user the JSON and have them save it.
 
-**`.ritual/config.json` is committed to the repo — it is shared, not per-user.** Same model as `.eslintrc.json` or `tsconfig.json`: it binds this codebase to a Ritual workspace + pins team-level defaults (`workspaceId`, `personaSlug` — set by `ritual init`'s FTUE — or the legacy `defaultTemplateId`). Everyone working on this repo wants the same values. Per-user state (PATs, auth tokens) lives in `~/.config/ritual/` and never in this file.
+<!-- skill-options:no-gate-change: prose only — corrected the .ritual/config.json description and dropped mentions of the removed `--persona` flag; no decision gate or offered options changed -->
+**`.ritual/config.json` is committed to the repo — it is shared, not per-user.** Same model as `.eslintrc.json` or `tsconfig.json`: it binds this codebase to a Ritual workspace (`workspaceId` / `workspaceName`) so everyone working on this repo resolves the same place. It holds ONLY repo-level facts — write nothing per-user into it. Persona and template defaults are user-scoped (your Ritual account's `user.persona`, set during `ritual init`), NOT stored here; PATs and auth tokens live in `~/.config/ritual/` and never in this file.
 
 When you write the config, also write `.ritual/.gitignore` if it doesn't already exist so any future per-user state files in this directory get ignored while `config.json` itself stays tracked:
 
@@ -712,12 +713,12 @@ Steps:
 <!-- skill-options:no-gate-change: f.1 is an OPTIONAL skippable sub-prompt nested in Step 1.5 step 6 (default skip); adds no tracked pause gate or Step header, so the structural fingerprint is unchanged (check-skill-options-contract green). -->
    f.1 **Unchosen-candidates gate (2026-06-14, unchosen-options → discovery worktrees).** The candidates the user did NOT pick are paths worth not silently dropping. Render ONE compact, SKIPPABLE prompt — for each unchosen candidate, the user can spin up **discovery now** (a background worktree reasons it to a build brief) or **log it as a future job**. Promote DELIBERATELY: the default is to drop. (This gate is itself skipped in autonomous/worktree mode — never spawn discovery recursively.)
 
+      <!-- skill-options:no-gate-change: prose-only copy tightening of the discover/next-job/skip descriptions; option tokens + gate unchanged -->
       ```text
-      You picked #{k}. The other {M} — want to keep any going?
-        • `discover <nums>`  — spin up discovery NOW in a background git worktree: an agent reasons it
-                               end-to-end to a build brief (reasoning only, no code). e.g. `discover 1`
-        • `next-job <nums>`  — just log it as a future job (a draft exploration in this workspace; nothing runs)
-        • `skip`             — drop them (default)
+      You picked #{k}. For the rest:
+        • `discover <nums>`  — explore unpicked option(s) in parallel; returns a build brief, no code.
+        • `next-job <nums>`  — save as future work.
+        • `skip`             — drop them. Default.
       ```
 
       Resolve the reply, then continue to Step 2 for the picked candidate:
@@ -792,7 +793,7 @@ Steps:
 
 #### Step 2 — Template selection (server-side, silent)
 
-> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy — the FTUE picker is gone; set only via `ritual init --persona`) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
+> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy fallback — no longer set during onboarding; not CLI-settable) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
 
 **For the agent: there is no template-selection step. Skip this Step entirely and go to Step 3.** Don't read `.ritual/config.json` for persona, don't try to call `list_templates` (it's not registered), don't render a "Using persona X" confirmation.
 
@@ -823,7 +824,7 @@ All atomic in one HTTP request. See `apps/api/src/modules/explorations/explorati
 
 Recognized roles (use the role keyword the API returns, not a paraphrase): `engineering`, `product`, `design`, `marketing`, `delivery`, `operations`.
 
-If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now; `ritual init --persona <slug>` only changes the legacy personal default).
+If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now).
 
 Proceed to Step 3.
 
@@ -1381,14 +1382,14 @@ Surface a single compact summary after all registrations resolve:
 
 Longest phase because generation is async + the user picks per-Area. (Internally the API field is `matter_id`; user-facing copy always says Area.)
 
-**Step 6 → Step 7 transition anti-pattern (load-bearing):** after `create_exploration` succeeds in Step 6, you MUST NOT render Step 8's *"Reply `run` to continue"* CTA. Required next actions, in order, before Step 8 is allowed:
+**Step 6 → Step 7 transition anti-pattern (load-bearing):** after `create_exploration` succeeds in Step 6, you MUST NOT jump to Step 8's answering/run — discovery questions must be generated, picked, and committed first. Required next actions, in order, before Step 8 is allowed:
 
 1. Call `mcp__ritual__suggest_discovery_questions(exploration_id)` (Step 7.1) — no user input needed; just kick it off.
 2. Poll `mcp__ritual__get_discovery_state(exploration_id)` until `ready: true` (Step 7.2).
 3. Render the **Area rail + Area 1's questions together** and walk Area-by-Area per § 7.3.1 (the rail orients; a rail with NO questions under it — a bare index — is the failure mode).
 4. `**[LITE AUTO — no pause; auto-pick the recommended default]**` — the suggested-12 landing (§ 7.3.1): the user replies `proceed` (commit the 12), `expert` (walk + adjust; floor 6 to run, aim 15–20, no cap), or `pause`.
 5. Commit all picked Areas in ONE `mcp__ritual__accept_discovery_questions_batch` call (Step 7.4) — never one parallel call per Area.
-6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 and render the *"Reply `run` to continue"* CTA.
+6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 — but only **after the Step 7.4 `accept_discovery_questions_batch` response returns** (you need its `materialized[]` question ids to run against). For engineering/delivery/operations, then **auto-fire the run** (answer the picked questions + `submit_all_answers`, or the server fallback) — no `run` CTA, no pause. For product/design/PRD flows, render the `1`/`2` run-mode choice (stop-after-answers review vs run-through). Never start answering/running before the accept resolves.
 
 **Picking is a deliberate step-through, not a bulk action (load-bearing):** the user going Area by Area and choosing the questions that matter IS the value of discovery — that per-question judgment shapes the whole downstream chain. So **nudge the user to step through and pick**; don't lead with bulk shortcuts.
 - **Nudge to step through.** Walk the user Area-by-Area (drop into Area 1, `next`/`prev`) and invite deliberate picks per Area, with `show more` to expand an Area. The framing is "which of these should we dig into?", not "want all of them?".
@@ -1401,7 +1402,7 @@ Longest phase because generation is async + the user picks per-Area. (Internally
 - Calling `start_agentic_run` before at least 6 discovery picks have been committed for this exploration (via `accept_discovery_questions_batch`, or `accept_discovery_questions`). There is no skip-discovery exception.
 - Silently auto-picking all generated questions and proceeding to Step 8 — observed in agent output 2026-05-15 as "the engineering-mode default is to run, which skips the per-question picker." There is no such default; the picker is mandatory.
 - **Offering "or I'll default to taking all of them" (or any accept-all fallback), then committing the full set on an ambiguous reply** — observed 2026-06-05 (a `proceed` at this gate → `accept_discovery_questions_batch` with all 68 questions → a ~25-min run the user never chose). Accept-all is a legitimate choice **only when the user explicitly asks for it** — it is NEVER the default you offer, and NEVER the fallback. The default you offer + fall back to is always **the suggested 12 rendered on the landing**. An ambiguous reply (`proceed`/`go`/`ok`) at the pick gate means **accept those 12**, not the full set — structurally safe because the 12 are on screen in full.
-- Rendering "Next: run discovery through recommendations / Reply `run` to continue" anywhere in the chat before Step 7.4 has completed.
+- Starting Step 8 — auto-firing the answers (engineering) or rendering the product/design run-mode choice — anywhere in the chat before Step 7.4 has committed the picks.
 
 The picker is **not** a UI suggestion — it's the load-bearing decision gate where the user expresses what to investigate. Skipping it converts the agentic run into an automated "answer everything" pass and erases the user's judgment.
 
@@ -1687,28 +1688,24 @@ it's `/ritual build`.**
 
 Pick the path honestly; don't claim to answer from code you didn't read.
 
-<!-- skill-options:no-gate-change: Step 8 answerer is chosen by real repo-linkage (recon ran / code open), not by the /ritual build invocation; agent-answers when repo-linked, server-run fallback. Includes prose guidance on answer length (~300-600 words), that attached code is OPTIONAL illustrative reference (not part of the answer, not a verbatim copy), and a hard no-secrets/no-PII redaction rule for the BYO answerer. The run/pause gate + its options are unchanged — no new pause gate or Step header. -->
+<!-- skill-options:no-gate-change: Step 8 answerer is chosen by real repo-linkage (recon ran / code open), not by the /ritual build invocation; agent-answers when repo-linked, server-run fallback. Includes prose guidance on answer length (~300-600 words), that attached code is OPTIONAL illustrative reference (not part of the answer, not a verbatim copy), and a hard no-secrets/no-PII redaction rule for the BYO answerer. As of 2026-06-21 the engineering/delivery/operations run gate is REMOVED (auto-proceed after the §7.4 commit) — the options-contract drops that gate; no new pause gate or Step header is added. -->
 
-For `engineering`, `delivery`, and `operations` roles, show:
+For `engineering`, `delivery`, and `operations` roles there is **no run confirmation**: the user already chose "generate answers and recommendations" when they proceeded from the discovery pick gate (§ 7.3.1), so a second "ready to run?" prompt is redundant friction. **Auto-proceed with no `run`/`pause` CTA and no wait for a reply.**
+
+<!-- skill-options:no-gate-change: prose only — adds a strict accept-returns-before-run ordering precondition to Step 8 (and the §7-transition rule); no decision gate, offered option, or Step header is added, removed, or changed. -->
+**Strict ordering (load-bearing — do NOT skip, reorder, or parallelize):** the run begins **only after the Step 7.4 `accept_discovery_questions_batch` call has RETURNED its response**. That accept is what commits the picks and returns `materialized[]` (the committed question rows + their `id`s); you answer those exact ids. Do NOT call `write_answer_context`, `submit_all_answers`, or `start_agentic_run` before the accept resolves, and never fire them in parallel with it — there is no committed question set to run against until the accept returns. Removing the old `run` gate removed a human turn, NOT this dependency: await the accept, read `materialized[]`, then run. Once you have the accept response, print one non-blocking status line so the hand-off isn't silent, then begin:
 
 ```text
 Ritual build
 ✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Run discovery
-
-I'll answer the picked questions from the codebase, then generate
-recommendations. This usually takes a few minutes.
-
-Reply `run` to answer → generate recommendations.
-Reply `pause` to stop here.
+Answering your picked questions, then generating recommendations.
+This usually takes a few minutes — I'll keep working; nothing needed from you.
 ```
 
-(Match the first line to the path you'll actually take: repo-linked → "I'll answer the picked questions from the codebase…"; fallback → "Ritual will source answers for the picked questions…". Don't claim to answer from code if you're taking the server path.)
-
-Visible CTA is `run`. Accept `r`, `go`, `continue`, or `next` as aliases. Per `references/cli-output-contract.md` § Surface-aware continuation prompts, do NOT treat empty input as proceed inside agent chat.
+(Match the line to the path you'll actually take: repo-linked → "Answering your picked questions from the codebase…"; fallback → "Ritual is sourcing answers for the picked questions…". Don't claim to answer from code if you're taking the server path.)
 
-On `run`, **if you're genuinely repo-linked (per the check above), answer the questions yourself** (BYO-answerer; do NOT call `start_agentic_run`):
+**If you're genuinely repo-linked (per the check above), answer the questions yourself** (BYO-answerer; do NOT call `start_agentic_run`):
 1. The Step 7.4 accept (`accept_discovery_questions_batch`) returned `materialized[]` — the committed questions with their row `id`s. (If you didn't keep them, the same ids are what you passed to accept.)
 2. For each saved question, call `mcp__ritual__write_answer_context(question_id, content)` with an answer grounded in your reading of the codebase — the files you read at Step 5.7, the actual code, real constraints. Answer in PARALLEL where your agent supports it (e.g. one subagent per Area). The content is provisional + provenance-tagged agentic until saved; only the final saved set drives recommendations.
    - **Length:** keep each answer to **~300–600 words by default** — tight and grounded, not an essay. Go longer only when the question genuinely needs it.
@@ -1716,7 +1713,7 @@ On `run`, **if you're genuinely repo-linked (per the check above), answer the qu
    - **Never leak secrets or sensitive data.** A snippet is **illustrative, not a verbatim copy** — it only has to convey the shape/idea, so simplify and elide freely. **NEVER** include API keys, tokens, passwords, connection strings, credentials, `.env` values, real customer data, or PII — even if they're literally in the file you read. Replace them with obvious placeholders (`process.env.X`, `"<api-key>"`, `"user@example.com"`). The same goes for the prose: describe constraints without pasting secret values.
 3. When every committed question has answer context, call `mcp__ritual__submit_all_answers(exploration_id)` — it commits the set and triggers recommendation generation. Then go to the recommendation wait (Step 8.1, agent-answered path).
 
-**Fallback — server answers (no repo / nothing to ground in):** call `mcp__ritual__start_agentic_run` with `scope_type: 'exploration'` + `exploration_id`, then follow the server polling path (8.0 → 8.1).
+**Fallback — server answers (no repo / nothing to ground in):** only after the Step 7.4 accept has returned (the run needs the committed question set it produced), call `mcp__ritual__start_agentic_run` with `scope_type: 'exploration'` + `exploration_id`, then follow the server polling path (8.0 → 8.1).
 
 For `product`, `design`, or explicitly PRD-style flows where answer review is useful, offer two choices without time estimates (this path uses the SERVER answer engine so the user can review each generated answer — Step 8.5):
 

package/skills/cursor/ritual/.ritual-bundle.json

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.38",
-  "builtAt": "2026-06-20T13:35:23.818Z",
-  "skillsHash": "ca720305a0e1"
+  "cliVersion": "0.36.42",
+  "builtAt": "2026-06-21T23:52:03.528Z",
+  "skillsHash": "020ff37f037f"
 }

package/skills/cursor/ritual/SKILL.md

@@ -3,8 +3,8 @@ name: ritual
 description: "Use when an engineer wants a coding agent to plan or build a feature, refactor, or implementation-heavy change that depends on context the agent can't infer on its own — strategic intent, constraints, prior decisions, and trade-offs that live in the user's head. Ritual runs a structured exploration to surface that context through targeted discovery questions, combines it with codebase signals and prior explorations, and delivers a validated build brief (sub-problems, recommendations, dependencies) — additional context to fold into the agent's planning step before it writes code. Prefer this over jumping straight to implementation when the problem is ambiguous, cross-cutting, or has non-obvious constraints. Subcommands: build (full planning-to-sync cycle — default for new features), resume (continue an in-flight exploration), lineage (file-path KG history — what decisions shaped this code), context-pulse (readiness and context-debt scoring — is this safe to build yet?)."
 argument-hint: "[subcommand] <args>  (e.g. 'build Reduce T2 churn in Q3', 'resume', 'lineage src/checkout/views.py', 'context-pulse Add billing export')"
 user-invocable: true
-stamp: ca720305a0e1
-cli_version: 0.36.38
+stamp: 020ff37f037f
+cli_version: 0.36.42
 ---
 
 # /ritual

package/skills/cursor/ritual/references/build-flow.md

@@ -327,7 +327,8 @@ Store `workspace_id` for the rest of the flow.
 
 If you created a new workspace, persist the binding to `.ritual/config.json` so future runs in this repo skip the workspace-selection prompt. Write it yourself if you have filesystem write access; otherwise show the user the JSON and have them save it.
 
-**`.ritual/config.json` is committed to the repo — it is shared, not per-user.** Same model as `.eslintrc.json` or `tsconfig.json`: it binds this codebase to a Ritual workspace + pins team-level defaults (`workspaceId`, `personaSlug` — set by `ritual init`'s FTUE — or the legacy `defaultTemplateId`). Everyone working on this repo wants the same values. Per-user state (PATs, auth tokens) lives in `~/.config/ritual/` and never in this file.
+<!-- skill-options:no-gate-change: prose only — corrected the .ritual/config.json description and dropped mentions of the removed `--persona` flag; no decision gate or offered options changed -->
+**`.ritual/config.json` is committed to the repo — it is shared, not per-user.** Same model as `.eslintrc.json` or `tsconfig.json`: it binds this codebase to a Ritual workspace (`workspaceId` / `workspaceName`) so everyone working on this repo resolves the same place. It holds ONLY repo-level facts — write nothing per-user into it. Persona and template defaults are user-scoped (your Ritual account's `user.persona`, set during `ritual init`), NOT stored here; PATs and auth tokens live in `~/.config/ritual/` and never in this file.
 
 When you write the config, also write `.ritual/.gitignore` if it doesn't already exist so any future per-user state files in this directory get ignored while `config.json` itself stays tracked:
 
@@ -620,12 +621,12 @@ Steps:
 <!-- skill-options:no-gate-change: f.1 is an OPTIONAL skippable sub-prompt nested in Step 1.5 step 6 (default skip); adds no tracked pause gate or Step header, so the structural fingerprint is unchanged (check-skill-options-contract green). -->
    f.1 **Unchosen-candidates gate (2026-06-14, unchosen-options → discovery worktrees).** The candidates the user did NOT pick are paths worth not silently dropping. Render ONE compact, SKIPPABLE prompt — for each unchosen candidate, the user can spin up **discovery now** (a background worktree reasons it to a build brief) or **log it as a future job**. Promote DELIBERATELY: the default is to drop. (This gate is itself skipped in autonomous/worktree mode — never spawn discovery recursively.)
 
+      <!-- skill-options:no-gate-change: prose-only copy tightening of the discover/next-job/skip descriptions; option tokens + gate unchanged -->
       ```text
-      You picked #{k}. The other {M} — want to keep any going?
-        • `discover <nums>`  — spin up discovery NOW in a background git worktree: an agent reasons it
-                               end-to-end to a build brief (reasoning only, no code). e.g. `discover 1`
-        • `next-job <nums>`  — just log it as a future job (a draft exploration in this workspace; nothing runs)
-        • `skip`             — drop them (default)
+      You picked #{k}. For the rest:
+        • `discover <nums>`  — explore unpicked option(s) in parallel; returns a build brief, no code.
+        • `next-job <nums>`  — save as future work.
+        • `skip`             — drop them. Default.
       ```
 
       Resolve the reply, then continue to Step 2 for the picked candidate:
@@ -700,7 +701,7 @@ Steps:
 
 #### Step 2 — Template selection (server-side, silent)
 
-> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy — the FTUE picker is gone; set only via `ritual init --persona`) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
+> **Rewritten 2026-05-21 (CLI 0.9.0+), chain updated 2026-06-11 (JTBD-first entry).** Previously this section had three branches (persona-pinned / legacy-pinned / list-and-pick) that the SKILL had to navigate, and could optionally call `mcp__ritual__list_templates`. That tool is gone from the agent-facing MCP surface as of CLI 0.9.0. Template selection is now entirely server-side: when `create_exploration` is called without an explicit `template_id`, the server resolves the right SYSTEM template from the exploration's `jtbd` (the job confirmed at the Step 0.7 Job gate) → `workspace.defaultTemplateId` (team override) → `user.persona` (legacy fallback — no longer set during onboarding; not CLI-settable) → a designated generic fallback → system default, then forks it into a per-exploration Template atomically inside the same `create_exploration` request.
 
 **For the agent: there is no template-selection step. Skip this Step entirely and go to Step 3.** Don't read `.ritual/config.json` for persona, don't try to call `list_templates` (it's not registered), don't render a "Using persona X" confirmation.
 
@@ -731,7 +732,7 @@ All atomic in one HTTP request. See `apps/api/src/modules/explorations/explorati
 
 Recognized roles (use the role keyword the API returns, not a paraphrase): `engineering`, `product`, `design`, `marketing`, `delivery`, `operations`.
 
-If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now; `ritual init --persona <slug>` only changes the legacy personal default).
+If the user corrects the role mid-flow ("actually I'm building a PRD"), update internal role tracking. **Do not** re-pick the template — that requires re-creating the exploration, which is bigger than a mid-flow correction warrants. If the user genuinely wants a different template for this exploration, ask them to start over with `/ritual build` and correct the job at the Job gate (the jtbd drives the template now).
 
 Proceed to Step 3.
 
@@ -1317,14 +1318,14 @@ Then summarize the created siblings in the dense-list format. Do not pause after
 
 Longest phase because generation is async + the user picks per-Area. (Internally the API field is `matter_id`; user-facing copy always says Area.)
 
-**Step 6 → Step 7 transition anti-pattern (load-bearing):** after `create_exploration` succeeds in Step 6, you MUST NOT render Step 8's *"Reply `run` to continue"* CTA. Required next actions, in order, before Step 8 is allowed:
+**Step 6 → Step 7 transition anti-pattern (load-bearing):** after `create_exploration` succeeds in Step 6, you MUST NOT jump to Step 8's answering/run — discovery questions must be generated, picked, and committed first. Required next actions, in order, before Step 8 is allowed:
 
 1. Call `mcp__ritual__suggest_discovery_questions(exploration_id)` (Step 7.1) — no user input needed; just kick it off.
 2. Poll `mcp__ritual__get_discovery_state(exploration_id)` until `ready: true` (Step 7.2).
 3. Render the **Area rail + Area 1's questions together** and walk Area-by-Area per § 7.3.1 (the rail orients; a rail with NO questions under it — a bare index — is the failure mode).
 4. `[USER PAUSE]` — the suggested-12 landing (§ 7.3.1): the user replies `proceed` (commit the 12), `expert` (walk + adjust; floor 6 to run, aim 15–20, no cap), or `pause`.
 5. Commit all picked Areas in ONE `mcp__ritual__accept_discovery_questions_batch` call (Step 7.4) — never one parallel call per Area.
-6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 and render the *"Reply `run` to continue"* CTA.
+6. Optionally capture anti-goals (Step 7.5), then proceed to Step 8 — but only **after the Step 7.4 `accept_discovery_questions_batch` response returns** (you need its `materialized[]` question ids to run against). For engineering/delivery/operations, then **auto-fire the run** (answer the picked questions + `submit_all_answers`, or the server fallback) — no `run` CTA, no pause. For product/design/PRD flows, render the `1`/`2` run-mode choice (stop-after-answers review vs run-through). Never start answering/running before the accept resolves.
 
 **Picking is a deliberate step-through, not a bulk action (load-bearing):** the user going Area by Area and choosing the questions that matter IS the value of discovery — that per-question judgment shapes the whole downstream chain. So **nudge the user to step through and pick**; don't lead with bulk shortcuts.
 - **Nudge to step through.** Walk the user Area-by-Area (drop into Area 1, `next`/`prev`) and invite deliberate picks per Area, with `show more` to expand an Area. The framing is "which of these should we dig into?", not "want all of them?".
@@ -1337,7 +1338,7 @@ Longest phase because generation is async + the user picks per-Area. (Internally
 - Calling `start_agentic_run` before at least 6 discovery picks have been committed for this exploration (via `accept_discovery_questions_batch`, or `accept_discovery_questions`). There is no skip-discovery exception.
 - Silently auto-picking all generated questions and proceeding to Step 8 — observed in agent output 2026-05-15 as "the engineering-mode default is to run, which skips the per-question picker." There is no such default; the picker is mandatory.
 - **Offering "or I'll default to taking all of them" (or any accept-all fallback), then committing the full set on an ambiguous reply** — observed 2026-06-05 (a `proceed` at this gate → `accept_discovery_questions_batch` with all 68 questions → a ~25-min run the user never chose). Accept-all is a legitimate choice **only when the user explicitly asks for it** — it is NEVER the default you offer, and NEVER the fallback. The default you offer + fall back to is always **the suggested 12 rendered on the landing**. An ambiguous reply (`proceed`/`go`/`ok`) at the pick gate means **accept those 12**, not the full set — structurally safe because the 12 are on screen in full.
-- Rendering "Next: run discovery through recommendations / Reply `run` to continue" anywhere in the chat before Step 7.4 has completed.
+- Starting Step 8 — auto-firing the answers (engineering) or rendering the product/design run-mode choice — anywhere in the chat before Step 7.4 has committed the picks.
 
 The picker is **not** a UI suggestion — it's the load-bearing decision gate where the user expresses what to investigate. Skipping it converts the agentic run into an automated "answer everything" pass and erases the user's judgment.
 
@@ -1623,28 +1624,24 @@ it's `/ritual build`.**
 
 Pick the path honestly; don't claim to answer from code you didn't read.
 
-<!-- skill-options:no-gate-change: Step 8 answerer is chosen by real repo-linkage (recon ran / code open), not by the /ritual build invocation; agent-answers when repo-linked, server-run fallback. Includes prose guidance on answer length (~300-600 words), that attached code is OPTIONAL illustrative reference (not part of the answer, not a verbatim copy), and a hard no-secrets/no-PII redaction rule for the BYO answerer. The run/pause gate + its options are unchanged — no new pause gate or Step header. -->
+<!-- skill-options:no-gate-change: Step 8 answerer is chosen by real repo-linkage (recon ran / code open), not by the /ritual build invocation; agent-answers when repo-linked, server-run fallback. Includes prose guidance on answer length (~300-600 words), that attached code is OPTIONAL illustrative reference (not part of the answer, not a verbatim copy), and a hard no-secrets/no-PII redaction rule for the BYO answerer. As of 2026-06-21 the engineering/delivery/operations run gate is REMOVED (auto-proceed after the §7.4 commit) — the options-contract drops that gate; no new pause gate or Step header is added. -->
 
-For `engineering`, `delivery`, and `operations` roles, show:
+For `engineering`, `delivery`, and `operations` roles there is **no run confirmation**: the user already chose "generate answers and recommendations" when they proceeded from the discovery pick gate (§ 7.3.1), so a second "ready to run?" prompt is redundant friction. **Auto-proceed with no `run`/`pause` CTA and no wait for a reply.**
+
+<!-- skill-options:no-gate-change: prose only — adds a strict accept-returns-before-run ordering precondition to Step 8 (and the §7-transition rule); no decision gate, offered option, or Step header is added, removed, or changed. -->
+**Strict ordering (load-bearing — do NOT skip, reorder, or parallelize):** the run begins **only after the Step 7.4 `accept_discovery_questions_batch` call has RETURNED its response**. That accept is what commits the picks and returns `materialized[]` (the committed question rows + their `id`s); you answer those exact ids. Do NOT call `write_answer_context`, `submit_all_answers`, or `start_agentic_run` before the accept resolves, and never fire them in parallel with it — there is no committed question set to run against until the accept returns. Removing the old `run` gate removed a human turn, NOT this dependency: await the accept, read `materialized[]`, then run. Once you have the accept response, print one non-blocking status line so the hand-off isn't silent, then begin:
 
 ```text
 Ritual build
 ✓ Job  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Run discovery
-
-I'll answer the picked questions from the codebase, then generate
-recommendations. This usually takes a few minutes.
-
-Reply `run` to answer → generate recommendations.
-Reply `pause` to stop here.
+Answering your picked questions, then generating recommendations.
+This usually takes a few minutes — I'll keep working; nothing needed from you.
 ```
 
-(Match the first line to the path you'll actually take: repo-linked → "I'll answer the picked questions from the codebase…"; fallback → "Ritual will source answers for the picked questions…". Don't claim to answer from code if you're taking the server path.)
-
-Visible CTA is `run`. Accept `r`, `go`, `continue`, or `next` as aliases. Per `references/cli-output-contract.md` § Surface-aware continuation prompts, do NOT treat empty input as proceed inside agent chat.
+(Match the line to the path you'll actually take: repo-linked → "Answering your picked questions from the codebase…"; fallback → "Ritual is sourcing answers for the picked questions…". Don't claim to answer from code if you're taking the server path.)
 
-On `run`, **if you're genuinely repo-linked (per the check above), answer the questions yourself** (BYO-answerer; do NOT call `start_agentic_run`):
+**If you're genuinely repo-linked (per the check above), answer the questions yourself** (BYO-answerer; do NOT call `start_agentic_run`):
 1. The Step 7.4 accept (`accept_discovery_questions_batch`) returned `materialized[]` — the committed questions with their row `id`s. (If you didn't keep them, the same ids are what you passed to accept.)
 2. For each saved question, call `mcp__ritual__write_answer_context(question_id, content)` with an answer grounded in your reading of the codebase — the files you read at Step 5.7, the actual code, real constraints. Answer in PARALLEL where your agent supports it (e.g. one subagent per Area). The content is provisional + provenance-tagged agentic until saved; only the final saved set drives recommendations.
    - **Length:** keep each answer to **~300–600 words by default** — tight and grounded, not an essay. Go longer only when the question genuinely needs it.
@@ -1652,7 +1649,7 @@ On `run`, **if you're genuinely repo-linked (per the check above), answer the qu
    - **Never leak secrets or sensitive data.** A snippet is **illustrative, not a verbatim copy** — it only has to convey the shape/idea, so simplify and elide freely. **NEVER** include API keys, tokens, passwords, connection strings, credentials, `.env` values, real customer data, or PII — even if they're literally in the file you read. Replace them with obvious placeholders (`process.env.X`, `"<api-key>"`, `"user@example.com"`). The same goes for the prose: describe constraints without pasting secret values.
 3. When every committed question has answer context, call `mcp__ritual__submit_all_answers(exploration_id)` — it commits the set and triggers recommendation generation. Then go to the recommendation wait (Step 8.1, agent-answered path).
 
-**Fallback — server answers (no repo / nothing to ground in):** call `mcp__ritual__start_agentic_run` with `scope_type: 'exploration'` + `exploration_id`, then follow the server polling path (8.0 → 8.1).
+**Fallback — server answers (no repo / nothing to ground in):** only after the Step 7.4 accept has returned (the run needs the committed question set it produced), call `mcp__ritual__start_agentic_run` with `scope_type: 'exploration'` + `exploration_id`, then follow the server polling path (8.0 → 8.1).
 
 For `product`, `design`, or explicitly PRD-style flows where answer review is useful, offer two choices without time estimates (this path uses the SERVER answer engine so the user can review each generated answer — Step 8.5):
 

package/skills/cursor/ritual/references/cli-output-contract.md

@@ -456,13 +456,11 @@ Visible CTA is `use`. Accept `lock`, `l`, `go`, `continue`, or `next` as backwar
 
 ### Engineering run mode
 
-For engineering / agentic-coding templates, do not offer answers-only review and do not mention time estimates. Use:
+For engineering / agentic-coding templates there is **no run CTA and no pause** — once the discovery picks are committed, auto-fire the run (answer the questions then `submit_all_answers`, or the server fallback) and proceed straight to recommendations. Do not offer answers-only review and do not ask the user to start the run. Print one non-blocking status line instead of a prompt:
 
 ```text
-Next: run discovery through recommendations.
-
-Reply `run` to continue.
-Reply `pause` to stop here.
+Answering your picked questions, then generating recommendations.
+This usually takes a few minutes — I'll keep working; nothing needed from you.
 ```
 
 ### Shipped work visibility