@ritualai/cli 0.36.8 → 0.36.11

package/skills/cursor/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: d91bf82d5264e811 -->
+<!-- source-sha: bc6ea52efd75e1c7 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -151,6 +151,7 @@ If the user types `always audit for this build` mid-flow at the Step 9.6 prompt,
 Persist `auditMode` to `Exploration.metadata.auditMode` at `create_exploration` time (additive JSONB key — no schema migration) so `/ritual resume <exploration-id>` picks up the same mode the original build started with, and `/ritual lineage <exploration-id>` can render which gates ran + their outcomes.
 
 
+<!-- skill-options:no-gate-change: 2b (clarifying question) + 2c (generic terminal) are loud-fallback COPY variants of the same gate; options are unchanged (proceed | name-the-job) -->
 #### Step 0.7 — The Job gate: classify the job to be done
 
 **The FIRST tool call of a fresh build.** The server — not you — classifies the user's raw ask into
@@ -166,9 +167,16 @@ When this gate runs:
 
 1. **Call `mcp__ritual__classify_work_item`** with `raw_input` = the user's ask, verbatim. Do NOT
    classify yourself, do NOT pre-filter to development jobs. It returns
-   `{ jtbd, workItemLabel, deliverableTemplate, why, personaCoverage }`.
+   `{ jtbd, workItemLabel, deliverableTemplate, why, confidence, isGenericFallback, personaCoverage }`.
+   `isGenericFallback` (and `confidence`) are the typed-uncertainty signal: when it's `true`, the
+   result is the catch-all (`build-feature` / `produce-deliverable`) or the classifier wasn't sure —
+   it is NOT a confident match, and which render variant you use in step 2 depends on it.
 
-2. **Render the validation prompt** (rail stage `Job`):
+2. **Render the validation prompt** (rail stage `Job`). This gate is a plain-language VALIDATION of
+   what you're about to build: restate the ask + the matched job in the user's words, then let them
+   confirm or correct. Which variant you render depends on `isGenericFallback`.
+
+   **2a — Confident match** (`isGenericFallback` is `false`): the classifier matched a specific job.
 
    ```text
    Ritual build
@@ -182,21 +190,68 @@ When this gate runs:
    job actually is.
    ```
 
+   **2b — No specific job matched, FIRST time** (`isGenericFallback` is `true` — the result is the
+   catch-all `build-feature` / `produce-deliverable`, or `confidence` is `low` — AND you have not yet
+   asked the clarifying question this gate): do NOT present the catch-all as a verdict. This case
+   should be RARE. Instead ask ONE clarifying question that elicits the missing signal — what KIND of
+   work this is — grounded in their ask, with concrete examples that lead the reply. The examples
+   span the catalog's functions so the user can self-identify; tailor the wording to their ask. This
+   is the fallback step that lets us classify properly instead of defaulting blind (see
+   `loud-fallback-escalation.md`).
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+
+   I couldn't pin this to a specific job — your ask reads as an outcome, and the flow scopes much
+   better when I know what KIND of work it is. Which is closest (or say it in your own words)?
+     • A coding-agent / MCP / skill capability — tooling the agent itself uses
+     • A backend service or API
+     • A frontend / UI feature
+     • A refactor, migration, or infra / platform change
+     • Something else — tell me in a sentence
+
+   Reply with the closest fit (or your own words) and I'll lock the job.
+   ```
+
+   When the user answers, call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input` plus
+   `correction` = their reply (and `previous_jtbd`), then re-render: **2a** if it now matched a
+   specific job, otherwise **2c**.
+
+   **2c — Still generic after the clarifying question** (`isGenericFallback` is STILL `true` after the
+   user answered 2b): do NOT ask again. Proceed as a generic build with the function-agnostic
+   `Feature Brief` deliverable, and note the job can be renamed later. The job name stays generic —
+   never show a function-specific deliverable (e.g. "Frontend Web") for an unclassified build.
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+   I'll treat this as a generic build — deliverable: Feature Brief. You can rename the job later.
+
+   Reply `proceed` to frame the problem.
+   ```
+
    Do not render `personaCoverage` — persona representation is handled server-side now; only surface
    it if the user explicitly asks who's involved.
 
    Rail naming (deliverable-named rail, 2026-06-11): render `{Deliverable}` as the PROPOSED job's
-   `deliverableTemplate` (e.g. `Launch Brief`, `PRD`, `Service Build Brief`; `Build brief` for the
-   generic `build-feature`), and OMIT the `Implementation (Your agent)` stage entirely when the
-   proposed job is not a development job — non-dev rails have FIVE stages ending at the deliverable.
-   A correction that changes the job updates the rail on the next render. Spec:
+   `deliverableTemplate` from the classify result (e.g. `Launch Brief`, `PRD`, `Service Build Brief`;
+   `Feature Brief` for the generic `build-feature`), and OMIT the `Implementation (Your agent)` stage
+   entirely when the proposed job is not a development job — non-dev rails have FIVE stages ending at
+   the deliverable. A correction that changes the job updates the rail on the next render. Spec:
    `references/cli-output-contract.md` § Canonical stage table.
 
 3. **[USER PAUSE]** — wait for the user's actual reply. Never infer confirmation from the original
    ask, auto-mode, or silence. `proceed` / `yes` / `ok` confirms. ANY other substantive reply is a
    correction: call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input`, plus
    `correction` (the user's words) and `previous_jtbd` (the rejected slug), then re-render step 2.
-   Loop until the user proceeds.
+   The clarifying QUESTION (2b) is asked AT MOST ONCE per gate — if the re-classification after the
+   user's answer is still generic, render **2c** (proceed as a generic `Feature Brief`); do not ask
+   the clarifying question again. Loop until the user proceeds.
 
 4. **Remember the confirmed `jtbd`** — you pass it to `create_exploration` at Step 6. Only after the
    user proceeds does the flow enter the `Scope` stage (workspace pick onward).

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.8",
-  "builtAt": "2026-06-12T04:36:24.525Z",
-  "skillsHash": "49c0dd37dafd"
+  "cliVersion": "0.36.11",
+  "builtAt": "2026-06-14T18:50:01.090Z",
+  "skillsHash": "39dbaf6dbdf9"
 }

package/skills/gemini/ritual/SKILL.md

@@ -3,7 +3,7 @@ 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 plan mode before the agent writes code. Prefer this over jumping straight to implementation or plan mode 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: 49c0dd37dafd
+stamp: 39dbaf6dbdf9
 ---
 
 # /ritual
@@ -20,6 +20,9 @@ Before executing any subcommand, read and follow:
 
 Do not reintroduce `/ritual recon`. Use plain-language repo inspection, `/ritual resume`, or `/ritual lineage` depending on intent.
 
+**Ground before you claim (load-bearing).** An exploration's current state — its recommendation count/status, step, requirement/brief status — is **live truth you read, never recall**. Before stating any of it: if unsure *which* exploration, call `list_explorations` (the compact roster) to fix identity by seeing them side by side; before asserting *what's in* one, call `get_exploration_status` (the cheap status card). Memory and prior turns are authoritative only for identity (which exploration, its title); the graph is authoritative for state. Never assert a recommendation count or status from memory, a session summary, or a stale read — that's how sibling explorations get conflated and "0 recs" gets claimed on an exploration that has many. See `documents/architecture/okf-grounding-policy.md`.
+<!-- skill-options:no-gate-change: grounding rule adds no [USER PAUSE] gate or options; read-before-claim discipline only -->
+
 **Skill freshness (once per session, silent unless stale):** this file's frontmatter may carry a
 `stamp:` value (injected when the bundle was built — absent on dev/source copies). On the FIRST
 `mcp__ritual__ping` of a session, pass it as `skill_stamp`. If the response says

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

@@ -107,6 +107,7 @@ If the user types `always audit for this build` mid-flow at the Step 9.6 prompt,
 Persist `auditMode` to `Exploration.metadata.auditMode` at `create_exploration` time (additive JSONB key — no schema migration) so `/ritual resume <exploration-id>` picks up the same mode the original build started with, and `/ritual lineage <exploration-id>` can render which gates ran + their outcomes.
 
 <!-- lite:keep-start -->
+<!-- skill-options:no-gate-change: 2b (clarifying question) + 2c (generic terminal) are loud-fallback COPY variants of the same gate; options are unchanged (proceed | name-the-job) -->
 #### Step 0.7 — The Job gate: classify the job to be done
 
 **The FIRST tool call of a fresh build.** The server — not you — classifies the user's raw ask into
@@ -122,9 +123,16 @@ When this gate runs:
 
 1. **Call `mcp__ritual__classify_work_item`** with `raw_input` = the user's ask, verbatim. Do NOT
    classify yourself, do NOT pre-filter to development jobs. It returns
-   `{ jtbd, workItemLabel, deliverableTemplate, why, personaCoverage }`.
+   `{ jtbd, workItemLabel, deliverableTemplate, why, confidence, isGenericFallback, personaCoverage }`.
+   `isGenericFallback` (and `confidence`) are the typed-uncertainty signal: when it's `true`, the
+   result is the catch-all (`build-feature` / `produce-deliverable`) or the classifier wasn't sure —
+   it is NOT a confident match, and which render variant you use in step 2 depends on it.
 
-2. **Render the validation prompt** (rail stage `Job`):
+2. **Render the validation prompt** (rail stage `Job`). This gate is a plain-language VALIDATION of
+   what you're about to build: restate the ask + the matched job in the user's words, then let them
+   confirm or correct. Which variant you render depends on `isGenericFallback`.
+
+   **2a — Confident match** (`isGenericFallback` is `false`): the classifier matched a specific job.
 
    ```text
    Ritual build
@@ -138,21 +146,68 @@ When this gate runs:
    job actually is.
    ```
 
+   **2b — No specific job matched, FIRST time** (`isGenericFallback` is `true` — the result is the
+   catch-all `build-feature` / `produce-deliverable`, or `confidence` is `low` — AND you have not yet
+   asked the clarifying question this gate): do NOT present the catch-all as a verdict. This case
+   should be RARE. Instead ask ONE clarifying question that elicits the missing signal — what KIND of
+   work this is — grounded in their ask, with concrete examples that lead the reply. The examples
+   span the catalog's functions so the user can self-identify; tailor the wording to their ask. This
+   is the fallback step that lets us classify properly instead of defaulting blind (see
+   `loud-fallback-escalation.md`).
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+
+   I couldn't pin this to a specific job — your ask reads as an outcome, and the flow scopes much
+   better when I know what KIND of work it is. Which is closest (or say it in your own words)?
+     • A coding-agent / MCP / skill capability — tooling the agent itself uses
+     • A backend service or API
+     • A frontend / UI feature
+     • A refactor, migration, or infra / platform change
+     • Something else — tell me in a sentence
+
+   Reply with the closest fit (or your own words) and I'll lock the job.
+   ```
+
+   When the user answers, call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input` plus
+   `correction` = their reply (and `previous_jtbd`), then re-render: **2a** if it now matched a
+   specific job, otherwise **2c**.
+
+   **2c — Still generic after the clarifying question** (`isGenericFallback` is STILL `true` after the
+   user answered 2b): do NOT ask again. Proceed as a generic build with the function-agnostic
+   `Feature Brief` deliverable, and note the job can be renamed later. The job name stays generic —
+   never show a function-specific deliverable (e.g. "Frontend Web") for an unclassified build.
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+   I'll treat this as a generic build — deliverable: Feature Brief. You can rename the job later.
+
+   Reply `proceed` to frame the problem.
+   ```
+
    Do not render `personaCoverage` — persona representation is handled server-side now; only surface
    it if the user explicitly asks who's involved.
 
    Rail naming (deliverable-named rail, 2026-06-11): render `{Deliverable}` as the PROPOSED job's
-   `deliverableTemplate` (e.g. `Launch Brief`, `PRD`, `Service Build Brief`; `Build brief` for the
-   generic `build-feature`), and OMIT the `Implementation (Your agent)` stage entirely when the
-   proposed job is not a development job — non-dev rails have FIVE stages ending at the deliverable.
-   A correction that changes the job updates the rail on the next render. Spec:
+   `deliverableTemplate` from the classify result (e.g. `Launch Brief`, `PRD`, `Service Build Brief`;
+   `Feature Brief` for the generic `build-feature`), and OMIT the `Implementation (Your agent)` stage
+   entirely when the proposed job is not a development job — non-dev rails have FIVE stages ending at
+   the deliverable. A correction that changes the job updates the rail on the next render. Spec:
    `references/cli-output-contract.md` § Canonical stage table.
 
 3. **[USER PAUSE]** — wait for the user's actual reply. Never infer confirmation from the original
    ask, auto-mode, or silence. `proceed` / `yes` / `ok` confirms. ANY other substantive reply is a
    correction: call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input`, plus
    `correction` (the user's words) and `previous_jtbd` (the rejected slug), then re-render step 2.
-   Loop until the user proceeds.
+   The clarifying QUESTION (2b) is asked AT MOST ONCE per gate — if the re-classification after the
+   user's answer is still generic, render **2c** (proceed as a generic `Feature Brief`); do not ask
+   the clarifying question again. Loop until the user proceeds.
 
 4. **Remember the confirmed `jtbd`** — you pass it to `create_exploration` at Step 6. Only after the
    user proceeds does the flow enter the `Scope` stage (workspace pick onward).

package/skills/gemini/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: d91bf82d5264e811 -->
+<!-- source-sha: bc6ea52efd75e1c7 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -151,6 +151,7 @@ If the user types `always audit for this build` mid-flow at the Step 9.6 prompt,
 Persist `auditMode` to `Exploration.metadata.auditMode` at `create_exploration` time (additive JSONB key — no schema migration) so `/ritual resume <exploration-id>` picks up the same mode the original build started with, and `/ritual lineage <exploration-id>` can render which gates ran + their outcomes.
 
 
+<!-- skill-options:no-gate-change: 2b (clarifying question) + 2c (generic terminal) are loud-fallback COPY variants of the same gate; options are unchanged (proceed | name-the-job) -->
 #### Step 0.7 — The Job gate: classify the job to be done
 
 **The FIRST tool call of a fresh build.** The server — not you — classifies the user's raw ask into
@@ -166,9 +167,16 @@ When this gate runs:
 
 1. **Call `mcp__ritual__classify_work_item`** with `raw_input` = the user's ask, verbatim. Do NOT
    classify yourself, do NOT pre-filter to development jobs. It returns
-   `{ jtbd, workItemLabel, deliverableTemplate, why, personaCoverage }`.
+   `{ jtbd, workItemLabel, deliverableTemplate, why, confidence, isGenericFallback, personaCoverage }`.
+   `isGenericFallback` (and `confidence`) are the typed-uncertainty signal: when it's `true`, the
+   result is the catch-all (`build-feature` / `produce-deliverable`) or the classifier wasn't sure —
+   it is NOT a confident match, and which render variant you use in step 2 depends on it.
 
-2. **Render the validation prompt** (rail stage `Job`):
+2. **Render the validation prompt** (rail stage `Job`). This gate is a plain-language VALIDATION of
+   what you're about to build: restate the ask + the matched job in the user's words, then let them
+   confirm or correct. Which variant you render depends on `isGenericFallback`.
+
+   **2a — Confident match** (`isGenericFallback` is `false`): the classifier matched a specific job.
 
    ```text
    Ritual build
@@ -182,21 +190,68 @@ When this gate runs:
    job actually is.
    ```
 
+   **2b — No specific job matched, FIRST time** (`isGenericFallback` is `true` — the result is the
+   catch-all `build-feature` / `produce-deliverable`, or `confidence` is `low` — AND you have not yet
+   asked the clarifying question this gate): do NOT present the catch-all as a verdict. This case
+   should be RARE. Instead ask ONE clarifying question that elicits the missing signal — what KIND of
+   work this is — grounded in their ask, with concrete examples that lead the reply. The examples
+   span the catalog's functions so the user can self-identify; tailor the wording to their ask. This
+   is the fallback step that lets us classify properly instead of defaulting blind (see
+   `loud-fallback-escalation.md`).
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+
+   I couldn't pin this to a specific job — your ask reads as an outcome, and the flow scopes much
+   better when I know what KIND of work it is. Which is closest (or say it in your own words)?
+     • A coding-agent / MCP / skill capability — tooling the agent itself uses
+     • A backend service or API
+     • A frontend / UI feature
+     • A refactor, migration, or infra / platform change
+     • Something else — tell me in a sentence
+
+   Reply with the closest fit (or your own words) and I'll lock the job.
+   ```
+
+   When the user answers, call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input` plus
+   `correction` = their reply (and `previous_jtbd`), then re-render: **2a** if it now matched a
+   specific job, otherwise **2c**.
+
+   **2c — Still generic after the clarifying question** (`isGenericFallback` is STILL `true` after the
+   user answered 2b): do NOT ask again. Proceed as a generic build with the function-agnostic
+   `Feature Brief` deliverable, and note the job can be renamed later. The job name stays generic —
+   never show a function-specific deliverable (e.g. "Frontend Web") for an unclassified build.
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+   I'll treat this as a generic build — deliverable: Feature Brief. You can rename the job later.
+
+   Reply `proceed` to frame the problem.
+   ```
+
    Do not render `personaCoverage` — persona representation is handled server-side now; only surface
    it if the user explicitly asks who's involved.
 
    Rail naming (deliverable-named rail, 2026-06-11): render `{Deliverable}` as the PROPOSED job's
-   `deliverableTemplate` (e.g. `Launch Brief`, `PRD`, `Service Build Brief`; `Build brief` for the
-   generic `build-feature`), and OMIT the `Implementation (Your agent)` stage entirely when the
-   proposed job is not a development job — non-dev rails have FIVE stages ending at the deliverable.
-   A correction that changes the job updates the rail on the next render. Spec:
+   `deliverableTemplate` from the classify result (e.g. `Launch Brief`, `PRD`, `Service Build Brief`;
+   `Feature Brief` for the generic `build-feature`), and OMIT the `Implementation (Your agent)` stage
+   entirely when the proposed job is not a development job — non-dev rails have FIVE stages ending at
+   the deliverable. A correction that changes the job updates the rail on the next render. Spec:
    `references/cli-output-contract.md` § Canonical stage table.
 
 3. **[USER PAUSE]** — wait for the user's actual reply. Never infer confirmation from the original
    ask, auto-mode, or silence. `proceed` / `yes` / `ok` confirms. ANY other substantive reply is a
    correction: call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input`, plus
    `correction` (the user's words) and `previous_jtbd` (the rejected slug), then re-render step 2.
-   Loop until the user proceeds.
+   The clarifying QUESTION (2b) is asked AT MOST ONCE per gate — if the re-classification after the
+   user's answer is still generic, render **2c** (proceed as a generic `Feature Brief`); do not ask
+   the clarifying question again. Loop until the user proceeds.
 
 4. **Remember the confirmed `jtbd`** — you pass it to `create_exploration` at Step 6. Only after the
    user proceeds does the flow enter the `Scope` stage (workspace pick onward).

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.8",
-  "builtAt": "2026-06-12T04:36:24.525Z",
-  "skillsHash": "49c0dd37dafd"
+  "cliVersion": "0.36.11",
+  "builtAt": "2026-06-14T18:50:01.090Z",
+  "skillsHash": "39dbaf6dbdf9"
 }

package/skills/kiro/ritual/SKILL.md

@@ -3,7 +3,7 @@ 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 plan mode before the agent writes code. Prefer this over jumping straight to implementation or plan mode 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: 49c0dd37dafd
+stamp: 39dbaf6dbdf9
 ---
 
 # /ritual
@@ -20,6 +20,9 @@ Before executing any subcommand, read and follow:
 
 Do not reintroduce `/ritual recon`. Use plain-language repo inspection, `/ritual resume`, or `/ritual lineage` depending on intent.
 
+**Ground before you claim (load-bearing).** An exploration's current state — its recommendation count/status, step, requirement/brief status — is **live truth you read, never recall**. Before stating any of it: if unsure *which* exploration, call `list_explorations` (the compact roster) to fix identity by seeing them side by side; before asserting *what's in* one, call `get_exploration_status` (the cheap status card). Memory and prior turns are authoritative only for identity (which exploration, its title); the graph is authoritative for state. Never assert a recommendation count or status from memory, a session summary, or a stale read — that's how sibling explorations get conflated and "0 recs" gets claimed on an exploration that has many. See `documents/architecture/okf-grounding-policy.md`.
+<!-- skill-options:no-gate-change: grounding rule adds no [USER PAUSE] gate or options; read-before-claim discipline only -->
+
 **Skill freshness (once per session, silent unless stale):** this file's frontmatter may carry a
 `stamp:` value (injected when the bundle was built — absent on dev/source copies). On the FIRST
 `mcp__ritual__ping` of a session, pass it as `skill_stamp`. If the response says

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

@@ -107,6 +107,7 @@ If the user types `always audit for this build` mid-flow at the Step 9.6 prompt,
 Persist `auditMode` to `Exploration.metadata.auditMode` at `create_exploration` time (additive JSONB key — no schema migration) so `/ritual resume <exploration-id>` picks up the same mode the original build started with, and `/ritual lineage <exploration-id>` can render which gates ran + their outcomes.
 
 <!-- lite:keep-start -->
+<!-- skill-options:no-gate-change: 2b (clarifying question) + 2c (generic terminal) are loud-fallback COPY variants of the same gate; options are unchanged (proceed | name-the-job) -->
 #### Step 0.7 — The Job gate: classify the job to be done
 
 **The FIRST tool call of a fresh build.** The server — not you — classifies the user's raw ask into
@@ -122,9 +123,16 @@ When this gate runs:
 
 1. **Call `mcp__ritual__classify_work_item`** with `raw_input` = the user's ask, verbatim. Do NOT
    classify yourself, do NOT pre-filter to development jobs. It returns
-   `{ jtbd, workItemLabel, deliverableTemplate, why, personaCoverage }`.
+   `{ jtbd, workItemLabel, deliverableTemplate, why, confidence, isGenericFallback, personaCoverage }`.
+   `isGenericFallback` (and `confidence`) are the typed-uncertainty signal: when it's `true`, the
+   result is the catch-all (`build-feature` / `produce-deliverable`) or the classifier wasn't sure —
+   it is NOT a confident match, and which render variant you use in step 2 depends on it.
 
-2. **Render the validation prompt** (rail stage `Job`):
+2. **Render the validation prompt** (rail stage `Job`). This gate is a plain-language VALIDATION of
+   what you're about to build: restate the ask + the matched job in the user's words, then let them
+   confirm or correct. Which variant you render depends on `isGenericFallback`.
+
+   **2a — Confident match** (`isGenericFallback` is `false`): the classifier matched a specific job.
 
    ```text
    Ritual build
@@ -138,21 +146,68 @@ When this gate runs:
    job actually is.
    ```
 
+   **2b — No specific job matched, FIRST time** (`isGenericFallback` is `true` — the result is the
+   catch-all `build-feature` / `produce-deliverable`, or `confidence` is `low` — AND you have not yet
+   asked the clarifying question this gate): do NOT present the catch-all as a verdict. This case
+   should be RARE. Instead ask ONE clarifying question that elicits the missing signal — what KIND of
+   work this is — grounded in their ask, with concrete examples that lead the reply. The examples
+   span the catalog's functions so the user can self-identify; tailor the wording to their ask. This
+   is the fallback step that lets us classify properly instead of defaulting blind (see
+   `loud-fallback-escalation.md`).
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+
+   I couldn't pin this to a specific job — your ask reads as an outcome, and the flow scopes much
+   better when I know what KIND of work it is. Which is closest (or say it in your own words)?
+     • A coding-agent / MCP / skill capability — tooling the agent itself uses
+     • A backend service or API
+     • A frontend / UI feature
+     • A refactor, migration, or infra / platform change
+     • Something else — tell me in a sentence
+
+   Reply with the closest fit (or your own words) and I'll lock the job.
+   ```
+
+   When the user answers, call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input` plus
+   `correction` = their reply (and `previous_jtbd`), then re-render: **2a** if it now matched a
+   specific job, otherwise **2c**.
+
+   **2c — Still generic after the clarifying question** (`isGenericFallback` is STILL `true` after the
+   user answered 2b): do NOT ask again. Proceed as a generic build with the function-agnostic
+   `Feature Brief` deliverable, and note the job can be renamed later. The job name stays generic —
+   never show a function-specific deliverable (e.g. "Frontend Web") for an unclassified build.
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+   I'll treat this as a generic build — deliverable: Feature Brief. You can rename the job later.
+
+   Reply `proceed` to frame the problem.
+   ```
+
    Do not render `personaCoverage` — persona representation is handled server-side now; only surface
    it if the user explicitly asks who's involved.
 
    Rail naming (deliverable-named rail, 2026-06-11): render `{Deliverable}` as the PROPOSED job's
-   `deliverableTemplate` (e.g. `Launch Brief`, `PRD`, `Service Build Brief`; `Build brief` for the
-   generic `build-feature`), and OMIT the `Implementation (Your agent)` stage entirely when the
-   proposed job is not a development job — non-dev rails have FIVE stages ending at the deliverable.
-   A correction that changes the job updates the rail on the next render. Spec:
+   `deliverableTemplate` from the classify result (e.g. `Launch Brief`, `PRD`, `Service Build Brief`;
+   `Feature Brief` for the generic `build-feature`), and OMIT the `Implementation (Your agent)` stage
+   entirely when the proposed job is not a development job — non-dev rails have FIVE stages ending at
+   the deliverable. A correction that changes the job updates the rail on the next render. Spec:
    `references/cli-output-contract.md` § Canonical stage table.
 
 3. **[USER PAUSE]** — wait for the user's actual reply. Never infer confirmation from the original
    ask, auto-mode, or silence. `proceed` / `yes` / `ok` confirms. ANY other substantive reply is a
    correction: call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input`, plus
    `correction` (the user's words) and `previous_jtbd` (the rejected slug), then re-render step 2.
-   Loop until the user proceeds.
+   The clarifying QUESTION (2b) is asked AT MOST ONCE per gate — if the re-classification after the
+   user's answer is still generic, render **2c** (proceed as a generic `Feature Brief`); do not ask
+   the clarifying question again. Loop until the user proceeds.
 
 4. **Remember the confirmed `jtbd`** — you pass it to `create_exploration` at Step 6. Only after the
    user proceeds does the flow enter the `Scope` stage (workspace pick onward).

package/skills/kiro/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: d91bf82d5264e811 -->
+<!-- source-sha: bc6ea52efd75e1c7 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -151,6 +151,7 @@ If the user types `always audit for this build` mid-flow at the Step 9.6 prompt,
 Persist `auditMode` to `Exploration.metadata.auditMode` at `create_exploration` time (additive JSONB key — no schema migration) so `/ritual resume <exploration-id>` picks up the same mode the original build started with, and `/ritual lineage <exploration-id>` can render which gates ran + their outcomes.
 
 
+<!-- skill-options:no-gate-change: 2b (clarifying question) + 2c (generic terminal) are loud-fallback COPY variants of the same gate; options are unchanged (proceed | name-the-job) -->
 #### Step 0.7 — The Job gate: classify the job to be done
 
 **The FIRST tool call of a fresh build.** The server — not you — classifies the user's raw ask into
@@ -166,9 +167,16 @@ When this gate runs:
 
 1. **Call `mcp__ritual__classify_work_item`** with `raw_input` = the user's ask, verbatim. Do NOT
    classify yourself, do NOT pre-filter to development jobs. It returns
-   `{ jtbd, workItemLabel, deliverableTemplate, why, personaCoverage }`.
+   `{ jtbd, workItemLabel, deliverableTemplate, why, confidence, isGenericFallback, personaCoverage }`.
+   `isGenericFallback` (and `confidence`) are the typed-uncertainty signal: when it's `true`, the
+   result is the catch-all (`build-feature` / `produce-deliverable`) or the classifier wasn't sure —
+   it is NOT a confident match, and which render variant you use in step 2 depends on it.
 
-2. **Render the validation prompt** (rail stage `Job`):
+2. **Render the validation prompt** (rail stage `Job`). This gate is a plain-language VALIDATION of
+   what you're about to build: restate the ask + the matched job in the user's words, then let them
+   confirm or correct. Which variant you render depends on `isGenericFallback`.
+
+   **2a — Confident match** (`isGenericFallback` is `false`): the classifier matched a specific job.
 
    ```text
    Ritual build
@@ -182,21 +190,68 @@ When this gate runs:
    job actually is.
    ```
 
+   **2b — No specific job matched, FIRST time** (`isGenericFallback` is `true` — the result is the
+   catch-all `build-feature` / `produce-deliverable`, or `confidence` is `low` — AND you have not yet
+   asked the clarifying question this gate): do NOT present the catch-all as a verdict. This case
+   should be RARE. Instead ask ONE clarifying question that elicits the missing signal — what KIND of
+   work this is — grounded in their ask, with concrete examples that lead the reply. The examples
+   span the catalog's functions so the user can self-identify; tailor the wording to their ask. This
+   is the fallback step that lets us classify properly instead of defaulting blind (see
+   `loud-fallback-escalation.md`).
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+
+   I couldn't pin this to a specific job — your ask reads as an outcome, and the flow scopes much
+   better when I know what KIND of work it is. Which is closest (or say it in your own words)?
+     • A coding-agent / MCP / skill capability — tooling the agent itself uses
+     • A backend service or API
+     • A frontend / UI feature
+     • A refactor, migration, or infra / platform change
+     • Something else — tell me in a sentence
+
+   Reply with the closest fit (or your own words) and I'll lock the job.
+   ```
+
+   When the user answers, call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input` plus
+   `correction` = their reply (and `previous_jtbd`), then re-render: **2a** if it now matched a
+   specific job, otherwise **2c**.
+
+   **2c — Still generic after the clarifying question** (`isGenericFallback` is STILL `true` after the
+   user answered 2b): do NOT ask again. Proceed as a generic build with the function-agnostic
+   `Feature Brief` deliverable, and note the job can be renamed later. The job name stays generic —
+   never show a function-specific deliverable (e.g. "Frontend Web") for an unclassified build.
+
+   ```text
+   Ritual build
+   ● Job  ○ Scope  ○ Discovery  ○ Recommendations  ○ Feature Brief
+
+   You're looking to: {restate the ask in one short clause}
+   I'll treat this as a generic build — deliverable: Feature Brief. You can rename the job later.
+
+   Reply `proceed` to frame the problem.
+   ```
+
    Do not render `personaCoverage` — persona representation is handled server-side now; only surface
    it if the user explicitly asks who's involved.
 
    Rail naming (deliverable-named rail, 2026-06-11): render `{Deliverable}` as the PROPOSED job's
-   `deliverableTemplate` (e.g. `Launch Brief`, `PRD`, `Service Build Brief`; `Build brief` for the
-   generic `build-feature`), and OMIT the `Implementation (Your agent)` stage entirely when the
-   proposed job is not a development job — non-dev rails have FIVE stages ending at the deliverable.
-   A correction that changes the job updates the rail on the next render. Spec:
+   `deliverableTemplate` from the classify result (e.g. `Launch Brief`, `PRD`, `Service Build Brief`;
+   `Feature Brief` for the generic `build-feature`), and OMIT the `Implementation (Your agent)` stage
+   entirely when the proposed job is not a development job — non-dev rails have FIVE stages ending at
+   the deliverable. A correction that changes the job updates the rail on the next render. Spec:
    `references/cli-output-contract.md` § Canonical stage table.
 
 3. **[USER PAUSE]** — wait for the user's actual reply. Never infer confirmation from the original
    ask, auto-mode, or silence. `proceed` / `yes` / `ok` confirms. ANY other substantive reply is a
    correction: call `mcp__ritual__classify_work_item` AGAIN with the same `raw_input`, plus
    `correction` (the user's words) and `previous_jtbd` (the rejected slug), then re-render step 2.
-   Loop until the user proceeds.
+   The clarifying QUESTION (2b) is asked AT MOST ONCE per gate — if the re-classification after the
+   user's answer is still generic, render **2c** (proceed as a generic `Feature Brief`); do not ask
+   the clarifying question again. Loop until the user proceeds.
 
 4. **Remember the confirmed `jtbd`** — you pass it to `create_exploration` at Step 6. Only after the
    user proceeds does the flow enter the `Scope` stage (workspace pick onward).

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.8",
-  "builtAt": "2026-06-12T04:36:24.525Z",
-  "skillsHash": "49c0dd37dafd"
+  "cliVersion": "0.36.11",
+  "builtAt": "2026-06-14T18:50:01.090Z",
+  "skillsHash": "39dbaf6dbdf9"
 }

package/skills/vscode/ritual/SKILL.md

@@ -3,7 +3,7 @@ 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 plan mode before the agent writes code. Prefer this over jumping straight to implementation or plan mode 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: 49c0dd37dafd
+stamp: 39dbaf6dbdf9
 ---
 
 # /ritual
@@ -20,6 +20,9 @@ Before executing any subcommand, read and follow:
 
 Do not reintroduce `/ritual recon`. Use plain-language repo inspection, `/ritual resume`, or `/ritual lineage` depending on intent.
 
+**Ground before you claim (load-bearing).** An exploration's current state — its recommendation count/status, step, requirement/brief status — is **live truth you read, never recall**. Before stating any of it: if unsure *which* exploration, call `list_explorations` (the compact roster) to fix identity by seeing them side by side; before asserting *what's in* one, call `get_exploration_status` (the cheap status card). Memory and prior turns are authoritative only for identity (which exploration, its title); the graph is authoritative for state. Never assert a recommendation count or status from memory, a session summary, or a stale read — that's how sibling explorations get conflated and "0 recs" gets claimed on an exploration that has many. See `documents/architecture/okf-grounding-policy.md`.
+<!-- skill-options:no-gate-change: grounding rule adds no [USER PAUSE] gate or options; read-before-claim discipline only -->
+
 **Skill freshness (once per session, silent unless stale):** this file's frontmatter may carry a
 `stamp:` value (injected when the bundle was built — absent on dev/source copies). On the FIRST
 `mcp__ritual__ping` of a session, pass it as `skill_stamp`. If the response says