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 skills add yuri-semenenko/ai-engineering-workspace --skill codebase-mapgit clone --depth 1 https://github.com/yuri-semenenko/ai-engineering-workspaceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/codebase-map)<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/codebase-map"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/codebase-map/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yuri-semenenko/ai-engineering-workspace/codebase-map"><img src="https://agentmods.dev/badge/skills/yuri-semenenko/ai-engineering-workspace/codebase-map.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00000 | $0.01033 |
| Opus 5.5 | $0.00000 | $0.00413 |
| Sonnet 5.5 | $0.00000 | $0.00207 |
| Haiku 4.5 | $0.00000 | $0.00103 |
Grade A, and why
codebase-map 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 1mo 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 — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Codebase Map
Build a fast, honest orientation to code you don't know yet, so you (or an agent you're about to point at it) can work in it safely. This is reconnaissance for comprehension: what the code is, where it starts, how it flows, and what not to touch. It is a map, not a tour — pointers over prose, evidence over guesses.
How to run (keep main context lean)
- Scope it. If a path argument was given, map that subtree; otherwise the whole repo. Read the obvious roots first: README,
package.json(scripts + deps), the top-level layout, and any existingAGENTS.md/CLAUDE.md/ architecture docs. - Fan out, do not grep inline. Per the persona's session-hygiene rule, dispatch
Exploresubagents — one per subsystem or question (entry points, data flow, domain terms, tests/tooling) — each returning a compact findings list, not file dumps. This keeps large intermediate output out of the main conversation. - Assemble the map from what came back. Merge, resolve contradictions rather than smoothing them over, and cite where each fact lives.
What the map captures
- What it is. One paragraph: the purpose and the domain it serves. From the README and the shape of the code, not the marketing.
- Entry points. Where execution actually starts — server/main, routes or pages, CLI commands, cron/queue workers, build entry. The "start here" files.
- Architecture sketch. The handful of layers or modules that matter and how data flows between them. A few boxes and arrows in prose, not a file tree.
- Domain glossary. The ubiquitous language: the 5-15 domain nouns and verbs that recur, one line each. The vocabulary you need to read the code and talk to the team.
- Key seams. The stable interfaces and boundaries where behavior is substituted or extended (see /module-design for the vocabulary). Where you would attach a test or a new implementation.
- Risky / don't-touch areas. Load-bearing, security-sensitive, or historically fragile code, and the invariants not to regress. Mark it; do not "fix" it (Chesterton's Fence).
- How to run and test. Build/dev/test/single-test commands, local setup, required env vars — from repo evidence, not guesses. Say so when something is unknown.
- Known tradeoffs. Existing
TRADEOFF(...)annotations, TODOs of record, and documented debt (feeds /debt-ledger).
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.
- 1mo ago First seen · 45 lines · 0 tokens per session scan A 555e4ef2fe41
codebase-map is a skill published in the GitHub repository yuri-semenenko/ai-engineering-workspace (4 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,033 tokens. 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-31.
Other skills, from other repositories
spec-kitty-charter-doctrine
Run charter interview, generation, context, and sync workflows for project governance in Spec Kitty 3.x. Access doctrine artifacts programmatically via DoctrineService. Resolve agent profiles. Load action-scoped governance context iteratively, not all at once. Triggers: "interview for charter", "generate charter"…
110-java-maven-best-practices
Use when you need to review, improve, or troubleshoot a Maven pom.xml file — including dependency management with BOMs, plugin configuration, version centralization, multi-module project structure, build profiles, or any situation where you want to align your Maven setup with industry best practices. This should…
128-java-generics
Use when you need to review, improve, or refactor Java code for generics quality — including avoiding raw types, applying the PECS (Producer Extends Consumer Super) principle for wildcards, using bounded type parameters, designing effective generic methods, leveraging the diamond operator, understanding type erasure…
322-frameworks-spring-boot-testing-integration-tests
Use when you need to write or improve integration tests — including Testcontainers with @ServiceConnection, @DataJdbcTest persistence slices, TestRestTemplate or MockMvcTester for HTTP, data isolation, and container lifecycle management for Spring Boot 4.0.x. This should trigger for requests such as Review Java code…
422-frameworks-quarkus-testing-integration-tests
Use when you need to write or improve integration tests for Quarkus — including @QuarkusTest, Dev Services for automatic container provisioning, Testcontainers via QuarkusTestResourceLifecycleManager, WireMock for external HTTP stubs, @QuarkusIntegrationTest for black-box testing against packaged artifacts, REST…
521-frameworks-micronaut-testing-unit-tests
Use when you need to write unit tests for Micronaut applications — Mockito-first with @ExtendWith(MockitoExtension.class), @MicronautTest with @MockBean, HttpClient @Client(/) assertions, @Property overrides, @ParameterizedTest, and Test vs IT naming. For framework-agnostic Java use @131-java-testing-unit-testing.…