Query Writeback

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_writeback.py to produce a reviewable diff before changing files
• wiki_lint.py after approved writeback

Example:

python scripts/wiki_search.py "<vault>" "<query>" --limit 8
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:

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
• 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