Update to Clara

{
  "description": "Use when Clara or Codex generates, revises, or audits a clean PPTX/deck and needs a fully automatic readable sidecar that maps each slide claim to its basis and checks whether current deck text has drifted from the generation-time claim snapshot. Use for AI-generated decks where visible citations, claim IDs, reviewer attestations, hashes, thumbnails, and HTML are explicitly not wanted.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 279
    },
    {
      "relative_path": "scripts/render_claim_basis_map.py",
      "size_in_bytes": 37658
    }
  ],
  "name": "claim-basis-map",
  "skill_md_contents": "---\nname: claim-basis-map\ndescription: \"Use when Clara or Codex generates, revises, or audits a clean PPTX/deck and needs a fully automatic readable sidecar that maps each slide claim to its basis and checks whether current deck text has drifted from the generation-time claim snapshot. Use for AI-generated decks where visible citations, claim IDs, reviewer attestations, hashes, thumbnails, and HTML are explicitly not wanted.\"\n---\n\n<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->\nOnboarding is optional. Continue ordinary professional work immediately,\nincluding direct specialist invocation, without checking or completing a local\nonboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,\nor unavailable voice/window controls, must never block ordinary work. Do not\nautomatically start, resume or repeatedly offer onboarding.\nOnly for a user-requested tutorial or a native teaching handoff, read\n`../clara/references/local-onboarding.md`. A verified paired lesson worker\nexecutes only its bound lesson and token; never bypass tutorial validation.\nTutorial profiles, progress, examples and feedback remain local; never send a\nchange request, stamp a tutorial receipt or call hosted interviews for a tutorial.\nCurrent user requests take precedence over saved preferences.\n<!-- CLARA_OPENAI_ONBOARDING_END -->\n\n# Claim Basis Map\n\nAfter substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.\n\nCreate a clean companion file for a deck:\n\n```text\ndeck.pptx\ndeck.claims.json\ndeck.claims.md\n```\n\nThe PPTX stays visually clean. Do not add visible claim IDs, footnotes,\nspeaker-note dumps, thumbnails, HTML, reviewers, certifications, or file hashes.\nInternal `claim_key` values are allowed in JSON when they make cross-slide\nreferences more robust, but never show them in the PPTX.\n\n## Core Rule\n\nTrack claim basis during deck generation whenever possible. Do not reconstruct\nthe \"source of origin\" after the deck is complete unless the user explicitly\naccepts that the result is only matched support.\n\nFor each slide, emit `deck.claims.json` as the generation-time record. Treat the\nexact normalized claim text in that JSON as the snapshot for later edit checks.\nThen render `deck.claims.md` deterministically from that record with:\n\n```bash\npython plugins/clara/skills/claim-basis-map/scripts/render_claim_basis_map.py \\\n  deck.claims.json \\\n  --output deck.claims.md\n```\n\nThe command also writes `deck.claims.audit.json`. Its authoritative\n`source: clara_claim_basis_map_audit` and `result` fields are what the advisory\ndeliverable validator consumes. An ungrounded claim, broken reference, or\ncurrent-deck drift makes the command exit non-zero.\n\nThis is not tamper-proofing and does not certify the PPTX. It is a text-drift\ncheck: if the deck changes later, rerun the renderer against the current PPTX.\nChanged, missing, untracked, or broken-reference claims fail closed and are\nsurfaced as requiring refresh.\n\n## JSON Contract\n\nUse this minimal shape:\n\n```json\n{\n  \"deck\": \"deck.pptx\",\n  \"slides\": [\n    {\n      \"slide_number\": 4,\n      \"slide_title\": \"Market direction\",\n      \"claims\": [\n        {\n          \"claim\": \"The market grew 12% in 2025.\",\n          \"source_refs\": [\n            {\n              \"title\": \"Example Market Research Category Report 2025\",\n              \"locator\": \"p. 14, table 2\",\n              \"url\": \"https://example.com/report\"\n            }\n          ]\n        },\n        {\n          \"claim\": \"Premium SKUs contributed 62% of growth.\",\n          \"calculation_ref\": {\n            \"inputs\": [\"sell-out extract rows 114-189\"],\n            \"method\": \"premium growth / total category growth\"\n          }\n        },\n        {\n          \"claim\": \"Premiumization is likely to remain the main growth vector.\",\n          \"claim_key\": \"claim-4\",\n          \"advisory_claim_id\": \"claim-4\",\n          \"evidence_receipt_ids\": [\"ev-category-growth\", \"ev-sell-out-run\"],\n          \"reasoning_inputs\": [\n            {\n              \"label\": \"Example Market Research category growth table\",\n              \"locator\": \"p. 14\"\n            },\n            {\n              \"label\": \"Company sell-out extract\",\n              \"locator\": \"rows 114-189\"\n            }\n          ],\n          \"reasoning\": \"Premium formats show stronger growth and higher launch density.\"\n        },\n        {\n          \"claim\": \"Retailers will increasingly favor discovery-led merchandising.\"\n        }\n      ]\n    },\n    {\n      \"slide_number\": 6,\n      \"slide_title\": \"Retail implications\",\n      \"claims\": [\n        {\n          \"claim\": \"Retailers will prioritize premium discovery space.\",\n          \"claim_refs\": [\n            {\n              \"slide_number\": 4,\n              \"claim\": \"Premiumization is likely to remain the main growth vector.\"\n            }\n          ],\n          \"reasoning\": \"Retailers typically allocate discovery space toward the growth vector they need to defend.\"\n        }\n      ]\n    }\n  ]\n}\n```\n\nWhen the deck is generated inside a Clara case with\n`advisory_claim_register.json`, use the existing upstream claim ID as\n`claim_key` and `advisory_claim_id` when the PowerPoint safe-ID contract allows\nit, and carry the linked `evidence_receipt_ids`. After generation, add the exact\nslide appearance to the shared claim register. These cross-workflow IDs do not\nreplace this workflow's `source_refs`, `calculation_ref`, `claim_refs`,\nreasoning, drift checks, or PPTX verification.\n\nWhen the deck generator can control PPTX shape metadata, set the invisible\nPowerPoint shape name for the textbox that carries a claim to:\n\n```text\nclara-claim:<claim_key>\n```\n\nThis is not visible on the slide and is not a hash. It simply lets the check\nmode distinguish \"same claim edited in place\" from \"old claim deleted or moved\"\nmore accurately. If hidden shape names are unavailable, the check mode falls\nback to exact normalized text matching across slides.\n\n## Deterministic Classification\n\nClassify each claim from fields only:\n\n```text\nif source_refs is non-empty -> source-backed\nelif calculation_ref is non-empty -> calculated\nelif claim_refs is non-empty -> claim-linked\nelif reasoning_inputs is non-empty -> reasoned\nelif assumption_basis is non-empty -> assumption\nelse -> ungrounded\n```\n\nThis deterministic rule is justified because it validates and renders explicit\ngeneration metadata. It does not decide whether a source semantically supports a\nclaim, which remains model-led during generation.\n\nFail closed: when a claim lacks a captured basis, surface it as ungrounded.\nReasoned claims are grounded only when `reasoning_inputs` are present.\n\n`claim_refs` may point to a prior slide claim by exact `slide_number` + `claim`\ntext, or by an internal `claim_key`. Prefer prior-slide references so the claim\ngraph is acyclic and deterministic. If a claim points to a missing, future, or\nungrounded prior claim, surface that dependency in the top `Ungrounded Claims`\nsection. Do not invent an upstream source to make the dependency look grounded.\n\n## Current Deck Check\n\nTo check a PPTX after normal editing, compare the current deck text layer with\nthe generation-time JSON:\n\n```bash\npython plugins/clara/skills/claim-basis-map/scripts/render_claim_basis_map.py \\\n  deck.claims.json \\\n  --current-pptx deck.pptx \\\n  --case-dir <case-dir> \\\n  --evidence-register <case-dir>/advisory_evidence_register.json \\\n  --claim-register <case-dir>/advisory_claim_register.json \\\n  --output deck.claims.md\n```\n\nWith `--case-dir`, the renderer checks shared claim/evidence IDs and records\neach advisory claim's exact PPTX hash and slide appearance. It never infers or\ncreates a semantic claim from slide text.\n\nUse `--snapshot-output current-deck.snapshot.json` when a local debug snapshot\nis useful. Use `--current-claims-json` only when another deck builder has\nalready extracted the current visible claims/text.\n\nCheck statuses:\n\n- `unchanged`: exact claim text is still on the same slide.\n- `moved`: exact claim text appears on a different slide.\n- `edited`: a hidden `clara-claim:<claim_key>` shape still exists but its text\n  no longer contains the original claim.\n- `missing-or-edited`: the original claim text is not found and no hidden key\n  identifies an edited shape.\n- `untracked-current-text`: current deck text looks like a claim but was not in\n  the generation-time snapshot.\n- `reference-broken`: a claim depends on another claim whose current deck text\n  drifted.\n\nDo not use deterministic code to decide whether a new or edited claim is\nsemantically supported. Re-run the model-led generation/matching step for those\nclaims, then emit an updated `deck.claims.json`.\n\nRead every item in the audit's `current_text_inventory`, including short\nheadlines, numeric labels and footnotes. The untracked-text heuristic omits\nsome of these; an empty issue list is not complete materiality review. Compare\nthe inventory with every rendered slide and inspect chart/image meaning\nseparately. Record material claims through model-led review even when no\nheuristic flagged them. The inventory's coverage metadata does not attest that\nthis review occurred.\n\n## Markdown Output\n\nThe readable file must start with `Ungrounded Claims` and then list slides:\n\n```md\n# Claim Basis Map\n\nDeck: deck.pptx\n\n## Ungrounded Claims\n\n- Slide 4: \"Retailers will increasingly favor discovery-led merchandising.\"\n  Basis: no captured source, calculation, reasoning input, or assumption\n\n## Slide 4 - Market direction\n\n### Source-backed\n- \"The market grew 12% in 2025.\"\n  Source: Example Market Research Category Report 2025, p. 14, table 2, https://example.com/report\n\n### Calculated\n- \"Premium SKUs contributed 62% of growth.\"\n  Inputs: sell-out extract rows 114-189\n  Method: premium growth / total category growth\n\n### Reasoned\n- \"Premiumization is likely to remain the main growth vector.\"\n  Inputs: Example Market Research category growth table, p. 14; Company sell-out extract, rows 114-189\n  Reasoning: Premium formats show stronger growth and higher launch density.\n\n### Ungrounded\n- \"Retailers will increasingly favor discovery-led merchandising.\"\n  Basis: no captured source, calculation, reasoning input, or assumption\n\n## Slide 6 - Retail implications\n\n### Claim-Linked\n- \"Retailers will prioritize premium discovery space.\"\n  Based on claim: Slide 4 - \"Premiumization is likely to remain the main growth vector.\"\n  Reasoning: Retailers typically allocate discovery space toward the growth vector they need to defend.\n```\n\n## Existing Decks\n\nFor an existing PPTX with no generation record, be explicit that the sidecar is\nnot the original source map. Produce a `deck.claims.json` where each basis is\nonly captured if the support was actually found or inferred during the current\nrun. Leave unsupported items ungrounded rather than inventing a source.\n\nWhen an existing deck later gets a real generation-time snapshot, prefer that\nsnapshot over any reconstructed map. The reconstructed map is matched support;\nthe generated map is the authority for drift checks.\n\n## Codex-Native Run UX\n\nUse a short checklist for the run: identify the deck, locate or create\n`deck.claims.json`, decide whether this is generation-time capture or current\nPPTX check mode, run deterministic rendering, and report `deck.claims.md`.\n\nBefore running the script, show a compact Run Intake table with the PPTX path,\nclaims JSON path, output Markdown path, whether this is generation-time capture\nor existing-deck matching, whether current-deck check mode is enabled, and\nwhether cross-slide `claim_refs` are present.\n\nUse a Decision Table only for unresolved material choices, such as whether the\nuser wants matched support for an existing deck. Default output policy: create\n`deck.claims.json` and `deck.claims.md`; these are not choices to propose when\nthe user asked for the normal claim-basis sidecar.\n\nBefore write-heavy or externally visible work, use an execution checkpoint that\nnames the command, input file, output file, and expected artifacts. Never edit\ngenerated ZIPs by hand; plugin release artifacts are rebuilt from source.\n\nEnd with an Artifact Card listing generated paths, ungrounded claim count,\nunresolved claim-reference count, current-deck drift issue count when checked,\nand any failed validation. Create\n`codex_run_review.md` only when the run needs a local note about blocked\ninputs, schema gaps, or repeated manual cleanup.\n\n## Boundaries\n\n- Do not put source labels on the slide unless the user asks.\n- Do not use speaker notes as the primary source map.\n- Do not create HTML or thumbnails unless the user asks later.\n- Do not add a reviewer, certification, signature, or hash.\n- Do not let deterministic code make semantic support decisions.\n"
}