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 qGolem/orc --skill mapgit clone --depth 1 https://github.com/qGolem/orcWrote 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/qgolem/orc/map)<a href="https://agentmods.dev/skills/qgolem/orc/map"><img src="https://agentmods.dev/badge/skills/qgolem/orc/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/qgolem/orc/map"><img src="https://agentmods.dev/badge/skills/qgolem/orc/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.00016 | $0.07350 |
| Opus 5.5 | $0.00006 | $0.02940 |
| Sonnet 5.5 | $0.00003 | $0.01470 |
| Haiku 4.5 | $0.00002 | $0.00735 |
Grade A, and why
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 — 918 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Each wave builds on prior waves — later agents read earlier documents instead of re-exploring the same ground. This eliminates duplication and produces focused, non-overlapping output.
Output: .claude/context/ folder with 16 structured documents, each ≤200 lines.
Why waves: Parallel-only deployment causes agents to independently discover the same structure, stack, and patterns — producing 3-4 files that overlap on architecture, naming, validation, etc. Waves let foundation docs (STACK, STRUCTURE) be written first, then referenced by all subsequent agents.
Why ≤200 lines: Documents are reference material loaded into context. Bloated files waste tokens. Prefer tables over prose, examples over explanations. If a topic is covered in another doc, write "See [DOC].md" instead of repeating.
Upstream enrichment: Wave 2+ agents may update prior-wave documents if they discover information that would improve output for later waves. For example, a Wave 2 architecture agent might add entry points it discovered to STRUCTURE.md, or a Wave 3 patterns agent might add a convention it found to CONVENTIONS.md. Append to the relevant section — never delete or rewrite existing content.
Why dedicated mapper agents:
- Fresh context per domain (no token contamination)
- Agents write documents directly (no context transfer back to orchestrator)
- Orchestrator only summarizes what was created (minimal context usage)
Always include file paths:
Documents are reference material for Claude when planning/executing. Always include actual file paths formatted with backticks: src/services/user.ts.
Target directory: .claude/context/
This command can run:
- Before
/orc(brownfield codebases) -- creates codebase map first - After
/orc(greenfield codebases) -- updates codebase map as code evolves - Anytime to refresh codebase understanding
<when_to_use> Use orc-map for:
- Brownfield projects before planning (understand existing code first)
- Refreshing codebase map after significant changes
- Onboarding to an unfamiliar codebase
- Before major refactoring (understand current state)
Skip orc-map for:
- Greenfield projects with no code yet (nothing to map)
- Trivial codebases (<5 files) </when_to_use>
Step 1: Check existing maps
ls -la .claude/context/ 2>/dev/null && echo "has_maps=true" || echo "has_maps=false"
If context/ already exists:
Present options:
AskUserQuestion:
header: "Existing"
question: ".claude/context/ already exists. What should we do?"
options:
- label: "Refresh"
description: "Delete existing and remap codebase"
- label: "Skip"
description: "Use existing codebase map as-is"
If "Refresh": Delete context/, continue to step 2 If "Skip": Exit workflow
If doesn't exist: Continue to step 2.
Step 2: Create directory structure
mkdir -p .claude/context
Expected output files (16 documents across 4 waves):
Wave 1 — Foundation:
- STACK.md, STRUCTURE.md, HISTORY.md
Wave 2 — Architecture & Conventions:
- ARCHITECTURE.md, CONVENTIONS.md, INTEGRATIONS.md, REPO.md
Wave 3 — Deep Analysis:
- PATTERNS.md, TYPES.md, TESTING.md, CODEMAP.md, UX-PATTERNS.md
Wave 4 — Cross-Cutting:
- BOUNDARIES.md, FLOWS.md, CONCERNS.md, TEST-QUALITY.md
Step 3a: Wave 1 — Foundation (3 parallel agents)
These are discovery agents with no prior context. They establish the facts that all later waves reference.
If $ARGUMENTS contains a prompt, append it to each agent's prompt as a <focus_hint> block.
Agent 1: Stack
Task(
subagent_type="orc:orc-codebase-mapper",
run_in_background=true,
description="Map codebase tech stack",
prompt="Focus: tech stack
Analyze this codebase for its technology stack and configuration.
Write to .claude/context/:
- STACK.md (max 150 lines)
Include:
- Languages, runtime versions, package manager
- Frameworks and key dependencies (with versions)
- Build tools, bundlers, task runners
- Environment configuration model (env files, config patterns)
- Dev vs production differences
Use tables for dependency listings. Be concise.
<focus_hint>$ARGUMENTS</focus_hint>
Explore thoroughly. Write document directly. Return confirmation only."
)
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 · 918 lines · 0 tokens per session scan A 53445b892edb
map is a skill published in the GitHub repository qGolem/orc (5 stars, last pushed 7mo ago), licensed MIT. It adds 16 tokens to every session and 7,350 once invoked, about $0.0001 per session on Opus 5.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-31.
Other skills, from other repositories
new-skill
Scaffold a new brooks-lint analysis skill so it passes npm run validate and npm run evals on the first try — generates skills/{name}/SKILL.md (with the mandatory "Do NOT trigger for:" clause and a Process section citing guide step ranges) plus skills/{name}/{name}-guide.md (sequentially numbered steps), then appends…
llm-friendly-context
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream consumers can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
apex-review
Cross-cutting review of recent work — catches gaps between specialists. Use when asked to "review what we built", "check the work", "pre-launch review", or after completing a significant chunk of work.
prompt-tuning
Tune a prompt, or anything whose quality is measured by non-deterministic model output, without chasing noise - a noise baseline before the first edit, medians over repeated runs, enforcement AFTER generation rather than in the wording. Use when iterating on prompts or model-judged output.
brainstorm
Explores a codebase, researches the problem space, and produces an approved design specification before any code is written. Use when the user wants to create a new feature, add significant functionality, redesign a subsystem, or build something that touches multiple parts of the project.
performance-audit
Full-stack performance health check across 12 dimensions. Rendering, bundles, assets, API/network, algorithms, memory, database, caching, Web Vitals, backend runtime, concurrency, and framework-specific pathologies. Evidence-based Impact Models with confidence tiers and a prioritized optimization roadmap. Switches…