wikirize

Create a lean, source-truth project wiki from a codebase.
Built for AI agents that need to find the right files, relationships, and verification paths before safely modifying repositories.

Install · What It Builds · Obsidian Support · Benchmark · Usage · Output Shape · Principles

---

Install

Install from GitHub:

npx skills add tmih06/wikirize --skill wikirize

Install from a local checkout:

npx skills add . --skill wikirize

Install globally:

npx skills add tmih06/wikirize --skill wikirize --global

---

What It Builds

Wikirize creates a nested wiki/ directory that maps source code, entrypoints, flows, contracts, configuration, tests, CI, and agent maintenance rules.

Source Map wiki/source-map.md Project-owned files, modules, directories, responsibilities, and related tests.	Entrypoints wiki/entrypoints.md Apps, CLIs, routes, handlers, jobs, workers, exports, and public contracts.	Flow Map wiki/flows.md Startup, runtime, requests, auth, jobs, persistence, integrations, tests, CI, and deploy flows.
Coverage Manifest wiki/coverage-manifest.md Source areas covered, excluded, unknown, or needing follow-up.	Agent Quickstart wiki/agent-quickstart.md What future agents should read before changing each area.	Maintenance Rules AGENTS.md Required wiki updates after durable source, flow, contract, config, or test changes.

---

Plain Markdown First

The generated wiki works as normal Markdown in any repository. Obsidian is not required.

Obsidian-friendly syntax can be added only when the user wants it, and only when it does not break normal Markdown readability.

---

Obsidian Support

Wikirize does not require Obsidian. The generated wiki/ remains plain Markdown first, but it can also be opened as an Obsidian-friendly knowledge base when a user wants graph navigation and note linking.

For users who want deeper Obsidian-specific agent workflows, kepano/obsidian-skills is a recommended external companion skill set.

---

Benchmark

A six-task architecture-understanding benchmark compared default source exploration, wiki-assisted exploration, and GitNexus-assisted exploration on the same production-style monorepo workload.

The benchmark ran on OpenCode 1.14.3 with GPT-5.5, xhigh thinking effort, and nominal 80 TPS. The workload covered request lifecycle, domain/configuration flow, background jobs, UI/API/data flow, data ownership, tests, operations, Docker, CI, and runtime configuration.

Method	Tool Calls	Wall Time	Tokens
Source-only exploration	160	12m33s	414k
Wiki-assisted exploration	111	8m56s	224k
GitNexus-assisted exploration	257	22m17s	873k

Method	Tool Calls vs Baseline	Time vs Baseline	Tokens vs Baseline
Source-only exploration	1.00x	1.00x	1.00x
Wiki-assisted exploration	0.69x	0.71x	0.54x
GitNexus-assisted exploration	1.61x	1.78x	2.11x

Winner	Tool Call Change	Time Change	Token Change
Wiki-assisted exploration	30.6% fewer	28.8% faster	45.9% fewer

Wiki-assisted exploration performed best: it kept source verification available while giving agents a high-signal map of files, entrypoints, contracts, flows, tests, config, and operations before deep source inspection.

Usage

Ask your coding agent to run:

/wikirize

or:

wikirize this repository

Use Wikirize for initial wiki bootstrapping. It is not meant to run automatically during normal feature work, bug fixes, reviews, or small documentation edits.

---

Output Shape

The exact structure adapts to the repository. A lean wiki usually starts with source maps, entrypoints, contracts, flows, verification, and focused subsystem pages:

wiki/
├── agent-quickstart.md
├── architecture
│   ├── boundaries.md
│   └── index.md
├── change-map.md
├── contracts.md
├── contributing-agent-rules.md
├── coverage-manifest.md
├── entrypoints.md
├── flows.md
├── index.md
├── source-map.md
├── subsystems
│   ├── api
│   │   ├── flows.md
│   │   ├── index.md
│   │   ├── source-map.md
│   │   └── tests.md
│   └── web
│       ├── flows.md
│       ├── index.md
│       ├── source-map.md
│       └── tests.md
└── verification.md

4 directories, 18 files

Each page should point to source truth and related files. It should not restate trivial implementation details that agents must verify in code anyway.

---

Principles

Rule	Why It Matters
Source truth first	Code, tests, schemas, config, migrations, scripts, and CI override stale docs.
Lookup-first coverage	Agents need focused pages they can query by file, entrypoint, contract, domain, or flow.
Important symbols	Entrypoints, public APIs, contracts, handlers, jobs, schemas, models, and risky helpers should be locatable.
Workflow clarity	Runtime, request, job, persistence, integration, test, CI, and deploy flows must be traceable.
Agent maintenance	Future durable source changes must update the affected locator and relationship pages in the same task.

---

Skill File

skills/wikirize/SKILL.md

---

Benchmark Prompt

You are one agent in a benchmark comparing codebase exploration methods.

You must complete the same six complex codebase-understanding tasks as the other benchmark agents. Do not edit files. Do not mutate the repository. Use only your assigned information sources.

Assigned method:
<METHOD_POLICY>

Goal:
Produce a source-backed architecture report for this repository. Cover the whole relevant codebase, not just one file. Prefer concrete file paths, symbols, functions, classes, routes, commands, config files, data models, and runtime flows.

Six tasks:
1. Request/runtime lifecycle:
   Trace the main user-facing or API-facing request lifecycle from entrypoint to response. Include authentication/authorization, routing/dispatch, major state transitions, integrations, error paths, and response behavior.

2. Domain model and capability/configuration flow:
   Explain how the project represents its core domain entities, capabilities, feature flags, provider/plugin/module registries, configuration, validation, and transformations. Include where these are defined, loaded, validated, and consumed.

3. Background jobs, scheduling, health, or status flow:
   Trace any background workers, schedulers, health checks, polling loops, queues, caches, status aggregation, or maintenance jobs. Include persistence, cache keys, retry/failure behavior, and how status is surfaced.

4. UI/API/server-action/data flow:
   Explain how frontend, API routes, server actions/controllers, schemas, and data-fetching layers interact. Include important client/server boundaries, validation points, auth boundaries, and mutation flows.

5. Data model and ownership map:
   Identify core database/schema/storage models and which parts of the system read or write them. Include migrations/schema files, cross-service ownership boundaries, coupling risks, and any source/schema mismatches.

6. Test, operations, and runtime coverage map:
   Identify tests, scripts, build commands, Docker/Compose/Kubernetes/deployment configs, CI workflows, runtime environment variables, and recommended verification commands. Include gaps and operational risks.

Reporting requirements:
- Return a concise but substantive answer for each of the six tasks.
- Include source references using file paths and symbol names where possible.
- Include a final Benchmark Metrics section with:
  - elapsed wall-clock time if visible,
  - number of tool calls or iterations if tracked,
  - whether token usage was visible,
  - confidence per task,
  - limitations caused by your allowed method.
- Do not claim exact token usage unless the runtime exposes it.
- Do not modify the repository.