wikilinks
Wikilinks in Content
When to apply
- Generating or editing markdown (
.md) content - Writing notes, docs, or knowledge-base material
- User asks for wikilinks, cross-links, or interconnected content
Core rules
-
Actively look for link targets: Before or while generating text, search the codebase (e.g. file tree, grep, or project search) for existing notes or pages that match concepts, people, or terms you mention. Prefer linking to those real pages where possible.
-
Use double square brackets for wikilinks:
[[concept]],[[Product Name]],[[Person Name]]. -
Link what matters: concepts, products, people, domain-specific terms. Prefer linking where a reader might want to jump to a dedicated note.
-
Targets need not exist: The linked page does not have to exist yet; if you find a relevant existing note, link to it. Otherwise a new target is fine.
-
Use aliases for readable prose: Prefer natural wording over raw filenames.
- Format:
[[target page|display text]] - Example:
[[1.2.B Local Unit Manager|Unit Manager]]so the sentence reads “the Unit Manager” not the filename.
- Format:
-
Inline, not collected: Do not add a separate “References” or “See also” section. Place each link in the body where the concept is first or most relevant.
Examples
Avoid:
The Unit Manager is responsible for approvals. See 1.2.B Local Unit Manager for details.
## References
- [1.2.B Local Unit Manager](1.2.B%20Local%20Unit%20Manager.md)
Prefer:
The [[1.2.B Local Unit Manager|Unit Manager]] is responsible for approvals.
Multiple links in flow:
[[Project Alpha]] uses the new [[approval workflow]]; the [[1.2.B Local Unit Manager|Unit Manager]] signs off before [[deployment]].
Summary
- Actively search for existing pages that match what you mention; link to them when found
[[page]]or[[page|label]]in the main text- No standalone references section
- Link once where the concept is most relevant
More from michael-f-bryan/skills
long-running-agent-harness
Plans and structures large-scale work for AI agents across many sessions. Human and AI iterate to produce a design doc; run an Initializer sub-agent once to create feature list, runbook, and backlog in _working/; then repeatedly run a Coding sub-agent until all features pass. At milestones (e.g. end of a work-unit group), pause for human check-in, re-run Initializer, then continue. Prompts are passed to sub-agents when spawning (no copying into .cursor/rules). Use when planning multi-session agent work, long-horizon coding from a design, or handoff between coding sessions.
31doc-coauthoring
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
23working-docs
Use when handling multi-step tasks, investigations, or long sessions where working notes, interim findings, and scratch planning are needed to keep context and handoffs clear.
22test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
19commit-messages
When suggesting or writing commit messages for this repo, follow these rules.
17code-like-michael
Write, refactor, and review code in Michael's style; explicit contracts, thin entrypoints, practical boundaries, anti-ceremony abstractions, deterministic tooling, and architecture that scales from function internals to repository shape.
14