@ritualai/cli 0.36.22 → 0.36.25

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

@@ -837,6 +837,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -879,6 +881,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1841,7 +1844,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -307,6 +307,7 @@ When you need to wait for async server work (requirements generation, build brie
 This rule applies to: Step 9.5 (`get_requirement_set_status`), Step 10b (`get_build_brief_status` on timeout), and any future status-poll surface.
 
 <!-- skill-options:no-gate-change: pulse render gains a delta + next-lift line; no decision gate, option, or pause is added or changed -->
+<!-- skill-options:no-gate-change: pulse delta now renders as a Context Debt directional drop (Context Debt N% ↓M%) instead of a bare · +N%, so the movement reads as debt going down; render-only, no gate/option/pause change -->
 
 #### Inline pulses — surface reasoning readiness climbing as context debt drops
 
@@ -319,11 +320,11 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
   ```text
   {…the step's content…}
 
-  Pulse: Reasoning Readiness 58% · Context Debt 42% · +3% (scope locked)
+  Pulse: Reasoning Readiness 58% · Context Debt 42% ↓3% (scope locked)
   Reply  proceed (run discovery → recommendations)  ·  expert  ·  pause
   ```
 
-  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The **`· +N%` delta is MANDATORY** on every pulse after the first (the first pulse has no prior, so it shows just the baseline + reason). The delta is the visible-progress signal — never drop it. Show `+0%` honestly if a step didn't move the score, and `−N%` on a regression (rare; render full then).
+  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The progress delta attaches to **Context Debt as a directional drop** — `Context Debt 42% ↓3%` — so the movement reads unambiguously as debt going DOWN. (A bare `· +3%` sitting next to the debt figure reads like debt went UP by 3, the opposite of progress — that's the confusion this avoids.) The delta is **MANDATORY** on every pulse after the first (the first pulse has no prior → just the baseline + reason). Use `↓N%` when debt drops (the normal, good case), `↑N%` on a regression (rare; render full then), and `±0%` when a step didn't move the score. Never drop it — it's the visible-progress signal. (Readiness climbing and debt dropping are the same move — `Reasoning Readiness + Context Debt = 100%` — so the debt-drop arrow IS the readiness-gain signal, just framed the way users read it.)
   - **Lift bridge** (ONE sentence, immediately ABOVE the action/CTA line — NOT under the score). This is the load-bearing piece: it turns the score into a reason to proceed. Three requirements:
     1. **Plain language for the gap — NEVER the internal dimension name.** The lowest dimension from `score_context_pulse`'s breakdown picks the message, but the user sees what it MEANS, not the label:
        | lowest dimension (internal) | what the user reads (plain) |
@@ -335,7 +336,7 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
     2. **Name the NEXT STEP as the resolver, explicitly.** The bridge must make clear that the action the user is about to take is what closes the gap — `that's exactly what the next step, discovery, resolves` / `code recon next grounds it` / `the build brief locks those down`. The bridge and the forward-CTA below it name the SAME move — one story.
     3. **Terse + declarative** — no `now let me help you improve this` assistant/affect register (`cli-experience-tenets.md`).
     On the LAST scoreable step (Step 10, implementation-ready), there's no further lift — the bridge becomes the readiness statement: `The brief is your build path — implement when ready.`
-- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `+N%` delta on the score line and the same lift bridge above the CTA.
+- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `Context Debt N% ↓M%` delta on the score line and the same lift bridge above the CTA.
 - The score line goes near the top of the step's message; the lift bridge goes right before the action line. Both are additive, not replacements.
 - Prefer `mcp__ritual__score_context_pulse` (one canonical server-side call, persisted for trend reporting); fall back to deterministic agent-side counts only if the tool errors. No LLM call in the hot path either way.
 

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: 49db57c7a618c67e -->
+<!-- source-sha: 8175b963af80b591 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -929,6 +929,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -971,6 +973,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1905,7 +1908,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.22",
-  "builtAt": "2026-06-15T13:28:31.790Z",
-  "skillsHash": "8a8905aae549"
+  "cliVersion": "0.36.25",
+  "builtAt": "2026-06-15T14:41:36.894Z",
+  "skillsHash": "5c3ae1fc185a"
 }

package/skills/cursor/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: 8a8905aae549
+stamp: 5c3ae1fc185a
 ---
 
 # /ritual

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

@@ -837,6 +837,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -879,6 +881,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1841,7 +1844,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -307,6 +307,7 @@ When you need to wait for async server work (requirements generation, build brie
 This rule applies to: Step 9.5 (`get_requirement_set_status`), Step 10b (`get_build_brief_status` on timeout), and any future status-poll surface.
 
 <!-- skill-options:no-gate-change: pulse render gains a delta + next-lift line; no decision gate, option, or pause is added or changed -->
+<!-- skill-options:no-gate-change: pulse delta now renders as a Context Debt directional drop (Context Debt N% ↓M%) instead of a bare · +N%, so the movement reads as debt going down; render-only, no gate/option/pause change -->
 
 #### Inline pulses — surface reasoning readiness climbing as context debt drops
 
@@ -319,11 +320,11 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
   ```text
   {…the step's content…}
 
-  Pulse: Reasoning Readiness 58% · Context Debt 42% · +3% (scope locked)
+  Pulse: Reasoning Readiness 58% · Context Debt 42% ↓3% (scope locked)
   Reply  proceed (run discovery → recommendations)  ·  expert  ·  pause
   ```
 
-  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The **`· +N%` delta is MANDATORY** on every pulse after the first (the first pulse has no prior, so it shows just the baseline + reason). The delta is the visible-progress signal — never drop it. Show `+0%` honestly if a step didn't move the score, and `−N%` on a regression (rare; render full then).
+  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The progress delta attaches to **Context Debt as a directional drop** — `Context Debt 42% ↓3%` — so the movement reads unambiguously as debt going DOWN. (A bare `· +3%` sitting next to the debt figure reads like debt went UP by 3, the opposite of progress — that's the confusion this avoids.) The delta is **MANDATORY** on every pulse after the first (the first pulse has no prior → just the baseline + reason). Use `↓N%` when debt drops (the normal, good case), `↑N%` on a regression (rare; render full then), and `±0%` when a step didn't move the score. Never drop it — it's the visible-progress signal. (Readiness climbing and debt dropping are the same move — `Reasoning Readiness + Context Debt = 100%` — so the debt-drop arrow IS the readiness-gain signal, just framed the way users read it.)
   - **Lift bridge** (ONE sentence, immediately ABOVE the action/CTA line — NOT under the score). This is the load-bearing piece: it turns the score into a reason to proceed. Three requirements:
     1. **Plain language for the gap — NEVER the internal dimension name.** The lowest dimension from `score_context_pulse`'s breakdown picks the message, but the user sees what it MEANS, not the label:
        | lowest dimension (internal) | what the user reads (plain) |
@@ -335,7 +336,7 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
     2. **Name the NEXT STEP as the resolver, explicitly.** The bridge must make clear that the action the user is about to take is what closes the gap — `that's exactly what the next step, discovery, resolves` / `code recon next grounds it` / `the build brief locks those down`. The bridge and the forward-CTA below it name the SAME move — one story.
     3. **Terse + declarative** — no `now let me help you improve this` assistant/affect register (`cli-experience-tenets.md`).
     On the LAST scoreable step (Step 10, implementation-ready), there's no further lift — the bridge becomes the readiness statement: `The brief is your build path — implement when ready.`
-- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `+N%` delta on the score line and the same lift bridge above the CTA.
+- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `Context Debt N% ↓M%` delta on the score line and the same lift bridge above the CTA.
 - The score line goes near the top of the step's message; the lift bridge goes right before the action line. Both are additive, not replacements.
 - Prefer `mcp__ritual__score_context_pulse` (one canonical server-side call, persisted for trend reporting); fall back to deterministic agent-side counts only if the tool errors. No LLM call in the hot path either way.
 

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: 49db57c7a618c67e -->
+<!-- source-sha: 8175b963af80b591 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -929,6 +929,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -971,6 +973,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1905,7 +1908,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.22",
-  "builtAt": "2026-06-15T13:28:31.790Z",
-  "skillsHash": "8a8905aae549"
+  "cliVersion": "0.36.25",
+  "builtAt": "2026-06-15T14:41:36.894Z",
+  "skillsHash": "5c3ae1fc185a"
 }

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: 8a8905aae549
+stamp: 5c3ae1fc185a
 ---
 
 # /ritual

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

@@ -837,6 +837,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -879,6 +881,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1841,7 +1844,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -307,6 +307,7 @@ When you need to wait for async server work (requirements generation, build brie
 This rule applies to: Step 9.5 (`get_requirement_set_status`), Step 10b (`get_build_brief_status` on timeout), and any future status-poll surface.
 
 <!-- skill-options:no-gate-change: pulse render gains a delta + next-lift line; no decision gate, option, or pause is added or changed -->
+<!-- skill-options:no-gate-change: pulse delta now renders as a Context Debt directional drop (Context Debt N% ↓M%) instead of a bare · +N%, so the movement reads as debt going down; render-only, no gate/option/pause change -->
 
 #### Inline pulses — surface reasoning readiness climbing as context debt drops
 
@@ -319,11 +320,11 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
   ```text
   {…the step's content…}
 
-  Pulse: Reasoning Readiness 58% · Context Debt 42% · +3% (scope locked)
+  Pulse: Reasoning Readiness 58% · Context Debt 42% ↓3% (scope locked)
   Reply  proceed (run discovery → recommendations)  ·  expert  ·  pause
   ```
 
-  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The **`· +N%` delta is MANDATORY** on every pulse after the first (the first pulse has no prior, so it shows just the baseline + reason). The delta is the visible-progress signal — never drop it. Show `+0%` honestly if a step didn't move the score, and `−N%` on a regression (rare; render full then).
+  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The progress delta attaches to **Context Debt as a directional drop** — `Context Debt 42% ↓3%` — so the movement reads unambiguously as debt going DOWN. (A bare `· +3%` sitting next to the debt figure reads like debt went UP by 3, the opposite of progress — that's the confusion this avoids.) The delta is **MANDATORY** on every pulse after the first (the first pulse has no prior → just the baseline + reason). Use `↓N%` when debt drops (the normal, good case), `↑N%` on a regression (rare; render full then), and `±0%` when a step didn't move the score. Never drop it — it's the visible-progress signal. (Readiness climbing and debt dropping are the same move — `Reasoning Readiness + Context Debt = 100%` — so the debt-drop arrow IS the readiness-gain signal, just framed the way users read it.)
   - **Lift bridge** (ONE sentence, immediately ABOVE the action/CTA line — NOT under the score). This is the load-bearing piece: it turns the score into a reason to proceed. Three requirements:
     1. **Plain language for the gap — NEVER the internal dimension name.** The lowest dimension from `score_context_pulse`'s breakdown picks the message, but the user sees what it MEANS, not the label:
        | lowest dimension (internal) | what the user reads (plain) |
@@ -335,7 +336,7 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
     2. **Name the NEXT STEP as the resolver, explicitly.** The bridge must make clear that the action the user is about to take is what closes the gap — `that's exactly what the next step, discovery, resolves` / `code recon next grounds it` / `the build brief locks those down`. The bridge and the forward-CTA below it name the SAME move — one story.
     3. **Terse + declarative** — no `now let me help you improve this` assistant/affect register (`cli-experience-tenets.md`).
     On the LAST scoreable step (Step 10, implementation-ready), there's no further lift — the bridge becomes the readiness statement: `The brief is your build path — implement when ready.`
-- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `+N%` delta on the score line and the same lift bridge above the CTA.
+- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `Context Debt N% ↓M%` delta on the score line and the same lift bridge above the CTA.
 - The score line goes near the top of the step's message; the lift bridge goes right before the action line. Both are additive, not replacements.
 - Prefer `mcp__ritual__score_context_pulse` (one canonical server-side call, persisted for trend reporting); fall back to deterministic agent-side counts only if the tool errors. No LLM call in the hot path either way.
 

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: 49db57c7a618c67e -->
+<!-- source-sha: 8175b963af80b591 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -929,6 +929,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -971,6 +973,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1905,7 +1908,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.22",
-  "builtAt": "2026-06-15T13:28:31.790Z",
-  "skillsHash": "8a8905aae549"
+  "cliVersion": "0.36.25",
+  "builtAt": "2026-06-15T14:41:36.894Z",
+  "skillsHash": "5c3ae1fc185a"
 }

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: 8a8905aae549
+stamp: 5c3ae1fc185a
 ---
 
 # /ritual

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

@@ -837,6 +837,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -879,6 +881,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1841,7 +1844,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -307,6 +307,7 @@ When you need to wait for async server work (requirements generation, build brie
 This rule applies to: Step 9.5 (`get_requirement_set_status`), Step 10b (`get_build_brief_status` on timeout), and any future status-poll surface.
 
 <!-- skill-options:no-gate-change: pulse render gains a delta + next-lift line; no decision gate, option, or pause is added or changed -->
+<!-- skill-options:no-gate-change: pulse delta now renders as a Context Debt directional drop (Context Debt N% ↓M%) instead of a bare · +N%, so the movement reads as debt going down; render-only, no gate/option/pause change -->
 
 #### Inline pulses — surface reasoning readiness climbing as context debt drops
 
@@ -319,11 +320,11 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
   ```text
   {…the step's content…}
 
-  Pulse: Reasoning Readiness 58% · Context Debt 42% · +3% (scope locked)
+  Pulse: Reasoning Readiness 58% · Context Debt 42% ↓3% (scope locked)
   Reply  proceed (run discovery → recommendations)  ·  expert  ·  pause
   ```
 
-  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The **`· +N%` delta is MANDATORY** on every pulse after the first (the first pulse has no prior, so it shows just the baseline + reason). The delta is the visible-progress signal — never drop it. Show `+0%` honestly if a step didn't move the score, and `−N%` on a regression (rare; render full then).
+  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The progress delta attaches to **Context Debt as a directional drop** — `Context Debt 42% ↓3%` — so the movement reads unambiguously as debt going DOWN. (A bare `· +3%` sitting next to the debt figure reads like debt went UP by 3, the opposite of progress — that's the confusion this avoids.) The delta is **MANDATORY** on every pulse after the first (the first pulse has no prior → just the baseline + reason). Use `↓N%` when debt drops (the normal, good case), `↑N%` on a regression (rare; render full then), and `±0%` when a step didn't move the score. Never drop it — it's the visible-progress signal. (Readiness climbing and debt dropping are the same move — `Reasoning Readiness + Context Debt = 100%` — so the debt-drop arrow IS the readiness-gain signal, just framed the way users read it.)
   - **Lift bridge** (ONE sentence, immediately ABOVE the action/CTA line — NOT under the score). This is the load-bearing piece: it turns the score into a reason to proceed. Three requirements:
     1. **Plain language for the gap — NEVER the internal dimension name.** The lowest dimension from `score_context_pulse`'s breakdown picks the message, but the user sees what it MEANS, not the label:
        | lowest dimension (internal) | what the user reads (plain) |
@@ -335,7 +336,7 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
     2. **Name the NEXT STEP as the resolver, explicitly.** The bridge must make clear that the action the user is about to take is what closes the gap — `that's exactly what the next step, discovery, resolves` / `code recon next grounds it` / `the build brief locks those down`. The bridge and the forward-CTA below it name the SAME move — one story.
     3. **Terse + declarative** — no `now let me help you improve this` assistant/affect register (`cli-experience-tenets.md`).
     On the LAST scoreable step (Step 10, implementation-ready), there's no further lift — the bridge becomes the readiness statement: `The brief is your build path — implement when ready.`
-- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `+N%` delta on the score line and the same lift bridge above the CTA.
+- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `Context Debt N% ↓M%` delta on the score line and the same lift bridge above the CTA.
 - The score line goes near the top of the step's message; the lift bridge goes right before the action line. Both are additive, not replacements.
 - Prefer `mcp__ritual__score_context_pulse` (one canonical server-side call, persisted for trend reporting); fall back to deterministic agent-side counts only if the tool errors. No LLM call in the hot path either way.
 

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: 49db57c7a618c67e -->
+<!-- source-sha: 8175b963af80b591 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -929,6 +929,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -971,6 +973,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1905,7 +1908,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -1,5 +1,5 @@
 {
-  "cliVersion": "0.36.22",
-  "builtAt": "2026-06-15T13:28:31.790Z",
-  "skillsHash": "8a8905aae549"
+  "cliVersion": "0.36.25",
+  "builtAt": "2026-06-15T14:41:36.894Z",
+  "skillsHash": "5c3ae1fc185a"
 }

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: 8a8905aae549
+stamp: 5c3ae1fc185a
 ---
 
 # /ritual

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

@@ -837,6 +837,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -879,6 +881,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1841,7 +1844,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})

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

@@ -307,6 +307,7 @@ When you need to wait for async server work (requirements generation, build brie
 This rule applies to: Step 9.5 (`get_requirement_set_status`), Step 10b (`get_build_brief_status` on timeout), and any future status-poll surface.
 
 <!-- skill-options:no-gate-change: pulse render gains a delta + next-lift line; no decision gate, option, or pause is added or changed -->
+<!-- skill-options:no-gate-change: pulse delta now renders as a Context Debt directional drop (Context Debt N% ↓M%) instead of a bare · +N%, so the movement reads as debt going down; render-only, no gate/option/pause change -->
 
 #### Inline pulses — surface reasoning readiness climbing as context debt drops
 
@@ -319,11 +320,11 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
   ```text
   {…the step's content…}
 
-  Pulse: Reasoning Readiness 58% · Context Debt 42% · +3% (scope locked)
+  Pulse: Reasoning Readiness 58% · Context Debt 42% ↓3% (scope locked)
   Reply  proceed (run discovery → recommendations)  ·  expert  ·  pause
   ```
 
-  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The **`· +N%` delta is MANDATORY** on every pulse after the first (the first pulse has no prior, so it shows just the baseline + reason). The delta is the visible-progress signal — never drop it. Show `+0%` honestly if a step didn't move the score, and `−N%` on a regression (rare; render full then).
+  - **Score line** (top of the message). Full capitalized labels — `Reasoning Readiness` and `Context Debt`, NOT lowercase. The progress delta attaches to **Context Debt as a directional drop** — `Context Debt 42% ↓3%` — so the movement reads unambiguously as debt going DOWN. (A bare `· +3%` sitting next to the debt figure reads like debt went UP by 3, the opposite of progress — that's the confusion this avoids.) The delta is **MANDATORY** on every pulse after the first (the first pulse has no prior → just the baseline + reason). Use `↓N%` when debt drops (the normal, good case), `↑N%` on a regression (rare; render full then), and `±0%` when a step didn't move the score. Never drop it — it's the visible-progress signal. (Readiness climbing and debt dropping are the same move — `Reasoning Readiness + Context Debt = 100%` — so the debt-drop arrow IS the readiness-gain signal, just framed the way users read it.)
   - **Lift bridge** (ONE sentence, immediately ABOVE the action/CTA line — NOT under the score). This is the load-bearing piece: it turns the score into a reason to proceed. Three requirements:
     1. **Plain language for the gap — NEVER the internal dimension name.** The lowest dimension from `score_context_pulse`'s breakdown picks the message, but the user sees what it MEANS, not the label:
        | lowest dimension (internal) | what the user reads (plain) |
@@ -335,7 +336,7 @@ The pulse rule and visual specs live in the [§ /ritual context-pulse](#ritual-c
     2. **Name the NEXT STEP as the resolver, explicitly.** The bridge must make clear that the action the user is about to take is what closes the gap — `that's exactly what the next step, discovery, resolves` / `code recon next grounds it` / `the build brief locks those down`. The bridge and the forward-CTA below it name the SAME move — one story.
     3. **Terse + declarative** — no `now let me help you improve this` assistant/affect register (`cli-experience-tenets.md`).
     On the LAST scoreable step (Step 10, implementation-ready), there's no further lift — the bridge becomes the readiness statement: `The brief is your build path — implement when ready.`
-- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `+N%` delta on the score line and the same lift bridge above the CTA.
+- **Full (with bars + Reasoning Readiness / Context Debt / Context Surface labels)** when crossing a state-tier boundary, jumping ≥15%, or regressing. Full mode keeps the same `Context Debt N% ↓M%` delta on the score line and the same lift bridge above the CTA.
 - The score line goes near the top of the step's message; the lift bridge goes right before the action line. Both are additive, not replacements.
 - Prefer `mcp__ritual__score_context_pulse` (one canonical server-side call, persisted for trend reporting); fall back to deterministic agent-side counts only if the tool errors. No LLM call in the hot path either way.
 

package/skills/vscode/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: 49db57c7a618c67e -->
+<!-- source-sha: 8175b963af80b591 -->
 
 # /ritual lite — fast build (generated; do not edit)
 
@@ -929,6 +929,8 @@ Store the final sub-problems for Step 5 — they go into `considerations[]`.
 
 #### Step 5 — Generate problem frame
 
+<!-- skill-options:no-gate-change: Step 5 adds a render-only rule (do not surface follow_up_questions / an "open questions" preview / fuzzy-meta at the frame gate); the frame's pause + options + Reply line are unchanged. -->
+
 ##### 5.1 First draft
 
 Call `mcp__ritual__generate_problem_statement` with:
@@ -971,6 +973,7 @@ Or reply with edits, e.g. `tighten`, `broaden`, `focus on outbox`, `drop dashboa
 ```
 
 Rules:
+- **Render ONLY the four blocks above** — Problem frame, Optimize for, References, and the Reply line. Nothing else. The `generate_problem_statement` response may include `follow_up_questions` and quality scores: those are for YOUR internal awareness, never for display. Do NOT add an "Open questions" / "what discovery will resolve" section, do NOT preview or list discovery questions here, and do NOT editorialize about what's "still fuzzy" or "what the next step pins down." Discovery is the next step and owns open questions; the frame is a lock-point, not a discovery preview. Surfacing them here both pre-empts Step 7 and clutters the gate.
 - Do not show the old versioned scope heading.
 - Do not show `Engineering problem:` as the heading; use `Problem frame`.
 - Do not say `ship it` unless the user used that language first.
@@ -1905,7 +1908,7 @@ or proceed to your {Deliverable}.
 
 {…every category, every rec, one line each…}
 
-Pulse: Reasoning Readiness ~88% · Context Debt 12% · +16% (recommendations ready)
+Pulse: Reasoning Readiness ~88% · Context Debt 12% ↓16% (recommendations ready)
 
 A few assumptions are still unverified — the build brief is what locks them down.
 Reply  drill R{N} (read one in full)   ·   edit R{N} <your change>   ·   proceed (generate the {Deliverable})