Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/dvnghiem/flowdeck/codebase-mappingnpx skills add DVNghiem/FlowDeck --skill codebase-mappinggit clone --depth 1 https://github.com/DVNghiem/FlowDeckWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00036 | $0.00677 |
| Opus 5 | $0.00018 | $0.00338 |
| Sonnet 5 | $0.00007 | $0.00135 |
| Haiku 4.5 | $0.00004 | $0.00068 |
Grade A, and why
codebase-mapping scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Codebase Mapping Skill
Produces structured documentation of a codebase that agents can read to answer "how does this project work?" without re-scanning every time.
When to Activate
- Starting work on an unfamiliar codebase
- Before a major feature that spans multiple modules
- When
/fd-taskruns its init step for an unmapped project - When
~/.fd-plan/<slug>/.codebase/is missing or stale
Output Files
All outputs go to ~/.fd-plan/<slug>/.codebase/:
| File | Contents |
|---|---|
ARCHITECTURE.md |
System design: layers, modules, data flow |
CONVENTIONS.md |
Naming, style, patterns specific to this project |
DEPENDENCIES.md |
Key external packages and what they do |
INDEX.md |
File-by-file inventory |
ENTRY_POINTS.md |
How the application starts and key entry files |
Mapping Sequence
Step 1: Start from the outside
Read in this order:
package.json/pyproject.toml/Cargo.toml— dependencies, scripts, metadataREADME.md— stated purpose and architecture- Entry point files (main, index, app, server)
- Configuration files (env examples, config schemas)
Step 2: Map the directory structure
Document each top-level directory's purpose:
src/
api/ — HTTP route handlers
services/ — Business logic
models/ — Database schemas and queries
utils/ — Shared helpers
tests/ — Test files (mirror of src/)
scripts/ — Build and deployment scripts
Do not guess. Read the files to confirm what each directory contains.
Step 3: Document key conventions
Find examples in the code:
- How are errors handled? (throw? return Result? error callback?)
- How are modules exported? (default export? named exports?)
- What is the naming pattern for files? (
UserService.ts?user-service.ts?) - Where do interfaces/types live?
- How is dependency injection done?
Write 1-2 examples for each pattern, not a generic description.
Step 4: Document entry points
## Entry Points
- `src/index.ts` — Application bootstrap, registers routes and middleware
- `src/workers/queue.ts` — Background job processor, runs independently
- `scripts/migrate.ts` — Database migration runner
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 88 lines · 36 tokens per session scan A 704bac990f4a
codebase-mapping is a skill published in the GitHub repository DVNghiem/FlowDeck (24 stars, last pushed 13d ago), licensed MIT. It adds 36 tokens to every session and 677 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
oh-my-opencode-slim
Configure and improve oh-my-opencode-slim for the current user. Use when users want to tune agents, models, prompts, custom agents, skills, MCPs, presets, or plugin behavior. Also use when recurring workflow friction suggests a safe config or prompt improvement.
reflect
Review recent work, find repeated workflow patterns, and suggest reusable skills, agents, commands, config changes, or playbooks. Use when the user asks to learn from past sessions, improve recurring workflows, or identify what should be turned into reusable agent instructions.
clonedeps
Clone important project dependency source code into an ignored local workspace so OpenCode can inspect library internals. Use when the user asks to clone dependencies, inspect dependency/source internals, understand SDK/framework behavior from source, debug library implementation details, or make core dependency repos…
codemap
Generate comprehensive hierarchical codemaps for UNFAMILIAR repositories. Expensive operation - only use when explicitly asked for codebase documentation or initial repository mapping.
deepwork
High-cost orchestrator workflow for large, high-risk, multi-phase coding efforts with meaningful dependencies and review gates. Do not activate for routine multi-file changes.
worktrees
Manage Git worktrees as OMO safe isolated coding lanes for complex, risky, or parallel work.