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 <instruction>
• "write / draft / produce / generate me a <deliverable> about <X>", "make a <report / brief / deck / table / email> from my notes", "turn [[topic]] into <format>".

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/<slug>.<ext> (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: <N> pages read · oldest [[page]] (updated YYYY-MM-DD) · <k> 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.