Update to get-fable

{
  "description": "Design and author structured technical proposals, responsive artifacts, architecture diagrams, Mermaid charts, and interactive components. Use when creating standalone markdown reports, architectural specifications, Mermaid diagrams, or interactive artifact widgets — even if the user does not explicitly say \"fable-artifact\" (e.g. \"create an artifact\", \"draw an architecture diagram\", \"write a technical proposal\", \"generate a mermaid flowchart\"). Do NOT use for quick one-line conversational answers.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 391
    },
    {
      "relative_path": "evals/scenarios.json",
      "size_in_bytes": 3874
    },
    {
      "relative_path": "examples/system-architecture-diagram.md",
      "size_in_bytes": 242
    },
    {
      "relative_path": "references/artifact-composition-guide.md",
      "size_in_bytes": 2999
    },
    {
      "relative_path": "references/source-grounded-artifact-design.md",
      "size_in_bytes": 2694
    },
    {
      "relative_path": "skill.package.json",
      "size_in_bytes": 470
    },
    {
      "relative_path": "templates/technical-proposal.template.md",
      "size_in_bytes": 1058
    }
  ],
  "name": "fable-artifact",
  "skill_md_contents": "---\nname: fable-artifact\ndescription: \"Design and author structured technical proposals, responsive artifacts, architecture diagrams, Mermaid charts, and interactive components. Use when creating standalone markdown reports, architectural specifications, Mermaid diagrams, or interactive artifact widgets — even if the user does not explicitly say \\\"fable-artifact\\\" (e.g. \\\"create an artifact\\\", \\\"draw an architecture diagram\\\", \\\"write a technical proposal\\\", \\\"generate a mermaid flowchart\\\"). Do NOT use for quick one-line conversational answers.\"\nversion: 1.3.0\npack: system\ninputs:\n  - artifact_spec\nrequires:\n  - design_requirements\nproduces:\n  - artifact_document\n  - interactive_ui\ngates:\n  - hierarchy_clear\n  - theme_adaptive\nfallback: fable-plan\nmutatesWorkspace: true\nparallelSafe: true\nneural_links:\n  precursors:\n    - fable-dataviz\n    - fable-plan\n  continuations:\n    - fable-verify\n    - fable-review\n  lateral_peers:\n    - fable-dataviz\n  recovery: fable-recover\n---\n\n# Fable Artifact\n\nTurn requirements and evidence into a standalone artifact whose content, structure, diagrams, links, and rendered output can all be checked independently.\n\n## Mission\nAn artifact is not successful because the Markdown parses or the diagram looks polished. It must communicate the right claims to the right audience, preserve source truth, make assumptions visible, and render in the medium the user will actually consume.\n\n## Activate When\n- producing RFCs, architecture proposals, technical reports, runbooks, decision records, diagrams, or rich standalone documentation;\n- packaging analysis/results into a durable document;\n- creating a diagram or interactive explanatory artifact from established requirements/evidence.\n\n## Do Not Activate When\n- a one-paragraph answer is sufficient;\n- application logic itself needs modification (`fable-execute`);\n- the main work is numerical chart selection (`fable-dataviz`);\n- facts required by the artifact have not been researched/discovered yet.\n\n## Artifact Classification\n| Artifact | Primary contract |\n| --- | --- |\n| RFC/proposal | decision, alternatives, trade-offs, acceptance/rollout |\n| Architecture doc | boundaries, data/control flow, invariants, deployment |\n| Runbook | trigger, prerequisites, executable steps, rollback/escalation |\n| Incident/report | timeline/evidence/impact without invented causality |\n| Decision record | context, decision, alternatives, consequences |\n| Diagram | semantic topology/sequence/state, not decorative boxes |\n| Interactive explainer | accessible interaction + deterministic content/source |\n\n## Protocol\n### Stage 1 — Define audience and job\nState who will use the artifact and what decision/action it must support. One artifact can contain multiple sections, but it should have one primary communication job.\n\n### Stage 2 — Build a claim/source map\nBefore writing polished prose, identify:\n- measured/source-backed facts;\n- design decisions;\n- assumptions/inferences;\n- unresolved items;\n- data/visual sources;\n- claims that need citations/links.\n\nDo not invent examples, metrics, architecture components, test results, or citations to make the document feel complete.\n\n### Stage 3 — Choose structure from artifact type\nExamples:\n- RFC: context → goals/non-goals → evidence → options → decision → design → risks → rollout/rollback → acceptance;\n- runbook: symptom/trigger → safety prerequisites → diagnosis → action → verification → rollback/escalation;\n- architecture: scope → context → components/boundaries → flows → data/state → failure/security → deployment/operations → decisions.\n\nAvoid generic template sections that do not serve the document's job.\n\n### Stage 4 — Design diagrams semantically\nEach node/edge should represent a real component, state, dependency, event, or data/control flow. Label direction/meaning where ambiguity exists.\n\nFor Mermaid or other text diagrams:\n- validate syntax;\n- quote/escape labels safely;\n- avoid giant unreadable graphs;\n- split views by question (context, container, sequence, state) when one diagram becomes overloaded.\n\n### Stage 5 — Write for scanning and decision quality\nUse hierarchy, short sections, tables only when comparison benefits, callouts sparingly, and explicit `Decision`, `Risk`, `Unknown`, `Evidence` language where useful.\n\nDo not turn every sentence into bullets or bury the main decision below background detail.\n\n### Stage 6 — Validate internal consistency\nCross-check:\n- terms/names/versions match throughout;\n- diagram matches prose;\n- examples match actual API/schema;\n- links/anchors exist;\n- recommendations follow cited evidence;\n- no section contradicts the accepted design.\n\n### Stage 7 — Render in the target medium\nA source file is not the final artifact when rendering matters. Preview/render Markdown/Mermaid/HTML/PDF/other target as appropriate and inspect for clipping, broken diagrams, overflow, missing assets, unreadable typography, or inaccessible interactions.\n\n### Stage 8 — Run truth and usability review\nAsk:\n- can the audience locate the primary decision/action quickly?\n- which statements are fact vs proposal vs inference?\n- are any claims unsupported?\n- would a diagram imply a relationship that does not exist?\n- can a future reader execute/maintain the artifact without chat context?\n\n## Decision Rules\n- Prefer explicit `unknown/not checked` to filling gaps with plausible content.\n- A diagram should answer a question; split it when one view mixes topology, sequence, deployment, and ownership beyond readability.\n- Use links/citations for external/current claims where traceability matters; do not fabricate sources.\n- Generated charts/tables inherit their data provenance from DataViz/research packets.\n- If artifact changes as the design changes, reconcile every diagram/example/decision reference before completion.\n- Interactive artifacts need keyboard/accessibility/fallback behavior appropriate to their use; visual novelty is not a substitute for communication.\n- Keep implementation details out of an executive/decision artifact unless they materially change the decision.\n- Use the repository/designated artifact destination; do not litter roots/temp paths.\n\n## Invariants\n- Every factual claim is source-backed or clearly labeled as inference/proposal.\n- No fake data, citations, test results, architecture components, or case studies.\n- Diagram/prose/examples describe the same design.\n- Target rendering is checked when rendering is part of delivery.\n- Artifact stands alone without requiring hidden conversation context.\n- Audience can identify the primary decision/action.\n\n## Failure Taxonomy\n### Content hallucination\nMissing fact is filled with plausible detail. Remove/research/label unknown.\n\n### Diagram semantic drift\nDiagram no longer matches current design or implies false flow. Regenerate/reconcile.\n\n### Template bloat\nGeneric sections obscure the document's job. Remove sections without decision value.\n\n### Source/render mismatch\nMarkdown/HTML code looks valid but target renderer clips/breaks assets/diagram. Verify rendered output.\n\n### Internal contradiction\nVersions/names/decisions differ across sections. Establish one canonical claim map and reconcile.\n\n### Audience mismatch\nDocument is technically complete but too low/high altitude for intended reader. Reorganize around their decision/action.\n\n### Link/source rot\nCritical evidence points to invalid/missing paths. Repair or preserve relevant content locally when appropriate.\n\n## Anti-Patterns\n- fake metrics to make proposal persuasive;\n- Mermaid diagram full of decorative boxes with no clear edge semantics;\n- generic \"Overview / Architecture / Conclusion\" template regardless of job;\n- copying raw research notes without synthesis;\n- using callout blocks everywhere;\n- claiming rendered/accessible without previewing target medium;\n- architecture prose updated while diagram remains stale;\n- citations that do not support the sentence;\n- giant wall of implementation detail before the main decision.\n\n## Artifact Packet\n```text\nAudience / job:\nArtifact type + destination:\nClaim/source map:\nDecisions vs assumptions vs unknowns:\nStructure rationale:\nDiagram(s) + question answered:\nData/source provenance:\nInternal consistency checks:\nRendered validation:\nAccessibility/usability check:\nKnown limitations:\n```\n\n## Completion Criteria\nArtifact completes when:\n- content is evidence-grounded and audience/job-aligned;\n- structure supports the intended decision/action;\n- diagrams/examples/data are semantically consistent;\n- unknowns are explicit rather than invented;\n- target rendering/links/assets are validated;\n- a zero-context reader can understand and use the artifact.\n\n## Progressive Resources\n- Deep guide: `references/source-grounded-artifact-design.md`\n- Existing guide: `references/artifact-composition-guide.md`\n- Example: `examples/system-architecture-diagram.md`\n"
}