--- name: output description: > Produce a user-facing DELIVERABLE (report, brief, literature review, slide deck, table, email, outline, …) into the output/ directory — grounded in the wiki and strictly following the user's instruction. Use when the user runs /output, or says "write/draft/produce/generate me a about ", "make a from my notes/wiki", or "turn [[topic]] into in output/". Distinct from `query` (answers inline or files a cited synthesis INTO the wiki). The deliverable goes to output/, cites the wiki pages it draws on, clearly labels any general-knowledge content, and NEVER fabricates facts, figures, quotes or citations. user-invocable: true --- # output — generate a grounded deliverable into `output/` ## Goal Turn a user instruction + the compiled wiki into a **deliverable file in `output/`** that (a) **follows the instruction exactly** (format, scope, length, audience, style), (b) is **grounded** in the wiki and **cited**, and (c) **never hallucinates** — abstain when unsure rather than confabulate. ## Triggers - `/output ` - "write / draft / produce / generate me a about ", "make a from my notes", "turn [[topic]] into ". ## Pipeline ### Step 1 — Pin the instruction (no drift) Extract a small **spec** from the user's words: *deliverable type · topic/scope · format · length/size · audience · tone · must-include / must-exclude · citation style · output filename*. If a **material** detail is missing or genuinely ambiguous, ask **1–2 crisp questions**; otherwise proceed with sensible defaults **and state them**. Never silently widen, narrow, or reinterpret the ask. **Customisation gap-fill:** for spec fields the instruction leaves **unstated**, check `CUSTOMISATION.md` → `## Deliverable defaults` (if the file and section exist): apply any standing defaults found there (citation style, deck format, length conventions) and note them in the grounding note. An explicit instruction always overrides; if the section is absent or empty, choose sensible defaults yourself (and state them). Conversational output *styles* never apply to deliverables (CLAUDE.md §1) — this gap-fill covers content-format defaults only. **Single source of truth:** deliverable defaults live *only* in that Customisation section — re-read it on every run and never copy its values into this skill, any config, or the deliverable itself (beyond applying them). ### Step 2 — Ground in the wiki (read first, like `query`) Read `wiki/index.md` **whole** (`route` mode, CLAUDE.md §5), then deep-read the relevant pages (follow `## Related` one hop, which widens a shortlist route already produced and never replaces it). Collect the facts you will use **together with the page each comes from** (for citation). The deliverable is built from compiled knowledge — *not guessed*. Consult `wiki/user/` for personal context when the deliverable is about, or for, the owner. **Triage by `confidence` as `query` does**: lean on `authoritative`/`high` pages for load-bearing claims; the field is already in frontmatter, so this is free. If the catalogue under-covers and qmd is active (the `qmd-search` skill, dormant unless installed), use it as the semantic fallback to locate relevant pages, then deep-read; otherwise `grep`. **Freshness duty**: apply `query` Step 3b to the pages you read — surface stale/contradicted pages in the report line and mark them on-page (`flagged:` frontmatter / §4.4 block); no extra reads for this. ### Step 3 — Separate grounded · general · unknown (anti-hallucination core) Classify every claim before you write it: - **Grounded in the wiki** → cite the page(s) inline as `[[Page]]` (or the requested citation style); weight by the page's `confidence` — state `authoritative`/`high` plainly, but attribute and hedge any claim resting only on `low`/`very-low` pages. - **General knowledge** the instruction needs but the wiki lacks → include **only if clearly labelled** (e.g. *"(general knowledge — not from the wiki)"*). Never present it as wiki-sourced. - **Unknown / unverifiable** → **do not invent it.** Omit and note the gap, or mark a factual claim `unverified`. **Never fabricate facts, numbers, quotes, or citations.** Prefer quoting the raw source over paraphrasing when precision matters. - If the instruction needs something neither the wiki nor safe general knowledge can support, **say so** in the deliverable / report rather than fill the gap with invention. - **Load-bearing wiki gap** → the Step-6 report MAY end with one propose-only gather brief (why · what · how · cost) under the `query` Step-4b bar and consent ledger (CLAUDE.md §6) — the owner's explicit yes runs it; never proposed in non-interactive runs. ### Step 4 — Produce the deliverable, strictly to spec Write exactly what was asked, in the requested **format and length**: a Markdown report/brief/review (default), a **Marp** deck (`marp: true` frontmatter), a table, an email, a Canvas via the `json-canvas` skill, etc. Use **British/UK English**; keep verbatim quotes exact; honour must-include/exclude. Default citations are inline `[[wikilinks]]` (clickable in Obsidian); use a footnote/bibliography style instead if the deliverable is external-facing or the user asks. ### Step 5 — Write to `output/.` (never into `wiki/`) Save to **`output/`** (the deliverables layer — *not* the knowledge graph). Filename = a clean kebab-case slug + correct extension. Do **not** modify `wiki/` or `raw/`. (If the user wants the result compounded back into the knowledge base, that's a `query` synthesis, not an `output`.) **Root vs subfolders (CLAUDE.md §2):** the root holds one-off / temporary deliverables; a report (run, morning, audit, review) goes to `reports/`, the inbox the owner sorts later; standing artefacts live in the matching subfolder (`user-notes/` owner quick-references · `fundings/` funding applications) and are **actively maintained** — a run that updates one edits it in place. Create a new subfolder only on the user's instruction. When filing a standing artefact derived from wiki pages, add a "maintained derivative" line to each source page's `## Related` so future edits propagate. ### Step 6 — Report + grounding note State the path written, then a concise **grounding note**: which wiki pages it draws on, what (if anything) is labelled general-knowledge, and any gaps flagged or questions still open — closing with the freshness line (`query` Step 3b's gate, style-invariant): `Freshness: pages read · oldest [[page]] (updated YYYY-MM-DD) · flagged` **A completion gate: the report is not done without it.** A run that read no wiki pages says so instead. ## Hard constraints - **Follow the instruction exactly** — format, length, scope, inclusions/exclusions. Use defaults only when unstated, and state them when used. - **No hallucination.** Grounded → cite; general → label; unknown → omit / flag / abstain. **Never invent facts, figures, quotes, or citations.** - **Weight by `confidence`.** Prefer higher-confidence wiki pages for key claims; attribute and hedge anything resting only on `low`/`very-low` pages. - **Write only to `output/`.** Never edit `wiki/` or `raw/`. Outputs are deliverables, not knowledge. - **British/UK English** and all other CLAUDE.md rules apply. - **Not logged by default** — a deliverable is not a brain-update (CLAUDE.md §5). Log only if the user asks, or if the run also files a wiki page. ## Deliverable graphics (routing rule, moved here from CLAUDE.md §7 on 2026-09-05) `lieflat-charts` for browser-viewed HTML and interactive charts, dashboards and full-page HTML reports (some templates need CDN network); `scientific-figure-making` (from figures4papers) for publication-grade matplotlib figures for papers, theses and slides (PDF or PNG for LaTeX). Rule of thumb: web-viewed → lieflat-charts; print or venue-bound → scientific-figure-making. Both are `auto` rows in `wiki/developments/capability-register.md`.