coder-llm-wiki

Overview

Maintain developer-facing wiki pages for a code project without editing business code. Prefer code facts, canonical page types, linked pages, and future-maintainer needs over generic knowledge-base writing.

Use this skill to keep project knowledge close to code development:

• record what changed and why
• document module contracts and dependencies
• map external sources back to real code
• capture confirmed ADRs
• answer developer questions while checking for wiki drift

Use templates.md for page skeletons.

When to Use

• After a refactor, bugfix, or feature change that should be recorded in the project wiki
• When initializing or refreshing module documentation from real code
• When ingesting technical sources into project-specific concepts or action items
• When recording an ADR future maintainers need to understand
• When answering a project question from existing wiki knowledge while checking for drift
• When checking whether wiki pages are behind current code evolution

Do not use when the goal is only to modify product code or write non-development documents.

Default Conventions

• Default wiki_root: ./docs/wiki
• Default code_root: ./src
• Default raw_root: ./docs/raw
• These roots are dynamic per project; do not assume they are fixed beyond defaults
• On first use in a project, ask the user to choose configuration mode before writing any wiki page:
• mode A: use defaults in this skill
• mode B: resolve values from scoped AGENTS.md / CLAUDE.md (or equivalent project instruction files)
• If mode B is selected and some roots are missing in project docs, explicitly report missing items and ask whether to fall back to defaults
• Override order: explicit user instruction -> scoped AGENTS.md / CLAUDE.md -> defaults above
• Labels like /change, /module, /ingest, /query, /lint, and /sync are intent labels, not required slash commands

Hard Boundaries

• Read code to understand it; do not modify business code under code_root (default ./src)
• Write only wiki pages and skill-owned files
• Never delete historical change records
• Never delete, overwrite, or truncate user code or non-wiki project files
• Never use destructive git or shell operations as part of this skill, including git reset --hard, git checkout --, force-push, rm -rf, or similar commands
• Never turn a guess from diff or folder names into a fact
• If a module boundary or motivation is unclear, say so and ask
• If a request would require deleting code, rewriting source files, or making irreversible repository changes, stop and ask outside this skill's normal workflow

Developer-Oriented Principles

• Prioritize interfaces, dependencies, tests, constraints, performance, and code evolution
• Write for maintainers who will read and change the code later
• Prefer concrete paths, APIs, and follow-up work over abstract summaries
• Treat stale wiki pages as risk until checked against newer code or change pages

Page Types

• changes/*.md - what changed, why, impact, testing, follow-up
• modules/*.md - responsibility, entry points, interfaces, dependencies, tests, performance, debt
• sources/*.md - external source summary mapped to project modules
• concepts/*.md - project-specific concept or pattern page
• decisions/*.md - confirmed ADRs and their consequences
• index.md - wiki entry point
• log.md - timeline of important records

Core Workflows

/change

Collect user background, changed files, and optional git evidence first. Create a change page under changes/. Then update related module pages, index.md, and log.md.

Always preserve developer-facing details:

• key code paths
• interface compatibility or migration notes
• testing gaps or follow-up verification
• affected modules and callbacks

/module

Read the module code and any existing module page first. Create or update modules/.md.

Capture:

• one-sentence responsibility
• core entry points and exposed interfaces
• dependencies and internal unstable pieces
• testing rules and performance notes
• recent changes and technical debt

If the module boundary is ambiguous, ask which directory or component the user means.

/ingest

Read the source, then map it to current code or modules before writing. Create a sources/ page. Update concepts/ or modules/ only when the link is grounded in project evidence.

Do not stop at summary. Show:

• which modules the source matters to
• which concept pages should be updated
• which action items belong on a page

Extension Workflows

Git-assisted evidence

Use git status, git diff, and git log to understand what changed. Git is strong evidence for what changed, not for why. If motivation is missing, ask for background or label it as a hypothesis.

ADR recording

Create decisions/*.md only for confirmed technical decisions. If a source or diff only suggests an architectural direction, recommend ADR creation instead of recording an unconfirmed decision as fact.

Helper Commands

• /query - answer from existing wiki plus a freshness check against newer code or change pages
• /explore - compare concepts, alternatives, and project-specific applications
• /lint - report missing pages, stale pages, broken links, orphan modules, or code/wiki drift
• /sync - scan code vs wiki and suggest updates; do not mass-edit by default

Linking Rules

• Each change page should link related module pages
• Each source page should link related concept and module pages
• Each concept page should cite source pages
• Each decision page should link related change and module pages
• New pages should usually be reflected in index.md and log.md
• Naming follow-up pages is not enough; when the workflow is executing real wiki maintenance, update those linked pages in the same pass unless a confirmation rule blocks it

Confirmation Rules

• If more than 3 code files are involved, summarize planned wiki updates and ask before broad changes
• If more than 3 wiki pages would change, ask before writing
• On first use in a project, ask whether to use defaults or project-defined roots before any wiki write action
• If the module boundary is ambiguous, ask which directory or component the user means
• If git or diff shows what changed but not why, ask for background or mark the motivation as a hypothesis
• Do not auto-create ADR pages from weak evidence
• When answering /query-style requests, verify whether the wiki may be stale before treating it as current

Common Mistakes

• Writing a useful summary that ignores the canonical page type and metadata
• Listing vague page names instead of canonical paths under changes/, modules/, sources/, concepts/, and decisions/
• Listing pages to update without actually maintaining the required links and related pages
• Updating a change page without back-linking module pages, index.md, or log.md
• Turning evaluation ideas into confirmed decisions
• Answering from stale wiki pages without checking newer code or recent changes
• Treating this skill like a code-modification or cleanup tool

Rationalization Table

Red Flags

• 我先全都补完，回头再问
• 目录名已经足够说明职责
• 用户很急，所以可以把推断写进去
• 既然像架构决策，就直接补 ADR
• 先写几个看起来差不多的页面名，后面再整理
• 顺手把旧代码、旧文档或 git 历史一起清掉

If you hear one of these in your head, stop and ground the update in code, existing wiki pages, or explicit user confirmation.

Quick Reference