@ritualai/cli 0.25.0 → 0.36.9

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

@@ -1,4 +1,5 @@
 {
-  "cliVersion": "0.25.0",
-  "builtAt": "2026-06-09T00:58:35.759Z"
+  "cliVersion": "0.36.9",
+  "builtAt": "2026-06-14T10:07:00.491Z",
+  "skillsHash": "26b50ff4f856"
 }

package/skills/codex/ritual/SKILL.md

@@ -3,6 +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: 26b50ff4f856
 ---
 
 # /ritual
@@ -19,6 +20,16 @@ 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
+`skillFreshness: "stale"`, relay its one-line hint ("Skill update available — run
+`ritual init --skills-only` to refresh") exactly once, no pause, and continue with the current flow.
+No stamp, or `in-sync`/`unknown` → say nothing. Never block on this.
+
 ## Contract strength — load-bearing for all subcommands
 
 Every section in this SKILL or its reference files labeled **load-bearing**, **forbidden behavior**, **anti-pattern**, **rendering contract**, or **fire-on-trigger** is **contract-strength**, not guidance.