[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77JB6AA33TX762BBC5KSW3D":3,"skill-same:01M77JB6AA33TX762BBC5KSW3D":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":26,"repositoryHtmlUrl":27,"repositoryHomepageUrl":28,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M77JB6AA33TX762BBC5KSW3D","readiness-viewer",null,"Show the stage-centric readiness lens across the kit's sources \u002F tables \u002F reports -- one per-stage status MATRIX over the seven readiness stages, each stage's evidence rendered as NAVIGABLE REFERENCES, and an approvals TIMELINE, read from each item's readiness-status.yaml. Use when someone asks \"show the readiness viewer\", \"which stage is each table at\", \"what evidence backs Gold Ready\", or \"who approved this gate, and when\". READ-ONLY and invoke-and-present only: it RENDERS the recorded state (it never recomputes a status, advances a stage, writes a pass, infers\u002Fback-fills an approval, or fabricates evidence), it runs NO validator and opens NO DB connection, and it emits NO numeric health \u002F confidence \u002F percent-ready score (hard rule #9). It is the stage-lens sibling of the F012 control room: same inputs, different view.","Kemetra\u002FSeshat-BI","Kemetra","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206601658?v=4","01M77J5APND9QAJK8XMBH5B1A8","01M77J5AR4TM1GN2G4GS5KH02J",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freadiness-viewer\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: readiness-viewer\ndescription: >-\n  Show the stage-centric readiness lens across the kit's sources \u002F tables \u002F\n  reports -- one per-stage status MATRIX over the seven readiness stages, each\n  stage's evidence rendered as NAVIGABLE REFERENCES, and an approvals TIMELINE,\n  read from each item's readiness-status.yaml. Use when someone asks \"show the\n  readiness viewer\", \"which stage is each table at\", \"what evidence backs Gold\n  Ready\", or \"who approved this gate, and when\". READ-ONLY and invoke-and-present\n  only: it RENDERS the recorded state (it never recomputes a status, advances a\n  stage, writes a pass, infers\u002Fback-fills an approval, or fabricates evidence),\n  it runs NO validator and opens NO DB connection, and it emits NO numeric\n  health \u002F confidence \u002F percent-ready score (hard rule #9). It is the stage-lens\n  sibling of the F012 control room: same inputs, different view.\n---\n\n# readiness-viewer\n\nThe F012 control room answers \"what is broken, how badly, worst-first\". The\nReadiness Viewer answers a different question over the SAME inputs: \"which of the\nseven stages has each item reached, with what evidence, and who approved the gate\nthat let it advance\". It is a read-only stage-progression LENS over evidence that\nalready exists per item -- it introduces no new validator and no new gate\n(roadmap rule #8; Principle VIII). It renders, then STOPS.\n\n## Module contract (this skill IS a filled Product Module declaration)\n\nThis skill declares its authority category up front, per the F024 Companion Tools\nArchitecture contract (`templates\u002Fmodule-contract.md`).\n\n- **Authority category:** Product Module\n- **Capability level:** `read-only`  *(exactly one)*\n- **Product layer:** `4`  *(the functional axis -- see docs\u002Froadmap\u002Froadmap.md; orthogonal to category; matches the F012 control-room sibling)*\n- **Roadmap feature:** `F026`  **On-disk spec:** `specs\u002F020-readiness-viewer\u002F` *(roadmap F-number is authoritative when the two disagree)*\n- **Owner:** `the readiness \u002F data-quality lead`  *(a named role -- never \"the agent\")*\n- **Status:** `Authored`\n\n### What it does (one line)\n\n> Reads each item's `readiness-status.yaml` (Core Authority) and presents the\n> seven-stage status matrix, each stage's `evidence[]` as navigable references,\n> and the `approvals[]` timeline -- creating no truth.\n\n### Core Authority it READS\n\nIt reads these committed truth artifacts; it never writes them.\n\n- `mappings\u002F\u003Citem>\u002Freadiness-status.yaml` -- `current_stage`, per-stage `status`\n  (the four words), `evidence[]`, `blocking_reasons[]`, `approvals[]`, `next_action`.\n- the files each `evidence[]` entry references (to mark a reference \"referenced\n  file not found\" when absent -- it reads them only to check existence, never edits).\n- the \"Required owner \u002F approval\" field of each `docs\u002Freadiness\u002F\u003Cstage>-ready.md`\n  (to know which gates require an approval before flagging a missing one).\n\n### Derived evidence it WRITES\n\n- none (read-only). A `read-only` module writes NOTHING -- no cache, no report,\n  no per-item file.\n\n### Approved step it EXECUTES\n\n- none (read-only). It executes no step; it renders recorded state.\n\n### Forbidden operations (the matrix says NO)\n\n- MUST NOT create truth: no defining business meaning, no approving a metric\u002Fmapping.\n- MUST NOT grant approval or move a readiness stage to `pass` (named-human \u002F Core\n  Authority only).\n- MUST NOT connect to a DB or external service, and MUST NOT publish a Power BI\n  artifact (those are Execution Adapter capabilities).\n- MUST NOT emit a numeric \u002F maturity \u002F confidence score (hard rule #9).\n- As a `read-only` module it additionally MUST NOT write any derived evidence or\n  execute any step.\n\n### How it handles a missing input\n\nWhen a required Core Authority input is absent, the viewer SURFACES it as a flag\nand renders the gap as a gap -- it never fabricates the input, self-approves, or\nreads a missing-evidence stage as complete (Principle V; stop-and-ask).\n\n- missing `readiness-status.yaml` -> the item's row is \"no readiness file\"\n  (FR-009); a stage with empty `evidence[]` -> \"evidence missing\"; a `pass` gate\n  whose required approval is absent -> \"approval not recorded\" -- never auto-resolved.\n\n## Scope boundary (read first)\n\n- **Renders, never re-derives.** Every cell is a value copied from the source: a\n  per-stage `status` is shown EXACTLY as `readiness-status.yaml` records it. If the\n  file says a stage is `pass`, the viewer shows `pass`; it never decides `pass`\n  itself. Core Authority owns truth.\n- **Read-only.** It never edits a `readiness-status.yaml` or any per-item artifact,\n  never advances a stage, never writes a `pass`, never runs SQL, never opens a DB\n  connection, never runs `seshat check` \u002F `retail validate` as a new check.\n- **Infers no approval.** It RENDERS recorded `approvals[]` (each a named owner +\n  date already written by the approving human); it never establishes, fabricates,\n  or back-fills an approval, and never treats an unapproved gate as approved.\n- **Shows missing evidence AS MISSING.** When a stage's `evidence[]` is empty or a\n  referenced file is absent, it renders \"evidence missing\" \u002F \"referenced file not\n  found\" -- it never invents a reference and never lets a missing-evidence stage\n  read as complete.\n- **No fake confidence.** Readiness is the four explicit statuses + evidence +\n  blockers. The viewer MUST NOT emit a numeric health \u002F confidence \u002F percent-ready\n  score (hard rule #9). A score is OPTIONAL and DEFERRED; the viewer is not where\n  one appears.\n- **Generic.** No worked-example specifics (billing codes, segments, PII column\n  names, per-table grain keys). C086 \u002F retail_store_sales are filled instances\n  cited as references, never baked in (Principle VII).\n- ASCII only, UTF-8 no BOM. The stage spine is written Source Ready -> ... ->\n  Publish Ready (ASCII `->`); every dash is `--`.\n\n## Relationship to F012 (same inputs, different lens)\n\nF012 (Data Quality Control Room, shipped, skill\n`.claude\u002Fskills\u002Fretail-control-room\u002F`) is already a read-only cross-table roll-up\nof findings + blockers, worst-first, reading the SAME per-item\n`readiness-status.yaml`. F026 must be the DELTA, not a re-spec.\n\nBoth modules read the SAME Core Authority files; F026 introduces NO new input, NO\nnew measurement, and NO new pipeline. The difference is the lens:\n\n| Dimension | F012 Control Room (shipped) | F026 Readiness Viewer (this skill) |\n|-----------|-----------------------------|------------------------------------|\n| Organizing question | \"What is broken, how badly, worst-first?\" | \"Which of the 7 stages has each item reached, with what evidence and approvals?\" |\n| Stage rendering | `current_stage` + its one status, worst-first | a per-stage MATRIX across all 7 stages |\n| `evidence[]` rendering | summarized as MEASURED COUNTS | rendered as NAVIGABLE REFERENCES (path\u002Fline per stage) |\n| `approvals[]` rendering | not read by F012 | rendered as a chronological TIMELINE |\n| Primary axis | severity (findings + blockers, descending) | the stage spine (Source Ready .. Publish Ready) |\n| `next_action` | already surfaced | also surfaced (SHARED, NOT a delta) |\n\nThe three genuine deltas are exactly: (1) the per-stage status matrix across all\nseven stages, (2) `evidence[]` rendered as references rather than counts, and (3)\nthe `approvals[]` timeline (F012 does not read `approvals[]`). `next_action` is\nSHARED with F012 and is NOT a delta.\n\n**Chosen shape: (a).** This ships as a SEPARATE `readiness-viewer` skill that\nREUSES F012's existing read-fan-out over the per-item files (one aggregation, two\nlenses) -- not a re-implemented scan. The merge fallback (b) is explicit: if the\nthree deltas ever reduce so that the only durable difference is sort order +\ncolumn labels, this should NOT ship as a separate module -- it should fold into\nF012 as an optional stage-view section. Shape (a) holds because the stage matrix\nreveals WHERE in the seven-stage progression an item sits, evidence-as-reference\nlets a reviewer OPEN the backing file, and the approvals timeline answers \"who let\nthis advance, when\" -- each gives a reader something the control room cannot.\n\n## Renders, never re-derives (the evidence chain)\n\nEvery rendered element traces back to a recorded field -- a re-render, not a\nmeasurement. A rendered value with no traceable source is a defect.\n\n| Rendered element | Source field it copies VERBATIM |\n|------------------|---------------------------------|\n| each matrix cell (per-stage status) | `readiness-status.yaml` `stages.\u003Cstage>.status` |\n| the marked current stage | `readiness-status.yaml` `current_stage` |\n| the single next action | `readiness-status.yaml` `next_action` |\n| each evidence reference | `readiness-status.yaml` `stages.\u003Cstage>.evidence[]` (each entry as-recorded) |\n| each timeline approval | `readiness-status.yaml` `approvals[]` ({stage, owner, at}) |\n| which gates require an approval | `docs\u002Freadiness\u002F\u003Cstage>-ready.md` \"Required owner \u002F approval\" |\n\n## Run it -- produce the stage-centric view\n\nRender `templates\u002Freadiness-view.md` filled from the per-item evidence, reusing\nF012's read-fan-out for discovery.\n\n### 1. The seven-stage status matrix (the MVP)\n\nDiscover items exactly as F012 does: scan each `mappings\u002F\u003Citem>\u002F` directory for a\n`readiness-status.yaml` (ADR 0004 canonical location); emit one matrix row per\ndiscovered file. Add NO second discovery path and invent NO row for an item with no\nfile. For each item, emit a row x seven stage columns (Source Ready -> Mapping\nReady -> Silver Ready -> Gold Ready -> Semantic Model Ready -> Dashboard Ready ->\nPublish Ready); each cell is the `stages.\u003Cstage>.status` copied VERBATIM (one of\n`not_started` \u002F `blocked` \u002F `warning` \u002F `pass`). Mark `current_stage`. Show the\nsingle `next_action`. Never recompute or upgrade a status -- a stage the file\nrecords as `not_started` shows `not_started`.\n\n### 2. Evidence rendered as navigable references\n\nFor each stage, render every `evidence[]` entry as its committed reference, copied\nVERBATIM: if the entry carries a line\u002Fsection anchor, render it with that anchor;\nif it is a bare committed path, render the bare path. NEVER synthesize a line\nnumber or section anchor the source does not record (that is fabricated evidence).\nA stage with empty `evidence[]` renders \"evidence missing\" and NAMES the expected\nartifact; a `pass` stage with empty `evidence[]` renders \"evidence missing for a\npass stage\" as an explicit flag (a `pass` without evidence is surfaced, never\nhidden). An `evidence[]` entry whose referenced file is absent on disk renders the\nreference marked \"referenced file not found\" -- the entry is never dropped and\nnever replaced with an invented one.\n\n### 3. The approvals timeline\n\nRender `approvals[]` as a chronological timeline: each approval as {stage\u002Fgate,\nnamed owner, date} in date order, copied VERBATIM. Flag a `pass` gate \"approval not\nrecorded\" ONLY when BOTH conditions hold: (a) that stage's\n`docs\u002Freadiness\u002F\u003Cstage>-ready.md` \"Required owner \u002F approval\" field declares an\napprover IS required, AND (b) no matching `approvals[]` entry exists. Where the\nstage doc records NO required approver (e.g. a mechanical gate whose doc reads\n\"None -- mechanical ... No human approval is added at this stage\"), an empty\n`approvals[]` is NORMAL and MUST NOT be flagged. The viewer reads the requirement\nfrom the stage doc; it NEVER decides the requirement itself and NEVER infers,\nestablishes, or back-fills an approver (no-self-approval; Principle V).\n\n### 4. Surface conflicts (never resolve them)\n\nSurface, as explicit flags, never reconciled: `current_stage` disagreeing with the\nper-stage statuses (e.g. `current_stage: gold_ready` but Silver Ready recorded\n`blocked`); a `pass` stage with empty `evidence[]`; an approval that references a\nstage the matrix shows as `not_started`. The viewer is a lens, not an arbiter -- it\ndoes NOT resolve a conflict by picking one side.\n\n### 5. Traceability\n\nFor every rendered value, be able to name the exact committed source path (and\nline\u002Fsection where the source records it). If asked \"where does this come from\",\nanswer with the path -- not a recomputation.\n\n## No fake confidence (the guardrail)\n\nIf asked for \"one readiness score\", \"a percent-ready per item\", or \"a confidence\nnumber\", DECLINE: cite `docs\u002Freadiness\u002Freadiness-model.md` \"No fake confidence (the\nscoring rule)\" -- readiness is explicit status + evidence + blockers, not a\nconfidence score -- and return the four explicit statuses across the seven stages\ninstead. A stage matrix is exactly where a tidy invented score is tempting; it is\nforbidden (hard rule #9). Any future optional score is DEFERRED until scoring rules\nexist in the readiness model.\n\n## Honest-state rules (never invent, never silently resolve)\n\n| Situation | What the viewer does |\n|-----------|----------------------|\n| Zero items with a readiness file | render an empty matrix + a clear \"no items onboarded yet\" note; do not error, do not invent rows |\n| A `readiness-status.yaml` malformed \u002F partial | show that item \"readiness file incomplete: `\u003Cfile>`\" for the affected fields; do NOT guess the missing stage statuses or evidence (FR-009) |\n| `current_stage` disagrees with per-stage statuses | SURFACE the conflict as a flag; do NOT resolve it by picking one (Principle V) |\n| A stage is `pass` with empty `evidence[]` | surfaced as \"pass without evidence\", an explicit flag; never hidden |\n| An approval references a `not_started` stage | shown as a conflict flag; the stray approval is not reconciled or deleted |\n| A `pass` gate whose stage doc requires an approver, with no matching `approvals[]` entry | flagged \"approval not recorded\"; an approver is NEVER inferred |\n\n## Read-only proof\n\nThe skill modifies nothing: after a run, `git status` shows zero modified\n`mappings\u002F\u003Citem>\u002Freadiness-status.yaml` or per-item artifact, and zero\n`approvals[]` entries added by the viewer. It triggers no state-mutating\n`seshat check` \u002F `retail validate` run of its own.\n\n## See also\n\n- The output shape: `templates\u002Freadiness-view.md`; the usage + boundary doc:\n  `docs\u002Ftools\u002Freadiness-viewer.md`.\n- The headline overlap it is the delta of (F012): the skill\n  `.claude\u002Fskills\u002Fretail-control-room\u002FSKILL.md`, the template\n  `templates\u002Fdata-quality-control-room.md`.\n- The Core Authority input it renders: `templates\u002Freadiness-status.yaml`\n  (`current_stage`, per-stage `status`, `evidence[]`, `blocking_reasons[]`,\n  `approvals[]`, `next_action`); ADR 0004 (canonical\n  `mappings\u002F\u003Ctable>\u002Freadiness-status.yaml` location).\n- The module category + read-only contract: `docs\u002Farchitecture\u002Fproduct-modules.md`,\n  `docs\u002Farchitecture\u002Fcore-vs-modules-and-adapters.md`,\n  `templates\u002Fmodule-contract.md` (F024 Companion Tools Architecture,\n  `specs\u002F018-companion-tools-architecture\u002F`).\n- The model + no-fake-confidence rule: `docs\u002Freadiness\u002Freadiness-model.md`; the\n  stage sequence: `docs\u002Freadiness\u002Freadiness-pipeline.md`; the \"Required owner \u002F\n  approval\" field per stage: `docs\u002Freadiness\u002F\u003Cstage>-ready.md`.\n- The roadmap row + hard rules: `docs\u002Froadmap\u002Froadmap.md` (F026; rules #7\u002F#8\u002F#9);\n  Principles V, VII, VIII, IX. retail_store_sales is a cited filled\n  instance: `docs\u002Fworked-examples\u002Fretail-store-sales.md` (a filled worked\n  example under `docs\u002Fworked-examples\u002F`).\n\n## Orchestration\n\nWhen items are driven end-to-end, the `retail-orchestrate` conductor may invoke the\nviewer as the stage-progression READ after sequencing an item -- to see where the\nitem sits across all seven stages, what backs each gate, and who approved it. This\nskill reads state and reports; it advances no stage and clears no blocker. Moving a\nstage to `pass`, recording an approval, and clearing a blocker all remain Core\nAuthority actions by the named owner, never the viewer (Principle V;\nno-self-approval).\n","# readiness-viewer\n\nThe F012 control room answers \"what is broken, how badly, worst-first\". The\nReadiness Viewer answers a different question over the SAME inputs: \"which of the\nseven stages has each item reached, with what evidence, and who approved the gate\nthat let it advance\". It is a read-only stage-progression LENS over evidence that\nalready exists per item -- it introduces no new validator and no new gate\n(roadmap rule #8; Principle VIII). It renders, then STOPS.\n\n## Module contract (this skill IS a filled Product Module declaration)\n\nThis skill declares its authority category up front, per the F024 Companion Tools\nArchitecture contract (`templates\u002Fmodule-contract.md`).\n\n- **Authority category:** Product Module\n- **Capability level:** `read-only`  *(exactly one)*\n- **Product layer:** `4`  *(the functional axis -- see docs\u002Froadmap\u002Froadmap.md; orthogonal to category; matches the F012 control-room sibling)*\n- **Roadmap feature:** `F026`  **On-disk spec:** `specs\u002F020-readiness-viewer\u002F` *(roadmap F-number is authoritative when the two disagree)*\n- **Owner:** `the readiness \u002F data-quality lead`  *(a named role -- never \"the agent\")*\n- **Status:** `Authored`\n\n### What it does (one line)\n\n> Reads each item's `readiness-status.yaml` (Core Authority) and presents the\n> seven-stage status matrix, each stage's `evidence[]` as navigable references,\n> and the `approvals[]` timeline -- creating no truth.\n\n### Core Authority it READS\n\nIt reads these committed truth artifacts; it never writes them.\n\n- `mappings\u002F\u003Citem>\u002Freadiness-status.yaml` -- `current_stage`, per-stage `status`\n  (the four words), `evidence[]`, `blocking_reasons[]`, `approvals[]`, `next_action`.\n- the files each `evidence[]` entry references (to mark a reference \"referenced\n  file not found\" when absent -- it reads them only to check existence, never edits).\n- the \"Required owner \u002F approval\" field of each `docs\u002Freadiness\u002F\u003Cstage>-ready.md`\n  (to know which gates require an approval before flagging a missing one).\n\n### Derived evidence it WRITES\n\n- none (read-only). A `read-only` module writes NOTHING -- no cache, no report,\n  no per-item file.\n\n### Approved step it EXECUTES\n\n- none (read-only). It executes no step; it renders recorded state.\n\n### Forbidden operations (the matrix says NO)\n\n- MUST NOT create truth: no defining business meaning, no approving a metric\u002Fmapping.\n- MUST NOT grant approval or move a readiness stage to `pass` (named-human \u002F Core\n  Authority only).\n- MUST NOT connect to a DB or external service, and MUST NOT publish a Power BI\n  artifact (those are Execution Adapter capabilities).\n- MUST NOT emit a numeric \u002F maturity \u002F confidence score (hard rule #9).\n- As a `read-only` module it additionally MUST NOT write any derived evidence or\n  execute any step.\n\n### How it handles a missing input\n\nWhen a required Core Authority input is absent, the viewer SURFACES it as a flag\nand renders the gap as a gap -- it never fabricates the input, self-approves, or\nreads a missing-evidence stage as complete (Principle V; stop-and-ask).\n\n- missing `readiness-status.yaml` -> the item's row is \"no readiness file\"\n  (FR-009); a stage with empty `evidence[]` -> \"evidence missing\"; a `pass` gate\n  whose required approval is absent -> \"approval not recorded\" -- never auto-resolved.\n\n## Scope boundary (read first)\n\n- **Renders, never re-derives.** Every cell is a value copied from the source: a\n  per-stage `status` is shown EXACTLY as `readiness-status.yaml` records it. If the\n  file says a stage is `pass`, the viewer shows `pass`; it never decides `pass`\n  itself. Core Authority owns truth.\n- **Read-only.** It never edits a `readiness-status.yaml` or any per-item artifact,\n  never advances a stage, never writes a `pass`, never runs SQL, never opens a DB\n  connection, never runs `seshat check` \u002F `retail validate` as a new check.\n- **Infers no approval.** It RENDERS recorded `approvals[]` (each a named owner +\n  date already written by the approving human); it never establishes, fabricates,\n  or back-fills an approval, and never treats an unapproved gate as approved.\n- **Shows missing evidence AS MISSING.** When a stage's `evidence[]` is empty or a\n  referenced file is absent, it renders \"evidence missing\" \u002F \"referenced file not\n  found\" -- it never invents a reference and never lets a missing-evidence stage\n  read as complete.\n- **No fake confidence.** Readiness is the four explicit statuses + evidence +\n  blockers. The viewer MUST NOT emit a numeric health \u002F confidence \u002F percent-ready\n  score (hard rule #9). A score is OPTIONAL and DEFERRED; the viewer is not where\n  one appears.\n- **Generic.** No worked-example specifics (billing codes, segments, PII column\n  names, per-table grain keys). C086 \u002F retail_store_sales are filled instances\n  cited as references, never baked in (Principle VII).\n- ASCII only, UTF-8 no BOM. The stage spine is written Source Ready -> ... ->\n  Publish Ready (ASCII `->`); every dash is `--`.\n\n## Relationship to F012 (same inputs, different lens)\n\nF012 (Data Quality Control Room, shipped, skill\n`.claude\u002Fskills\u002Fretail-control-room\u002F`) is already a read-only cross-table roll-up\nof findings + blockers, worst-first, reading the SAME per-item\n`readiness-status.yaml`. F026 must be the DELTA, not a re-spec.\n\nBoth modules read the SAME Core Authority files; F026 introduces NO new input, NO\nnew measurement, and NO new pipeline. The difference is the lens:\n\n| Dimension | F012 Control Room (shipped) | F026 Readiness Viewer (this skill) |\n|-----------|-----------------------------|------------------------------------|\n| Organizing question | \"What is broken, how badly, worst-first?\" | \"Which of the 7 stages has each item reached, with what evidence and approvals?\" |\n| Stage rendering | `current_stage` + its one status, worst-first | a per-stage MATRIX across all 7 stages |\n| `evidence[]` rendering | summarized as MEASURED COUNTS | rendered as NAVIGABLE REFERENCES (path\u002Fline per stage) |\n| `approvals[]` rendering | not read by F012 | rendered as a chronological TIMELINE |\n| Primary axis | severity (findings + blockers, descending) | the stage spine (Source Ready .. Publish Ready) |\n| `next_action` | already surfaced | also surfaced (SHARED, NOT a delta) |\n\nThe three genuine deltas are exactly: (1) the per-stage status matrix across all\nseven stages, (2) `evidence[]` rendered as references rather than counts, and (3)\nthe `approvals[]` timeline (F012 does not read `approvals[]`). `next_action` is\nSHARED with F012 and is NOT a delta.\n\n**Chosen shape: (a).** This ships as a SEPARATE `readiness-viewer` skill that\nREUSES F012's existing read-fan-out over the per-item files (one aggregation, two\nlenses) -- not a re-implemented scan. The merge fallback (b) is explicit: if the\nthree deltas ever reduce so that the only durable difference is sort order +\ncolumn labels, this should NOT ship as a separate module -- it should fold into\nF012 as an optional stage-view section. Shape (a) holds because the stage matrix\nreveals WHERE in the seven-stage progression an item sits, evidence-as-reference\nlets a reviewer OPEN the backing file, and the approvals timeline answers \"who let\nthis advance, when\" -- each gives a reader something the control room cannot.\n\n## Renders, never re-derives (the evidence chain)\n\nEvery rendered element traces back to a recorded field -- a re-render, not a\nmeasurement. A rendered value with no traceable source is a defect.\n\n| Rendered element | Source field it copies VERBATIM |\n|------------------|---------------------------------|\n| each matrix cell (per-stage status) | `readiness-status.yaml` `stages.\u003Cstage>.status` |\n| the marked current stage | `readiness-status.yaml` `current_stage` |\n| the single next action | `readiness-status.yaml` `next_action` |\n| each evidence reference | `readiness-status.yaml` `stages.\u003Cstage>.evidence[]` (each entry as-recorded) |\n| each timeline approval | `readiness-status.yaml` `approvals[]` ({stage, owner, at}) |\n| which gates require an approval | `docs\u002Freadiness\u002F\u003Cstage>-ready.md` \"Required owner \u002F approval\" |\n\n## Run it -- produce the stage-centric view\n\nRender `templates\u002Freadiness-view.md` filled from the per-item evidence, reusing\nF012's read-fan-out for discovery.\n\n### 1. The seven-stage status matrix (the MVP)\n\nDiscover items exactly as F012 does: scan each `mappings\u002F\u003Citem>\u002F` directory for a\n`readiness-status.yaml` (ADR 0004 canonical location); emit one matrix row per\ndiscovered file. Add NO second discovery path and invent NO row for an item with no\nfile. For each item, emit a row x seven stage columns (Source Ready -> Mapping\nReady -> Silver Ready -> Gold Ready -> Semantic Model Ready -> Dashboard Ready ->\nPublish Ready); each cell is the `stages.\u003Cstage>.status` copied VERBATIM (one of\n`not_started` \u002F `blocked` \u002F `warning` \u002F `pass`). Mark `current_stage`. Show the\nsingle `next_action`. Never recompute or upgrade a status -- a stage the file\nrecords as `not_started` shows `not_started`.\n\n### 2. Evidence rendered as navigable references\n\nFor each stage, render every `evidence[]` entry as its committed reference, copied\nVERBATIM: if the entry carries a line\u002Fsection anchor, render it with that anchor;\nif it is a bare committed path, render the bare path. NEVER synthesize a line\nnumber or section anchor the source does not record (that is fabricated evidence).\nA stage with empty `evidence[]` renders \"evidence missing\" and NAMES the expected\nartifact; a `pass` stage with empty `evidence[]` renders \"evidence missing for a\npass stage\" as an explicit flag (a `pass` without evidence is surfaced, never\nhidden). An `evidence[]` entry whose referenced file is absent on disk renders the\nreference marked \"referenced file not found\" -- the entry is never dropped and\nnever replaced with an invented one.\n\n### 3. The approvals timeline\n\nRender `approvals[]` as a chronological timeline: each approval as {stage\u002Fgate,\nnamed owner, date} in date order, copied VERBATIM. Flag a `pass` gate \"approval not\nrecorded\" ONLY when BOTH conditions hold: (a) that stage's\n`docs\u002Freadiness\u002F\u003Cstage>-ready.md` \"Required owner \u002F approval\" field declares an\napprover IS required, AND (b) no matching `approvals[]` entry exists. Where the\nstage doc records NO required approver (e.g. a mechanical gate whose doc reads\n\"None -- mechanical ... No human approval is added at this stage\"), an empty\n`approvals[]` is NORMAL and MUST NOT be flagged. The viewer reads the requirement\nfrom the stage doc; it NEVER decides the requirement itself and NEVER infers,\nestablishes, or back-fills an approver (no-self-approval; Principle V).\n\n### 4. Surface conflicts (never resolve them)\n\nSurface, as explicit flags, never reconciled: `current_stage` disagreeing with the\nper-stage statuses (e.g. `current_stage: gold_ready` but Silver Ready recorded\n`blocked`); a `pass` stage with empty `evidence[]`; an approval that references a\nstage the matrix shows as `not_started`. The viewer is a lens, not an arbiter -- it\ndoes NOT resolve a conflict by picking one side.\n\n### 5. Traceability\n\nFor every rendered value, be able to name the exact committed source path (and\nline\u002Fsection where the source records it). If asked \"where does this come from\",\nanswer with the path -- not a recomputation.\n\n## No fake confidence (the guardrail)\n\nIf asked for \"one readiness score\", \"a percent-ready per item\", or \"a confidence\nnumber\", DECLINE: cite `docs\u002Freadiness\u002Freadiness-model.md` \"No fake confidence (the\nscoring rule)\" -- readiness is explicit status + evidence + blockers, not a\nconfidence score -- and return the four explicit statuses across the seven stages\ninstead. A stage matrix is exactly where a tidy invented score is tempting; it is\nforbidden (hard rule #9). Any future optional score is DEFERRED until scoring rules\nexist in the readiness model.\n\n## Honest-state rules (never invent, never silently resolve)\n\n| Situation | What the viewer does |\n|-----------|----------------------|\n| Zero items with a readiness file | render an empty matrix + a clear \"no items onboarded yet\" note; do not error, do not invent rows |\n| A `readiness-status.yaml` malformed \u002F partial | show that item \"readiness file incomplete: `\u003Cfile>`\" for the affected fields; do NOT guess the missing stage statuses or evidence (FR-009) |\n| `current_stage` disagrees with per-stage statuses | SURFACE the conflict as a flag; do NOT resolve it by picking one (Principle V) |\n| A stage is `pass` with empty `evidence[]` | surfaced as \"pass without evidence\", an explicit flag; never hidden |\n| An approval references a `not_started` stage | shown as a conflict flag; the stray approval is not reconciled or deleted |\n| A `pass` gate whose stage doc requires an approver, with no matching `approvals[]` entry | flagged \"approval not recorded\"; an approver is NEVER inferred |\n\n## Read-only proof\n\nThe skill modifies nothing: after a run, `git status` shows zero modified\n`mappings\u002F\u003Citem>\u002Freadiness-status.yaml` or per-item artifact, and zero\n`approvals[]` entries added by the viewer. It triggers no state-mutating\n`seshat check` \u002F `retail validate` run of its own.\n\n## See also\n\n- The output shape: `templates\u002Freadiness-view.md`; the usage + boundary doc:\n  `docs\u002Ftools\u002Freadiness-viewer.md`.\n- The headline overlap it is the delta of (F012): the skill\n  `.claude\u002Fskills\u002Fretail-control-room\u002FSKILL.md`, the template\n  `templates\u002Fdata-quality-control-room.md`.\n- The Core Authority input it renders: `templates\u002Freadiness-status.yaml`\n  (`current_stage`, per-stage `status`, `evidence[]`, `blocking_reasons[]`,\n  `approvals[]`, `next_action`); ADR 0004 (canonical\n  `mappings\u002F\u003Ctable>\u002Freadiness-status.yaml` location).\n- The module category + read-only contract: `docs\u002Farchitecture\u002Fproduct-modules.md`,\n  `docs\u002Farchitecture\u002Fcore-vs-modules-and-adapters.md`,\n  `templates\u002Fmodule-contract.md` (F024 Companion Tools Architecture,\n  `specs\u002F018-companion-tools-architecture\u002F`).\n- The model + no-fake-confidence rule: `docs\u002Freadiness\u002Freadiness-model.md`; the\n  stage sequence: `docs\u002Freadiness\u002Freadiness-pipeline.md`; the \"Required owner \u002F\n  approval\" field per stage: `docs\u002Freadiness\u002F\u003Cstage>-ready.md`.\n- The roadmap row + hard rules: `docs\u002Froadmap\u002Froadmap.md` (F026; rules #7\u002F#8\u002F#9);\n  Principles V, VII, VIII, IX. retail_store_sales is a cited filled\n  instance: `docs\u002Fworked-examples\u002Fretail-store-sales.md` (a filled worked\n  example under `docs\u002Fworked-examples\u002F`).\n\n## Orchestration\n\nWhen items are driven end-to-end, the `retail-orchestrate` conductor may invoke the\nviewer as the stage-progression READ after sequencing an item -- to see where the\nitem sits across all seven stages, what backs each gate, and who approved it. This\nskill reads state and reports; it advances no stage and clears no blocker. Moving a\nstage to `pass`, recording an approval, and clearing a blocker all remain Core\nAuthority actions by the named owner, never the viewer (Principle V;\nno-self-approval).\n",{"name":5,"description":7},"main","6266e304556a72b75d951b9433fd833481c61233",".claude\u002Fskills\u002Freadiness-viewer",0,"https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI","https:\u002F\u002Fpypi.org\u002Fproject\u002Fseshat-bi\u002F","https:\u002F\u002Fgithub.com\u002FKemetra","2026-11-11 21:44:25",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add Kemetra\u002FSeshat-BI --skill readiness-viewer",{"tool":37,"command":38},"bunx","bunx skills add Kemetra\u002FSeshat-BI --skill readiness-viewer",{"tool":40,"command":41},"pnpm","pnpm dlx skills add Kemetra\u002FSeshat-BI --skill readiness-viewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freadiness-viewer\u002FSKILL.md",true,[],[46,53,58,64,69,76],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":18},"01M77JWCTJ88JWPDD25WZ2NEY8","fake-skill","A fixture skill with declaring frontmatter, used as positive shipped evidence.","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Funlisted\u002F.claude\u002Fskills\u002Ffake-skill\u002FSKILL.md",[],[],{"skillNo":54,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":18},"01M77JWA0BTG4JB2HR52Q99216","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Forphan\u002F.claude\u002Fskills\u002Ffake-skill\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":18},"01M77JW6VE59XEFHWBTNDYAS2Q","bare-skill-no-frontmatter","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Forphan\u002F.claude\u002Fskills\u002Fbare-skill-no-frontmatter\u002FSKILL.md",[],[],{"skillNo":65,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":18},"01M77JW4TD1FNFSBNP5C0WXAA5","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Ftests\u002Funit\u002Ffixtures\u002Fcapability_inventory\u002Fgood\u002F.claude\u002Fskills\u002Ffake-skill\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":18},"01M77JVWCVE3WZ82ZNFCSFVDCP","retail-kpi-knowledge","Retail KPI \u002F metric-contract reasoning layer for BI agents in the Seshat BI project. Use when an agent must reason about the BUSINESS MEANING of a retail KPI before any implementation — defining a KPI in business terms, classifying additivity (fully\u002Fsemi\u002Fnon-additive), identifying grain, listing required source fields, resolving ambiguity (gross vs net, VAT, returns, cost method, same-store), choosing an MVP KPI pack, reviewing a metric contract for completeness, or preparing a clean handoff to an implementation layer. Also use it to classify KPI sufficiency or prepare an owner policy decision packet. This is a meaning\u002Fdefinition + review layer, not an executor: it does not write DAX\u002FSQL\u002FPython, grant readiness, approve policy, or design dashboards. See INDEX.md for live\u002Fplanned routes; registry.yaml is the authoritative machine-readable inventory.","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Fskills\u002Fretail-kpi-knowledge\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":18},"01M77JVNDM1NGYGSCPTBW9ZCF5","bi-sql-knowledge","SQL reasoning, validation, reconciliation, transformation, diagnostics, and anti-pattern knowledge layer for Seshat BI agents. Use when a task involves reasoning about source SQL: source profiling, table grain, keys & uniqueness, joins & fan-out amplification, aggregation correctness, COUNT\u002FNULL semantics, deduplication, validation queries, reconciliation queries, silver\u002Fgold transformation logic, window\u002Fdate-time analytics, SQL anti-patterns, or basic SQL performance reasoning, or interpretation of a supplied sanitized PostgreSQL JSON execution plan. The SQL counterpart to bi-dax-knowledge. It is a thinking & validation layer, not a database executor, runtime validator, dbt\u002FDagster project, or automatic tuning service.","https:\u002F\u002Fgithub.com\u002FKemetra\u002FSeshat-BI\u002Fblob\u002Fmain\u002Fskills\u002Fbi-sql-knowledge\u002FSKILL.md",[],[]]