[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NCEPG85JMADE02BJG84DTP":3,"skill-same:01M6NCEPG85JMADE02BJG84DTP":47},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":14,"categories":15,"keywords":16,"publishedAt":21,"linkOnly":22,"markdownContent":23,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M6NCEPG85JMADE02BJG84DTP","odylith-delivery-governance-surface-ops",null,"odylith\u002Fodylith","odylith","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273743042?v=4","01M6NBM8TE74H3GP527QEJFCPB","01M6NBM8YT7A5XTNABG4R5KQQ0",36,"MIT","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fodylith\u002Fskills\u002Fodylith-delivery-governance-surface-ops\u002FSKILL.md",[],[17,18,19,20],"governance","ops","delivery","odylith delivery governance surface ops","2026-11-10 10:12:30",false,"# Delivery Governance Surface Ops\n\n## Governance-Learning Default\nBefore acting on a durable error, escaped defect, failed mechanism, failed simulation, bad generated artifact, semantic drift, quality-gate miss, latency breach, architecture decision, validation result, or release-risk learning, search Casebook and related governance truth first. Read prior failed mechanisms, failed fix attempts, rejected approaches, guardrails, and validation history; do not repeat a fix path that already failed. Capture new mechanism-level learning in Casebook or Compass, and update Radar or plans, Registry, and Atlas when the learning changes planned work, component contracts, or flows.\n\n## CLI-First Non-Negotiable\n- CLI-first is non-negotiable for both Codex and Claude Code. Remove all hand-authoring for places where Odylith CLI should be doing the heavy-lifting. When an Odylith CLI command exists for an operation, you must call the CLI command and you must not hand-edit governed files the CLI owns. Hand-authoring governed truth where a CLI exists is a hard policy violation, not a stylistic preference. The authoritative policy, CLI surface enumeration, allowed hand-edit surfaces, and failure-mode handling live in `odylith\u002Fagents-guidelines\u002FCLI_FIRST_POLICY.md`, anchored by Casebook learning `CB-104`. The rule travels through routed `spawn_agent` leaves on Codex and Task-tool subagents on Claude Code, so delegated work inherits the same contract.\n\nUse this skill for substantive grounded repo work when Odylith should keep backlog, plans, components, Atlas, Casebook, Compass, and closeout truth synchronized automatically.\n\n## Lane Boundary\n- Consumer lane:\n  - use `.\u002F.odylith\u002Fbin\u002Fodylith` for Odylith commands\n  - validate repo code with the consumer repo's own toolchain\n- Product-repo maintainer mode:\n  - pinned dogfood posture proves the shipped runtime\n  - detached `source-local` posture is the explicit live-source dev lane\n- Interpreter choice does not control which repo files the agent may edit.\n- Consumer source truth must never be seeded from product-repo maintainer\n  truth. The install bundle may ship reusable shells, static assets, guidance,\n  skills, release notes, brand assets, and runtime corpora only; raw Radar,\n  Casebook, Compass, Registry, Atlas, and plan truth stay in maintainer source.\n\n## Default Flow\n- ground the slice through Odylith packets first\n- keep commentary focused on the slice, the repo truth, and the validation plan; avoid narrating startup, routing, or degraded-attempt internals unless the user needs a command or a blocker explanation\n- keep Odylith ambient by default during work; weave grounded governance facts into ordinary updates and only emit explicit `Odylith Insight:`, `Odylith History:`, or `Odylith Risks:` lines when they materially change the next move\n- when closeout would benefit from naming Odylith, or when visible-intervention renders a prompt-submit or visibility-proof fallback, use at most one short `Odylith Assist:` line; prefer `**Odylith Assist:**` when Markdown formatting is available. Lead with the user win, link updated governance IDs inline only when they actually changed, name affected governance-contract IDs from bounded request or packet truth when no governed file moved, frame the edge against `odylith_off` or the broader unguided path when the evidence supports it, and back it with concrete observed counts, measured deltas, or validation outcomes, or a concrete chat-visibility complaint. Keep it crisp, authentic, clear, simple, insightful, erudite in thought, soulful, friendly, free-flowing, human, and factual. Silence is better than filler.\n- search existing workstream, plan, bug, component, diagram, and session or Compass context before writing\n- extend, consolidate, or reopen existing truth before creating new governed records\n- create a missing workstream and bound plan before non-trivial implementation when the slice is genuinely new\n- in the Odylith product repo, name Radar workstreams after the slice itself and do not prefix the title with `Odylith`\n- add child workstreams or execution waves when the slice is truly umbrella-shaped\n- use the release-planning contract when the operator talks about `current release`, `next release`, `release x.y.z`, or adding\u002Fremoving\u002Fmoving `B-###` work between releases; in human-facing copy prefer `active target release` for the live planning lane and `latest shipped release` for the last GA version\n- suggest or deepen Registry components and living specs when new or clarified system boundaries appear\n- update or create Atlas coverage when a materially changed flow, seam, or contract lacks truthful diagrams\n- run Casebook preflight and capture named failures or repeat-debug loops in the same turn\n- keep Compass updates intent-first and carry forward constraints plus validation obligations\n- treat Compass voice as governed truth: plainspoken grounded maintainer narration in ordinary words, with no stock framing, house phrases, queue-label restatement, repeated window leads, generic priority wrappers, rhetorical benchmark challenges, stagey metaphor, or canned current\u002Fnext\u002Fwhy\u002Ftiming scaffolding in Compass-facing summaries or updates\n- keep Compass cheap too: `odylith compass refresh --repo-root .` is the quick cache-first rerender, `odylith compass deep-refresh --repo-root .` is the settled rerender, timeline audit inputs should be reused instead of recomputed through model calls, and future work must not reintroduce a second refresh profile or expensive truth mode\n- for briefs, follow `LLM writes, local code thinks`:\n  - build deterministic narration substrates locally\n  - rank and budget winner facts before provider input\n  - prefer delta narration over raw packet regeneration\n  - keep one packet-level provider bundle per meaningful fingerprint\n  - never reopen per-scope provider fanout or fuzzy cache replay\n- keep brief provider diagnostics explicit and bounded. Skip provider calls\n  when the winning story did not change, and let capacity or budget failures\n  slow the retry lane instead of hammering the same packet. Do not add a\n  separate narration attempt recorder.\n- keep internal diagnostics out of product chrome. Do not render status\u002Fcockpit\n  UI into the dashboard shell: no status drawer, status presenter, recorder\n  tape, chart canvas, ECharts dependency, snapshot slab, or legacy\n  `odylith_drawer` product path. Do not load internal delivery, evaluation,\n  optimization, or memory snapshots into the top-level shell payload. If a\n  slice touches dashboard shell status, add or run headless browser proof that\n  those strings, selectors, scripts, and snapshot payload keys are absent.\n- use Delivery Intelligence's shared Scope Signal Ladder when deciding what\n  deserves default visibility, promotion, or expensive compute:\n  - `R0 suppressed_noise`\n  - `R1 background_trace`\n  - `R2 verified_local`\n  - `R3 active_scope`\n  - `R4 actionable_priority`\n  - `R5 blocking_frontier`\n- do not rebuild urgency heuristics locally in Compass, Radar, Registry,\n  Atlas, shell, or guidance once `scope_signal` exists\n- treat `scope_signal.budget_class` as provider-neutral policy:\n  - `none`\n  - `cache_only`\n  - `fast_simple`\n  - `escalated_reasoning`\n- low-signal scopes stay hidden by default; explicit deep links may remain but\n  they must render quiet instead of borrowing global activity\n- keep closeout surfaces explicit\n- prefer proof bundles over prose summaries\n- fail closed when the evidence is incomplete\n- use strict refresh and strict check intentionally, not interchangeably\n- treat shared sync\u002Fruntime reuse as governed contract, not hidden optimization:\n  generation-aware provenance must match before Compass, Radar, or Registry\n  trust a warm substrate or cached payload\n- when a surface is reused or rebuilt, expect additive runtime provenance in\n  the payload and a matching cache-explain trail under\n  `.odylith\u002Fcache\u002Fodylith-context-engine\u002F`\n\n## Canonical Commands\n\n```bash\n.\u002F.odylith\u002Fbin\u002Fodylith context-engine --repo-root . governance-slice --working-tree\n.\u002F.odylith\u002Fbin\u002Fodylith sync --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith dashboard refresh --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith radar refresh --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith registry refresh --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith casebook validate --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith casebook refresh --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith atlas refresh --repo-root . --atlas-sync\n.\u002F.odylith\u002Fbin\u002Fodylith compass refresh --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith compass deep-refresh --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith sync --repo-root . --force --impact-mode full --check-clean\n.\u002F.odylith\u002Fbin\u002Fodylith sync --repo-root . --debug-cache\n.\u002F.odylith\u002Fbin\u002Fodylith sync --repo-root . --check-only --check-clean --runtime-mode standalone\n.\u002F.odylith\u002Fbin\u002Fodylith validate plan-traceability --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith validate plan-risk-mitigation --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith release list --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith release show current --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith release update current --repo-root . --status shipped\n.\u002F.odylith\u002Fbin\u002Fodylith release add B-123 current --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith release move B-123 next --repo-root .\n.\u002F.odylith\u002Fbin\u002Fodylith atlas auto-update --repo-root . --from-git-working-tree --fail-on-stale\n.\u002F.odylith\u002Fbin\u002Fodylith atlas render --repo-root . --fail-on-stale\n.\u002F.odylith\u002Fbin\u002Fodylith compass log --repo-root . --kind implementation --summary \"\u003Cintent-first update>\"\n.\u002F.odylith\u002Fbin\u002Fodylith compass watch-transactions --repo-root .\n```\n\n## Rules\n\n- Treat this skill as Odylith's governance-autopilot loop, not as optional closeout polish.\n- Release planning is additive:\n  - execution waves stay the umbrella execution contract\n  - release planning stays the repo-local target-ship contract\n  - the canonical maintainer publication lane stays separate again\n- Keep the operator wording simple:\n  - release planning answers \"what release should this workstream ship in?\"\n  - program or wave planning answers \"how should this umbrella effort execute?\"\n  - a workstream may appear in both because ship target and execution order are different facts\n- Use concrete examples when teaching or updating shell guidance:\n  - `B-067 -> 0.1.11` is release planning\n  - `B-021 -> W1, W2, W3` is program\u002Fwave planning\n- Release selectors are exact and fail-closed. Prefer `release:\u003Cid>` when a natural-language name or version could be ambiguous.\n- `current` and `next` are explicit aliases owned by source truth, not inferred from semver or dates.\n- The current active release stays visible in Compass and other governed read\n  surfaces until an explicit `shipped` or `closed` release update. Zero\n  targeted workstreams is an empty state, not implicit GA.\n- Finished work removed during closeout can still appear as completed release\n  history in Compass; do not confuse that readout with active release\n  targeting.\n- One workstream may have at most one active release target. Use `move`, not a second `add`, when work carries forward.\n- `finished`, `parked`, and `superseded` workstreams must not stay in active releases, and `shipped` or `closed` releases must not keep mutable active planning state.\n- Release `name` is explicit operator-owned source truth. Matching authored\n  release notes may exist for the same `version`, but they must never rename\n  or override the release-planning record without explicit maintainer\n  authorization.\n- If `name` is blank, governed release surfaces may fall back to `version`,\n  then `tag`, then `release_id`; they must never inherit a release-note title\n  as the release name.\n- Interactive `B-###` workstream buttons are a separate compact contract from\n  generic identifier links and labels. Use the shared workstream-button\n  primitive in `src\u002Fodylith\u002Fruntime\u002Fsurfaces\u002Fdashboard_ui_primitives.py`\n  across Compass, Radar, release views, and execution-wave stacks; do not\n  locally resize or repad those controls in renderer\u002Ftemplate CSS.\n- Interactive `B-###` workstream buttons also share one navigation contract:\n  they open Radar. Do not point those buttons at Compass-local scope routes or\n  other surface-local views; keep local scoping as separate row\u002Fdisclosure\n  behavior instead.\n- Generic chip or label selectors must explicitly exclude interactive `B-###`\n  controls so broader styling cannot silently re-inflate workstream buttons.\n- Compass `Release Targets` layout is also operator-owned. Keep\n  `Targeted Workstreams` and `Completed Workstreams` on the established stacked\n  format, and do not reintroduce side-by-side or auto-fit multi-column release\n  boards through renderer or shared-CSS changes unless the operator explicitly\n  authorizes that layout change.\n- In the default unscoped Compass view, treat `Current Workstreams` as the\n  residual focus table after `Programs` and `Release Targets` have claimed\n  their represented workstreams. Do not duplicate those same `B-###` rows in\n  the current table unless the operator explicitly scopes to one of them.\n- Treat top-line governance KPI\u002Fstat cards as a shared shell contract too.\n  Compass hero KPIs, Radar summary stats, Registry summary KPIs, and\n  Casebook summary KPIs should consume the shared Dashboard KPI helpers for\n  grid, card surface, and label\u002Fvalue typography instead of carrying local\n  stat-card CSS in templates or renderers.\n- Treat generic deep-link buttons as shared shell contract too. `Registry`,\n  `Spec`, proof-reference, and `D-###` diagram buttons should reuse the\n  centralized deep-link chip helper in\n  `src\u002Fodylith\u002Fruntime\u002Fsurfaces\u002Fdashboard_ui_primitives.py` instead of\n  surface-local button CSS.\n- Do not render a default proof-state or live-status card in Registry\n  component detail. Proof-state internals such as `Proof Control`,\n  `Live Blocker`, `Fingerprint`, `Frontier`, `Evidence tier`,\n  `Truthful claim`, and commit-hash deployment details belong in deeper\n  diagnostics, not the default Registry detail surface.\n- Do not render internal diagnostics or spend evidence as default dashboard\n  shell chrome. Runtime diagnostics belong in explicit debug artifacts; product\n  shells must stay free of status drawers, cockpit panels, recorder tapes, and\n  chart hydrators.\n- If a surface owns source-generated shell assets, keep one canonical loader\n  or generator path, refresh live and consumer-safe bundled mirrors together,\n  and do not keep a static fork of generated shared CSS when shared plus thin\n  overrides will do.\n- When a slice touches operator-owned shell layout or workstream-button\n  contracts, rerun headless browser proof in both standard and compact shell\n  layouts instead of relying on static selector checks alone.\n- When a slice touches governance KPI\u002Fstat cards, rerun headless browser proof\n  for computed card padding\u002Fradius, label\u002Fvalue typography, and current-release\n  labeling across Compass, Radar, Registry, and Casebook.\n- That browser proof must click representative `B-###` controls in Compass\n  current-workstream rows, Compass release\u002Fexecution-wave stacks, Atlas, and\n  Registry and verify the shell lands on the Radar workstream route.\n- `dashboard refresh --repo-root .` is the low-friction render-only refresh path when you need the shell current without running the full governance pipeline. It refreshes `tooling_shell`, `radar`, and `compass` by default, prints the included and excluded surfaces, and points at `--surfaces atlas --atlas-sync` when Atlas is stale but excluded.\n- `sync --force --impact-mode full --check-clean` is the authoritative write-mode refresh gate.\n- `sync --check-only --check-clean --runtime-mode standalone` is the authoritative non-mutating clean proof lane.\n- Refresh and shell upkeep must stay local and deterministic when the Tribunal reasoning artifact is absent; do not wait on opportunistic provider enrichment just to refresh governed surfaces.\n- If explicit Tribunal provider enrichment times out during a run, keep the remaining cases deterministic instead of retrying the same unhealthy provider path across the whole queue.\n- If strict sync is blocked only by Mermaid freshness, repair Atlas first, rerender, then rerun the strict gate.\n",{},"main","6d249fbca9cd8c41d45e6e2e90a72745cd954ce6","odylith\u002Fskills\u002Fodylith-delivery-governance-surface-ops",3,"https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith","https:\u002F\u002Fodylith.ai","https:\u002F\u002Fgithub.com\u002Fodylith","2026-10-25 01:05:33",{"source":7,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add odylith\u002Fodylith --skill odylith-delivery-governance-surface-ops",{"tool":39,"command":40},"bunx","bunx skills add odylith\u002Fodylith --skill odylith-delivery-governance-surface-ops",{"tool":42,"command":43},"pnpm","pnpm dlx skills add odylith\u002Fodylith --skill odylith-delivery-governance-surface-ops","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fodylith\u002Fskills\u002Fodylith-delivery-governance-surface-ops\u002FSKILL.md",true,[],[48,60,72,89,105,122],{"skillNo":49,"name":50,"nameZh":6,"description":51,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":21},"01M6NDHJPSYZGHRX4S392CCQQE","odylith-version","Inspect the pinned, active, and locally available Odylith versions.","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fsrc\u002Fodylith\u002Fbundle\u002Fassets\u002Fproject-root\u002F.claude\u002Fskills\u002Fodylith-version\u002FSKILL.md",[],[55,56,57,58,59],"odylith version","version","inspect","true","active",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":21},"01M6NDHEGHCN2ARB3MJVKJC1PY","odylith-sync","Refresh governed Odylith surfaces for the current changed slice.","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fsrc\u002Fodylith\u002Fbundle\u002Fassets\u002Fproject-root\u002F.claude\u002Fskills\u002Fodylith-sync\u002FSKILL.md",[],[67,68,69,70,71],"sync","odylith sync","surfaces","for","refresh",{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":21},"01M6NDHBJ21XYP1SHNV2ABS4FJ","odylith-subagent-router","Choose local execution versus bounded delegation for Odylith slices and shape routed payloads.","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fsrc\u002Fodylith\u002Fbundle\u002Fassets\u002Fproject-root\u002F.claude\u002Fskills\u002Fodylith-subagent-router\u002FSKILL.md",[],[79,80,81,82,83,84,85,86,87,58,70,88],"subagent","router","odylith subagent router","payloads","delegation","execution","choose","shape","local","bounded",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":21},"01M6NDH8FPCQB4TBXDZGKZEX43","odylith-subagent-orchestrator","Plan Odylith delegation ownership, bounded fanout, and merge-safe orchestration.","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fsrc\u002Fodylith\u002Fbundle\u002Fassets\u002Fproject-root\u002F.claude\u002Fskills\u002Fodylith-subagent-orchestrator\u002FSKILL.md",[],[96,97,79,98,99,58,88,100,101,102,103,104,83],"subagent orchestrator","orchestrator","odylith subagent orchestrator","ownership","plan","fanout","safe","orchestration","merge",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":21},"01M6NDGT24T77XP3714G3YWTQQ","odylith-start","Run the repo-local Odylith startup contract first, before context\u002Fsearch fan out.","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fsrc\u002Fodylith\u002Fbundle\u002Fassets\u002Fproject-root\u002F.claude\u002Fskills\u002Fodylith-start\u002FSKILL.md",[],[112,113,114,115,116,117,118,119,87,120,121],"start","odylith start","search","run","startup","first","repo","context","contract","contract first",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":21},"01M6NDGNVNGNAFYF76GXJ4CAB4","odylith-show-me","Use when the operator asks what Odylith can do for a repo, requests an advisory repo demo, or asks for the clean scenario-aware show-me output.","https:\u002F\u002Fgithub.com\u002Fodylith\u002Fodylith\u002Fblob\u002Fmain\u002Fsrc\u002Fodylith\u002Fbundle\u002Fassets\u002Fproject-root\u002F.claude\u002Fskills\u002Fodylith-show-me\u002FSKILL.md",[],[129,130,131,132,133,118,134,135,136,137,138,139,140,141,70,142],"odylith show me","me","show me","show","demo","use","clean","do","advisory","scenario","output","requests","can","operator"]