Turn any codebase into a structured knowledge base that Claude actually understands.
You just joined a new project. Or maybe you've been on it for a year but Claude keeps asking you the same questions. It doesn't know your auth flow. It doesn't know which service talks to which. It doesn't know that "pattukal" means songs in your domain.
CodeWiki fixes that. One command, and your entire codebase becomes a structured wiki that gives Claude (and your team) the full picture.
Claude Code is powerful, but it starts every conversation blind. It reads files on demand, guesses at architecture, and misses the connections between services. The result:
- Repeated context-setting. You explain the same auth flow, the same data model, the same deployment setup — every single session.
- Shallow understanding. Claude sees individual files but misses how they fit together. It doesn't know your API gateway routes to three backend services, or that a webhook triggers an async chain across four of them.
- No product awareness. Code structure alone doesn't tell Claude who your users are, what they're trying to do, or why that edge case matters.
- CLAUDE.md is manual and fragile. Writing it by hand means it's always incomplete, always outdated, and never covers the full system.
CodeWiki is a Claude Code skill that scans your codebase and generates a complete product knowledge base. Not just code docs — product docs. It understands your architecture, traces your user flows, maps your services, and writes it all down in a format optimized for LLM consumption.
Run /codewiki and get:
| Output | What's in it |
|---|---|
overview.md |
Product summary, target users, key links |
architecture.md |
System design, components, how they connect |
service-map.md |
Service dependencies, sync/async communication |
events.md |
Event catalog with full async flow chains |
user-flows/ |
Step-by-step journeys mapped to actual code paths |
api-reference.md |
Every endpoint, grouped and documented |
data-models.md |
Schemas, relationships, ownership |
frontend-map.md |
Routes, components, state management |
mobile-map.md |
Screens, navigation, platform-specific patterns |
commands.md |
Dev, build, test, deploy — all in one place |
env-vars.md |
Every environment variable across every service |
glossary.md |
Domain-specific terms your team uses |
CLAUDE.md |
Auto-generated project context file |
It skips what doesn't apply. No mobile app? No mobile-map.md. Not microservices? No service-map.md or events.md.
- Solo devs who want Claude to stop asking "what framework is this?" every session
- Teams onboarding new engineers who need to understand the system fast
- Multi-repo projects where no single person holds the full architecture in their head
- Microservice architectures where the async event chains are the hardest thing to document and the easiest thing to get wrong
- Anyone maintaining a CLAUDE.md by hand and tired of it being perpetually incomplete
CodeWiki runs in 7 phases. You don't need to manage them — just answer a few questions and let it work.
- Product context — Asks about your product, users, and URLs. Fetches landing pages and docs for additional context. (Skippable — it'll infer from code and ask you to confirm.)
- Codebase scan — Reads your code structure, entry points, routes, endpoints, models, env vars, and build commands. For multi-repo, it scans one repo at a time to stay within context limits.
- User flow discovery — Proposes flows it found in the code, asks you to confirm or add more, then traces each flow through frontend, backend, and async side-effects.
- Architecture checkpoint — Presents its understanding for you to verify before generating anything.
- Knowledge base generation — Writes everything to
codewiki/using structured templates. - CLAUDE.md — Generates a new one or merges into your existing one (your manual additions are preserved).
- Git setup — Commits locally. Optionally creates a GitHub repo and pushes.
Go, TypeScript, Python, Rust, Flutter/Dart, Ruby, Java, and anything else with readable dependency files and entry points. It adapts its scanning to whatever it finds.
| Project type | How CodeWiki handles it |
|---|---|
| Single app | Full deep scan in one pass |
| Monorepo | Scans each package/workspace, maps shared dependencies |
| Multi-repo microservices | Sequential scan with context management — infrastructure first, then gateway, frontends, core services, supporting services |
For microservices, it builds a full service topology from your infrastructure configs (docker-compose, k8s manifests, API gateway configs) before scanning individual services. It traces async event chains across services and confirms them with you.
git clone https://github.com/ekuttan/codewiki.git ~/.claude/skills/codewiki# Download or clone anywhere, then copy
cp -r codewiki ~/.claude/skills/codewikiThe skill directory should look like:
~/.claude/skills/codewiki/
├── SKILL.md
└── templates/
├── architecture.md
├── claude-md.md
├── events.md
├── readme.md
├── service-map.md
└── user-flow.md
Open Claude Code and type /codewiki. If it appears in the slash command menu, you're set.
New to Claude Code skills? See the official docs on extending Claude with skills.
cd your-project
/codewiki
For multi-repo projects, cd into the parent folder that contains all your repos:
cd ~/projects/my-product # contains backend/, frontend/, mobile/, etc.
/codewiki
CodeWiki discovers cross-repo relationships by scanning sibling directories. For this to work, all repos must live under a single parent folder.
my-product/ # parent folder — run /codewiki from here
├── backend/ # git repo
├── frontend/ # git repo
├── mobile-app/ # git repo
├── admin-dashboard/ # git repo
├── shared-libs/ # git repo (optional)
└── infra/ # git repo (optional)
Each subfolder is its own git repo. The parent folder doesn't need to be a git repo itself.
mkdir -p ~/projects/my-product && cd ~/projects/my-product
git clone git@github.com:your-org/backend.git
git clone git@github.com:your-org/frontend.git
git clone git@github.com:your-org/mobile-app.git
git clone git@github.com:your-org/admin-dashboard.git
# ... clone all repos that make up the productWhen it detects multiple repos, it:
- Inventories every repo — identifies each folder's role (API server, web app, mobile app, comms service, etc.) from dependency files and project structure
- Scans in priority order — infrastructure and contracts first, then gateway, frontends, core business services, and finally supporting services
- Manages context — scans one repo at a time, writes findings to a scratch folder, carries only a compact summary forward. This means it works even on large projects without running out of context.
- Maps cross-repo connections — API calls from frontend to backend, shared types, event producers and consumers, service-to-service communication
- Traces user flows across repos — a single user action (like "sign up") might touch the mobile app, API gateway, user service, notification service, and billing service. CodeWiki traces the full chain.
For multi-repo projects, CodeWiki asks whether you want the codewiki/ output:
- Inside the parent folder — alongside your repos, as a shared knowledge base
- In its own dedicated repo — so you can version and share it independently
Either way, it generates a CLAUDE.md you can copy into whichever repo you're actively working in.
Run /codewiki again anytime. It detects existing files and offers to:
- Fresh scan — back up and replace everything
- Rescan & merge — preserve your manual edits and update generated sections
The templates/ directory contains the structure for each output file. Edit them to match your team's documentation style, add sections, or remove ones you don't need.
Edit SKILL.md to change how CodeWiki scans, what questions it asks, or how it handles specific project types. The entire skill is a single markdown file — no build step, no dependencies.
Want CodeWiki available only for a specific project? Put it in your project's plugin directory instead:
your-project/.claude/skills/codewiki/
Learn more about skill scoping and plugin configuration in the Claude Code settings docs.
After running on a multi-component project, your repo will contain:
your-project/
├── CLAUDE.md # auto-generated project context
├── codewiki/
│ ├── overview.md
│ ├── architecture.md
│ ├── user-flows/
│ │ ├── index.md
│ │ ├── sign-up-onboarding.md
│ │ ├── checkout.md
│ │ └── ...
│ ├── api-reference.md
│ ├── data-models.md
│ ├── frontend-map.md
│ ├── commands.md
│ ├── env-vars.md
│ └── glossary.md
├── src/
└── ...
Every future Claude Code session in this project starts with full context. No more explaining your architecture from scratch.
CodeWiki runs entirely on your local machine inside Claude Code. Here's what it does and doesn't do:
- Reads your source code — that's the whole point. It scans files, dependency manifests, configs, and entry points to understand your project.
- Writes only to
codewiki/andCLAUDE.md— output stays in your project directory (or a sibling directory you choose). It doesn't modify your source code. - Fetches URLs you provide — if you give it your landing page or docs URL during the product context phase, it will fetch those pages to extract product descriptions. It only fetches URLs you explicitly provide.
- No data leaves your machine — CodeWiki doesn't phone home, collect telemetry, or send your code anywhere. It's a prompt file and a set of templates. There is no backend, no API, no analytics.
- No secrets in output — CodeWiki documents environment variable names, not values. It won't write your API keys, database passwords, or tokens into the generated docs. That said, always review the output before committing to a public repo.
- Web applications — backend APIs, frontend SPAs, full-stack apps. CodeWiki understands routes, endpoints, models, and auth flows across the stack.
- Mobile apps — Flutter, React Native, Swift, Kotlin. It maps screens, navigation, state management, and API integration.
- Microservices — this is where CodeWiki really shines. It traces service dependencies, async event chains, data ownership, and cross-service user flows that are nearly impossible to document by hand.
- Multi-repo products — backend in one repo, frontend in another, mobile in a third. CodeWiki scans them all and maps the connections.
- SaaS products — complex user flows, subscription logic, webhook integrations, admin dashboards. The kind of product where onboarding a new engineer takes weeks.
- Internal tools and admin platforms — CRUD-heavy apps with role-based access, approval workflows, and integrations with third-party services.
- Libraries and SDKs — CodeWiki can document the API surface, but it's designed for products with user flows, not standalone packages. You'll get architecture and API docs, but user flow documentation won't be as useful.
- CLI tools — works for mapping commands, flags, and internal structure, but the user flow model (screens, pages, API calls) doesn't map as naturally.
- Data pipelines and ETL — CodeWiki can document the services and their connections, but it doesn't have specialized templates for DAGs, scheduling, or data lineage.
- Single-file scripts or utilities — if your project is a handful of files, CodeWiki is overkill. Just write the CLAUDE.md by hand.
- Machine learning model repos — training pipelines, notebooks, experiment configs. CodeWiki doesn't understand model architectures, hyperparameters, or dataset structures.
- Infrastructure-only repos — pure Terraform, Helm charts, or Ansible playbooks without application code. CodeWiki is built around application architecture, not infrastructure-as-code.
- Massive monoliths (500k+ lines) — CodeWiki manages context carefully, but extremely large single-repo codebases may hit Claude's context limits before the scan completes. Multi-repo projects handle this better because each repo is scanned independently.
CodeWiki is a prompt-based skill — it guides Claude's behavior but doesn't guarantee identical output every time. Results depend on Claude's interpretation of your codebase, the quality of product context you provide, and the model version you're running.
- Review before committing. Always read the generated docs before pushing to a shared or public repo. While CodeWiki avoids writing secret values, it may reference internal service names, endpoint paths, or architecture details you'd prefer to keep private.
- Not a substitute for real documentation. CodeWiki gives you a strong starting point and keeps it maintainable. But domain nuance, decision rationale, and institutional knowledge still need a human.
- Accuracy varies by project complexity. Straightforward web apps produce highly accurate output. Complex event-driven microservices may need more corrections during the interactive confirmation steps — that's why CodeWiki asks you to verify before generating.
MIT — use it however you want. Personal projects, commercial products, modify it, redistribute it, sell something built on top of it. No attribution required (but appreciated).
See LICENSE for the full text.