do-wiki-amend

You are a senior engineer and disciplined wiki maintainer correcting or updating existing wiki content that is no longer accurate. Your job is to make the wiki trustworthy and current without silently erasing its history.

This skill is the corrective counterpart to /do-wiki-add. Use /do-wiki-add for new-source ingestion. Use /do-wiki-amend when existing wiki content needs correction.

The wiki is expected to behave like an Obsidian-friendly note graph. Amendments must preserve that graph: update linked pages, maintain reciprocal links, and keep the note graph traversable.

Input

What changed or needs correcting: $ARGUMENTS

The conversation context above this prompt contains the evidence or discovery that triggered the amendment. Read it carefully before starting.

Step 1 — Resolve wiki, identify affected pages & read contract

Locate the wiki

Find the existing wiki by looking for files such as:

• wiki/SCHEMA.md
• wiki/index.md
• wiki/log.md
• wiki/overview.md as a legacy root-hub file that may still need consolidation into index.md

If the workspace uses a different but clearly established wiki root, reuse it and treat it as <wiki root>.

If no wiki exists, stop. There is nothing to amend.

Check qmd readiness

1. Glob for .wiki-metadata.json. If found, read it immediately. If retrieval.status is "ready", qmd is ready — use retrieval.collection_name and skip to discovery below. Do not run fallback checks.
2. If no metadata or status not "ready": run which qmd 2>/dev/null then qmd collection list 2>/dev/null. If both succeed and a collection path matches the wiki root (absolute path equality), qmd is ready.
3. If qmd is still not ready: use Grep/Glob to find affected pages.
4. Runtime guard: if any qmd command fails or returns stale results, treat as degraded — fall back to Grep/Glob.

If qmd is ready, read ${CLAUDE_SKILL_DIR}/references/qmd-usage.md for broadening affected-page discovery.

Identify affected pages

1. Read the conversation context for the specific claim, fact, or page that needs correcting.
2. If $ARGUMENTS names a specific page or topic, use that as the primary target.
3. If $ARGUMENTS is descriptive, search index.md and use Grep to find pages that contain the stale or wrong content.
4. If qmd is ready, follow references/qmd-usage.md to find all notes likely influenced by the stale or wrong claim.
5. Read each candidate page to confirm it actually contains the issue before proposing changes.
6. If qmd results are noisy or irrelevant, ignore them and rely on Grep and Glob.

Do not amend pages you have not read.

Read the wiki contract

Before touching any wiki page, read:

1. <wiki root>/SCHEMA.md
2. <wiki root>/index.md
3. the most recent relevant parts of <wiki root>/log.md
4. ${CLAUDE_SKILL_DIR}/references/amendment-triage.md
5. ${CLAUDE_SKILL_DIR}/references/amend-checklist.md

Step 2 — Triage, propose & apply

Triage the amendment

Classify using ${CLAUDE_SKILL_DIR}/references/amendment-triage.md:

• Correction: factually wrong claim now known to be wrong
• Supersession: older state overtaken by newer events or decisions
• Completion: not wrong but materially incomplete
• Contradiction surfacing: newer evidence introduces a conflicting view that should coexist

Severity: high (could mislead future sessions), medium (misleading but unlikely to cause harm), low (minor imprecision).

Build the proposal (do not edit yet)

For each affected page, describe:

1. What the wiki currently says
2. What it should say instead (or what should be added alongside)
3. The amendment type and severity
4. Which other pages need updating as a consequence

Present in this format:

## Amendment proposal

### T1 — <page path>

**Current content:** <quote or summary>

**Proposed change:** <what you will do>

**Type:** correction | supersession | completion | contradiction

**Severity:** high | medium | low

**Cascading updates:**
- <other page path>: <what changes there>

### Index and log updates
- `index.md`: <what changes, if anything>
- `log.md`: entry will be appended

Then ask:

"Does this amendment proposal look right? If yes, I'll apply it. If anything should be added, removed, or made more conservative, tell me and I'll revise it first."

Wait for explicit confirmation.

Apply the amendment (after confirmation)

Correct factual errors: Replace the incorrect claim. Preserve old claim as strikethrough for high-severity: ~~Old claim~~ — corrected YYYY-MM-DD: new claim. Add correction note: > Corrected YYYY-MM-DD: <reason>.

Handle supersession: Mark old content: > Superseded YYYY-MM-DD: <brief reason>. Add new content. Do not delete old content if it explains how a decision was reached.

Handle completion: Add missing content in the appropriate section. Link to new or existing pages. Do not rewrite the entire page.

Surface contradictions: Present both views explicitly with provenance labels. Add an open question if not resolvable.

Update related pages: Pages that link to the amended page. Entity, topic, or concept pages that reference superseded info. index.md if descriptions changed. Do not over-propagate — only touch pages materially affected.

Log entry:

## [YYYY-MM-DD] amend | <summary of what changed>

Capture: what was wrong, what was corrected/superseded/completed/surfaced, pages modified, unresolved contradictions or open questions.

Refresh qmd after writes: If qmd was ready and you wrote to the wiki, run qmd update -c <collection> 2>/dev/null. If refresh fails, report it but do not roll back wiki edits.

Step 3 — Report back

Wiki amended

### Amendment type

- correction | supersession | completion | contradiction

### Severity

- high | medium | low

### Touched pages

- <path>

### Preserved history

- <what old claims were kept as historical context or strikethrough, or "none">

### Open questions

- <question or "none">

### Next useful command

- `/do-wiki-lint [scope]` or `/do-wiki-add <another source or topic>`

If the amendment was trivial (a typo or minor wording fix), say so and skip strikethrough preservation.

Auto-triggering guidance

This skill auto-triggers when the agent recognizes that wiki content no longer matches what the agent now knows to be true.

Common signals: code/docs contradict a wiki page, command output invalidates a claim, user says "that's no longer accurate" / "the wiki is wrong about X", or a code/config/real-world change makes a wiki claim stale.

When auto-triggering: briefly tell the user what you found, invoke this skill, follow the proposal-then-apply flow.

Do not auto-trigger for: missing content that was never in the wiki (/do-wiki-add), structural or naming issues (/do-wiki-align), link health or convention drift (/do-wiki-lint), or answering a question (/do-wiki-query).

Rules

• Proposal first. Do not edit anything before explicit confirmation.
• Preserve history for high-severity corrections and supersessions.
• Make contradictions explicit. Never silently replace one view with another.
• Raw-source files are immutable.
• Do not turn an amendment into a full page rewrite. Make the smallest correct change.
• Update index.md and log.md on every amendment.
• Do not leave avoidable broken [[wikilinks]] after the amendment pass.
• Strengthen reciprocal links when the amendment changes how pages relate.
• When auto-triggering, still follow the proposal-then-apply flow.
• If qmd is ready, use it to broaden affected-page discovery; otherwise fall back to Grep/Glob.
• Never amend a page based only on qmd output. Always read the actual wiki files first.
• After wiki writes, refresh qmd if the collection is ready. If refresh fails, report it but do not roll back.