query-writeback

name	query-writeback
description	Answer cross-source questions about an open-llm-wiki vault and optionally write reusable synthesis back into concept pages. Use when the user asks a wiki question that requires comparing, connecting, or tracing multiple source/concept pages. By default answer first and propose writeback; modify files only when the user explicitly asks for writeback, pre-authorizes wiki growth, or approves the proposed changes.
license	MIT
metadata	{"version":"0.3.0","reviewed-for":"Claude Code Skills quality"}

Query Writeback

Use the wiki to answer synthesis questions, then preserve high-value synthesis only when file changes are authorized.

Runtime Tools

Use deterministic scripts when available:

• wiki_search.py to find relevant source and concept pages
• wiki_claims.py and claims/claims.jsonl to inspect normalized durable claims
• wiki_normalize_metrics.py when comparisons depend on units, baselines, or protocols
• wiki_semantic_qa.py when the answer depends on claim-level evidence quality
• wiki_science_review.py when a high-stakes synthesis needs human or second-LLM review
• wiki_writeback.py to produce a reviewable diff before changing files
• wiki_lint.py after approved writeback

Example:

uv run python scripts/wiki_search.py "<vault>" "<query>" --limit 8
uv run python scripts/wiki_claims.py "<vault>"
uv run python scripts/wiki_normalize_metrics.py "<vault>" --in-place
uv run python scripts/wiki_writeback.py "<vault>" --target concepts/<page>.md --query "<query>" --body-file <draft.md>

Trigger Boundary

Use this skill for questions that require cross-source synthesis:

• relationships between concepts
• comparisons across papers
• timelines or evolution paths
• recurring questions that would benefit from a reusable concept note

Do not use it for simple factual lookup, casual chat, non-wiki topics, or questions where a single source page already gives the answer.

File-Safety Boundary

• Read from the resolved wiki vault only.
• Answering is read-only by default.
• Writeback requires explicit user approval unless the current instruction has already authorized automatic wiki growth.
• Before writing, show the target files and a short summary of the proposed additions.
• Never rewrite a whole concept page when a targeted insertion is enough.
• Never update sources/ or QA reports from this skill. Use wiki-ingest for source changes.
• Always append a log.md entry for approved writeback.

Workflow

1. Resolve Scope

Read SCHEMA.md, index.md, and relevant concept/source pages. Identify:

• concepts involved
• source pages cited
• relationships being tested
• gaps or missing evidence

2. Assess Coverage

Use this decision table:

Verdict	Condition	Action
FULL	wiki has enough cited material	answer from wiki
PARTIAL	related pages exist but evidence is incomplete	answer with caveats and list gaps
NONE	wiki lacks relevant material	say what is missing and suggest ingest

Do not trigger ingestion automatically. If new sources are needed, propose a separate wiki-ingest run.

3. Answer

Answer in normal prose and cite wiki pages with [[LLM-NNNN]] or [[concept-name]]. Label inference when a relationship is not explicitly stated by a source.

4. Decide Whether Writeback Is Valuable

Propose writeback when at least one is true:

• the answer cites three or more source pages
• the answer contains a comparison table or timeline
• the answer connects two concepts not currently linked
• the question is likely to recur
• the answer identifies a durable gap or contradiction marker

Single-source details and speculative answers usually should not be written back.

5. Self-Check Before Writeback

Check every relational claim:

• explicit in source: write as fact with citation
• explicit in claims/claims.jsonl: prefer the normalized claim and preserve its evidence anchor
• implied but not stated: label as inference
• guessed from chronology or similarity: do not write as a claim

Every paragraph added to a concept page needs at least one citation. Do not write unsupported synthesis.

6. Execute Approved Writeback

When writeback is approved:

1. Prefer updating an existing concept page.
2. Create a new concept page only when no existing concept fits.
3. Add frontmatter for new concept pages using templates/concept-template.md.
4. Add bidirectional links when useful.
5. Update index.md if a new concept page is created.
6. Append to log.md: [YYYY-MM-DD HH:MM] query-writeback | concepts/<page>.md | agent | query: "<original question>"

Mark writeback-derived sections with:

query-derived: YYYY-MM-DD

If wiki_writeback.py is available, use it to produce the diff first. Apply only after approval or pre-authorization.

Completion Criteria

Finish with:

• direct answer to the user's question
• citations used
• whether writeback was skipped, proposed, or completed
• changed files if writeback happened
• lint result after writeback when runtime tools are available
• remaining gaps that require future ingest