agentleFS
Sign inStart free
metaspartanmetaspartan/cybara/skills/code-wiki/SKILL.md

code-wiki

Skill38 starsChanged 5 months agoMITView on GitHub

Generate architecture wiki docs, module maps, and Mermaid diagrams for a codebase using Cybara file/search/write tools.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this when the user asks to document a repository, generate architecture diagrams, create a code wiki, or onboard to an unfamiliar …

    line 9
  2. Very specific:

    Default to ~/.cybara/wikis/<repo-name>/ so active repositories are not modified.

    line 15
  3. Distinctive:

    If the user gave a local path, use that path.

    line 20
  4. Very specific:

    If they gave a GitHub URL, clone with git clone --depth 50 <url> <tmp>/repo.

    line 21
  5. Distinctive:

    Read the README, manifests, and main entry points:

    line 25
  6. Distinctive:

    Every statement should trace to code, config, or docs you read.

    line 39
  7. Distinctive:

    Use relative links for local output.

    line 40
  8. Very specific:

    Keep Mermaid valid and readable.

    line 41
  9. Distinctive:

    Do not document generated bundles or dependency directories.

    line 42
  10. Distinctive:

    Do not claim coverage of the whole repo when you only sampled modules.

    line 43
  11. Distinctive:

    After writing the wiki:

    line 47
  12. Distinctive:

    Read the generated README.md and one module page before reporting paths back to the user.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Code Wiki

Use this when the user asks to document a repository, generate architecture diagrams, create a code wiki, or onboard to an unfamiliar codebase.

This is a reference-documentation workflow. It explains what exists and how it fits together; it is not a product strategy or roadmap exercise.

Output Location

Default to ~/.cybara/wikis/<repo-name>/ so active repositories are not modified. Only write under the repo, such as docs/wiki/, when the user explicitly asks for in-repo documentation.

Workflow

  1. Resolve the target repository.
    • If the user gave a local path, use that path.
    • If they gave a GitHub URL, clone with git clone --depth 50 <url> <tmp>/repo.
    • Record git rev-parse HEAD when available.
  2. Scan the structure with rg --files, excluding generated and dependency dirs:
    • .git, node_modules, dist, build, target, .next, .expo, coverage, venv, .venv.
  3. Read the README, manifests, and main entry points:
    • package.json, bun.lock, Cargo.toml, pyproject.toml, go.mod, Package.swift, app entry files.
  4. Pick 8-10 modules for the first pass.
    • Prioritize entry points, shared/core modules, API boundaries, UI route roots, persistence layers, and integration adapters.
  5. Write:
    • README.md with purpose, concepts, entry points, and module map.
    • architecture.md with a Mermaid flowchart.
    • modules/<module>.md for each selected module.
    • diagrams/sequences.md with 2-4 key workflows.
    • getting-started.md with verified local commands.
    • .codewiki-state.json with repo path, commit, generated time, and files reviewed.

Quality Bar

  • Every statement should trace to code, config, or docs you read.
  • Use relative links for local output; use commit-pinned GitHub links for cloned public repos.
  • Keep Mermaid valid and readable. Prefer flowchart LR for architecture and sequenceDiagram for workflows.
  • Do not document generated bundles or dependency directories.
  • Do not claim coverage of the whole repo when you only sampled modules; list gaps explicitly.

Verification

After writing the wiki:

find "$OUTPUT_DIR" -type f | sort
rg -n "TODO|TBD|unknown" "$OUTPUT_DIR" || true

Read the generated README.md and one module page before reporting paths back to the user.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free