with one click
cartography
Repository understanding and hierarchical codemap generation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Repository understanding and hierarchical codemap generation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Work inside a running marimo notebook's kernel — execute code, create cells, and build a notebook as an artifact. Use when the user wants to start a marimo notebook or work in an active marimo session.
Working on config and plugins for opencode
Hypothesis-driven debugging methodology: systematic investigation, binary search isolation, escalation criteria. Load when debugging complex, elusive, or multi-system bugs.
Systematic code refactoring methodology using ast-grep, comby, and manual transformations. Load when performing large-scale code restructuring or systematic transformations.
Deep research methodology: recursive exploration, branch-and-synthesize pattern, documentation structure. Load when conducting broad, open-ended research on technical or scientific topics.
Code review framework: 5-category evaluation, structured output format, severity levels. Load when performing thorough code reviews of changes, diffs, or pull requests.
| name | cartography |
| description | Repository understanding and hierarchical codemap generation |
You help users understand and map repositories by creating hierarchical codemaps.
First, check if .slim/cartography.json exists in the repo root.
If it exists: Skip to Step 3 (Detect Changes) - no need to re-initialize.
If it doesn't exist: Continue to Step 2 (Initialize).
src/**/*.ts, package.json, etc.**/*.test.ts, **/*.spec.ts, tests/**, __tests__/**docs/**, *.md (except root README.md if needed), LICENSEnode_modules/**, dist/**, build/**, *.min.js.gitignore automaticallypython3 ~/.config/opencode/skills/cartography/scripts/cartographer.py init \
--root ./ \
--include "src/**/*.ts" \
--exclude "**/*.test.ts" --exclude "dist/**" --exclude "node_modules/**"
This creates:
.slim/cartography.json - File and folder hashes for change detectioncodemap.md files in all relevant subdirectoriescodemap.md file.python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py changes \
--root ./
Review the output - It shows:
Only update affected codemaps - Spawn one explorer per affected folder to update its codemap.md.
Run update to save new state:
python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py update \
--root ./
Once all specific directories are mapped, the Orchestrator must create or update the root codemap.md. This file serves as the Master Entry Point for any agent or human entering the repository.
package.json, index.ts, plugin.json) and the project's overall purpose.codemap.md, extract its Responsibility summary and include it in a table or list in the root map.OpenCode auto-loads AGENTS.md into agent context on every session. To ensure agents automatically discover and use the codemap, update (or create) AGENTS.md at the repo root:
AGENTS.md already exists and already contains a ## Repository Map section, skip this step — the reference is already set up.AGENTS.md exists but has no ## Repository Map section, append the section below.AGENTS.md doesn't exist, create it with the section below.## Repository Map
A full codemap is available at `codemap.md` in the project root.
Before working on any task, read `codemap.md` to understand:
- Project architecture and entry points
- Directory responsibilities and design patterns
- Data flow and integration points between modules
For deep work on a specific folder, also read that folder's `codemap.md`.
This is idempotent — repeated cartography runs will detect the existing section and skip. No duplication.
Explorers are granted write permissions for codemap.md files during this workflow. Use precise technical terminology to document the implementation:
Example codemap:
# src/agents/
## Responsibility
Defines agent personalities and manages their configuration lifecycle.
## Design
Each agent is a prompt + permission set. Config system uses:
- Default prompts (orchestrator.ts, explorer.ts, etc.)
- User overrides from ~/.config/opencode/oh-my-opencode-slim.json
- Permission wildcards for skill/MCP access control
## Flow
1. Plugin loads → calls getAgentConfigs()
2. Reads user config preset
3. Merges defaults with overrides
4. Applies permission rules (wildcard expansion)
5. Returns agent configs to OpenCode
## Integration
- Consumed by: Main plugin (src/index.ts)
- Depends on: Config loader, skills registry
Example Root Codemap (Atlas):
# Repository Atlas: oh-my-opencode-slim
## Project Responsibility
A high-performance, low-latency agent orchestration plugin for OpenCode, focusing on specialized sub-agent delegation and background task management.
## System Entry Points
- `src/index.ts`: Plugin initialization and OpenCode integration.
- `package.json`: Dependency manifest and build scripts.
- `oh-my-opencode-slim.json`: User configuration schema.
## Directory Map (Aggregated)
| Directory | Responsibility Summary | Detailed Map |
|-----------|------------------------|--------------|
| `src/agents/` | Defines agent personalities (Orchestrator, Search) and manages model routing. | [View Map](src/agents/codemap.md) |
| `src/features/` | Core logic for tmux integration, background task spawning, and session state. | [View Map](src/features/codemap.md) |
| `src/config/` | Implements the configuration loading pipeline and environment variable injection. | [View Map](src/config/codemap.md) |