


Build a Research Wiki from Your Sources and Answer Questions with Citations
Use when you collect many articles or papers on one research topic. The AI leaves the originals untouched, writes a summary page for each, flags conflicting claims, answers questions with citations, and checks the wiki for broken or missing links.
To use this AI rule
## Keep Collected Sources Apart from the Wiki Pages the AI Writes
Separate source preservation from agent-maintained knowledge:
- `sources/` holds immutable input documents.
- `wiki/index.md` catalogs every maintained page.
- `wiki/log.md` is the append-only operation history.
- `wiki/overview.md` is the living synthesis across sources.
- `wiki/sources/` contains one summary page per input source.
- `wiki/entities/` contains people, organizations, projects, and products.
- `wiki/concepts/` contains ideas, methods, theories, and frameworks.
- `wiki/syntheses/` contains saved answers to research questions.
- `graph/` contains generated graph data and visualizations.
- `tools/` contains deterministic and semantic maintenance utilities.
Never modify source documents during ingestion. The maintained layer may be created and revised, but every claim must remain traceable to a source page.
Update the index on every ingestion. Append operational history rather than rewriting it, and revise the overview only when new evidence changes the cross-source synthesis.
## Record Sources and Update Dates on Every Page and Use Consistent Names
Every maintained page must use structured metadata:
- `title`: a descriptive page title.
- `type`: exactly one of `source`, `entity`, `concept`, or `synthesis`.
- `tags`: a list of classification tags.
- `sources`: a list of source slugs that support the page.
- `last_updated`: a date in `YYYY-MM-DD` format.
Source summaries should add the source date and original source reference. Use stable internal links to connect sources, entities, concepts, and syntheses.
Use consistent naming:
- source slugs use lowercase kebab-case;
- entity and concept pages use stable title-style names;
- saved syntheses use descriptive slugs;
- operation logs use `YYYY-MM-DD`, operation, and title.
Specialized source types may use specialized sections. Meeting notes should preserve goals, discussions, decisions, and actions; journals should preserve events, decisions, observations, connections, and changes. Keep the same provenance requirements in every template.
## Add a New Source and Update the Pages It Affects
When ingestion is requested, complete these steps in order:
1. Read the source in full; convert unsupported source formats to Markdown without changing the original.
2. Read the current index and overview to understand existing coverage.
3. Create one source page with a short summary, key claims, selected evidence, connections, and contradictions.
4. Add the new source to the index.
5. Revise the overview only where the new source warrants a change.
6. Create or update pages for important entities and concepts.
7. Compare new claims with existing pages and explicitly flag contradictions.
8. Append an ingestion entry to the operation log.
9. Validate that every new page is indexed and every internal link resolves.
10. Report the exact pages created, updated, or flagged.
Do not treat ingestion as extraction alone. It must integrate the source into the existing knowledge model while preserving provenance and uncertainty.
## Answer Research Questions by Pointing to the Supporting Pages
When a question is asked:
1. Read the index to identify likely relevant pages.
2. Read the smallest sufficient set of source, entity, concept, and synthesis pages.
3. Distinguish source claims from your own synthesis.
4. Answer with inline internal citations that point to the supporting pages.
5. State contradictions, uncertainty, and missing evidence instead of forcing consensus.
6. Ask before saving the answer as a durable synthesis page.
A saved synthesis must record the question it answers, link to its supporting sources, and remain revisable as later evidence arrives.
Do not cite an index entry as evidence when the underlying source page is available. Prefer the closest authoritative page in the provenance chain.
## Check Page Structure Quickly Before Checking Content in Depth
Run a fast structural health check before expensive semantic analysis.
Structural health uses deterministic checks and no model calls. It should detect:
- empty or stub pages;
- index entries that do not match actual pages;
- source pages missing ingestion log entries.
Run structural health at the start of a work session and before semantic linting.
Semantic lint evaluates content quality and may use model analysis. Run it periodically, such as after 10 to 15 ingestions, and check:
- orphan pages with no inbound links;
- broken internal links;
- contradictions across pages;
- stale summaries superseded by newer sources;
- recurring entities that lack entity pages;
- sparse pages with fewer than two outbound links;
- unanswered questions and missing evidence.
If graph data exists, also report thin high-degree hubs, community pairs connected by only one edge, and isolated communities. Do not spend semantic-analysis resources until structural health passes.
## Build a Knowledge Graph from Page Links and Find Weak Spots
Build one node per maintained page and one edge per explicit internal link.
When generating graph data:
1. Parse explicit links across all maintained pages.
2. Record nodes, edges, and the build date in machine-readable graph data.
3. Generate a self-contained visualization when useful.
4. Calculate edge-to-node ratio, orphan rate, community count, and link density.
5. Identify high-degree hubs above the mean plus two standard deviations.
6. Flag high-degree pages with less than 500 characters as thin hubs.
7. Flag community pairs connected by only one edge as fragile bridges.
8. Report references to missing pages when two or more pages point to the same absent target.
Inferred relationships must be labeled `INFERRED` with a confidence score. Mark low-confidence inferences as `AMBIGUOUS`; never present them as explicit source-grounded links.
## Treat Automatic Links as Drafts and Never Create Pages from Broken Links
Treat automatically proposed links as drafts:
1. Add proposed edges to the graph as `DRAFT` without writing them into page bodies.
2. Validate that each proposal is grounded in source content and consistent with existing knowledge.
3. Promote only proposals that pass validation.
4. Materialize promoted edges as internal links.
5. Require at least two outbound links before promoting a page to stable status.
Never auto-create pages from broken links. Report missing targets as research or curation signals; automatic creation would amplify hallucinated references.
Do not add a new command or workflow when an existing one covers the same operation. Extend or clarify the existing entry point instead.
Preserve immutable sources, append-only history, and provenance links during every maintenance action. Before overwriting generated graph artifacts, ensure they can be rebuilt deterministically from the maintained pages.
