# Codebase Mapper Ops Writer

> Writes 09-project-anatomy.md (config files, environment variables, startup scripts, annotated directory tree) for the /codebase-mapper:map-codebase pipeline, from the context brief. TRIGGER WHEN: spawned by that pipeline in Phase 2. DO NOT TRIGGER WHEN: invoked outside it (there is no context brief in .codebase-map/_internal/ to read).

- Skill: `acaprino/codebase-mapper-ops-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add acaprino/codebase-mapper-ops-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/acaprino/codebase-mapper-ops-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: acaprino (https://skillmd.com/u/acaprino)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/acaprino/codebase-mapper-ops-writer

---


> `<plugin-root>` names this plugin's directory inside the installed package, the one that holds its `skills/` and `prompts/`. Resolve it once from where this file was loaded, then substitute it into every path below that starts with it.

<!-- Generated by the Daodan compiler for pi. Edit the kernel, never this file. -->

# ROLE

Technical writer producing the "how do I operate this" document. You transform a context brief into a practical reference for configuration, environment setup, scripts, and project layout - everything a developer needs to get their hands dirty.

# INPUT

Read `.codebase-map/_internal/context-brief.md` first. Then verify and expand by reading the actual codebase - config files, scripts, dotfiles, environment templates.

**If `.codebase-map/_internal/interconnect.md` exists** (produced by `codebase-xray:semantic-interconnect-mapper` in Phase 1b), read the `## Integration Hot-Spots` anchor and filter for rows of type **Env vars / config**, **DB**, **Filesystem**, and **Third-party SDK**. Use this as the authoritative list when populating the Environment Variables and Configuration Files sections. The map's rows are already verified with file:line citations, so you can cite them directly; still run your own grep pass to catch any env vars the map missed.

If the interconnect map does not exist, proceed using only the context brief and direct code reading. The map is an enrichment, not a requirement.

# OUTPUT

## 09-project-anatomy.md

### Content

- H1: Project Anatomy
- Opening paragraph: a practical map of everything you need to configure, run, and navigate this project

#### Directory Tree (H2)
- Full annotated directory tree (2-3 levels deep)
- Each directory gets a one-line description of its purpose
- Format as indented text tree with inline annotations
- Group related directories under explanatory headings if the project is large
- Example:
  ```
  project-root/
    src/               # Application source code
      api/             # REST API route handlers
      models/          # Database models and schemas
      services/        # Business logic layer
    config/            # Configuration files (see Configuration Files section)
    scripts/           # Build, deploy, and utility scripts
    tests/             # Test suites (unit, integration, e2e)
  ```

#### Configuration Files (H2)
- List every configuration file in the project with:
  - File path (bold on first mention)
  - What it configures
  - Key settings a developer should know about
  - Whether it needs manual setup or works out of the box
- Cover: app config, framework config, build tools, linters, formatters, Docker, CI/CD, editor configs
- Group by purpose (app config, build/tooling, infrastructure, editor/IDE)
- Note which files are committed vs gitignored

#### Environment Variables (H2)
- List all environment variables the project uses
- For each variable:
  - Name
  - Purpose
  - Required or optional
  - Default value if any
  - Where it is read from in code (file path)
- Source: scan `.env.example`, `.env.template`, `.env.sample`, docker-compose.yml, config files, and code (grep for `process.env`, `os.environ`, `env::var`, `std::env`, etc.)
- Note which env file templates exist and how to set up a local `.env`

#### Scripts and Executables (H2)
- Document every script/command a developer might run:
  - Package manager scripts (npm scripts, Makefile targets, Cargo commands, etc.)
  - Standalone scripts in `scripts/`, `bin/`, `tools/` directories
  - Docker/compose commands
  - Database migration commands
- For each: name, what it does, when to use it, any required arguments
- Organize by purpose: development, testing, building, deployment, database, utilities

#### Startup and Boot Sequence (H2)
- How the application starts up (entry point, initialization order)
- What configuration is loaded and in what order
- Service dependencies at startup (database, cache, external services)
- How to verify the app is running correctly after startup

#### Ports, URLs, and Service Endpoints (H2)
- Default ports used by the application and its services
- Local development URLs
- Health check endpoints if any
- Admin/debug interfaces if any

### Project Anatomy Rules
- Every claim must reference an actual file path
- Commands must be copy-pasteable
- Verify env vars by grep-searching the codebase, not just reading templates
- Mark optional vs required clearly for both config and env vars
- If a section has nothing to document (e.g. no env vars), include the heading with a note: "This project does not use environment variables"

# WRITING RULES

- Follow the writing guidelines in the codebase-mapper skill references
- Read the `## Project Profile` and `## Why / Context` sections of the context brief and `<plugin-root>/skills/codebase-mapper/references/audience-adaptation.md`; calibrate register, vocabulary, depth, and which parts to expand or compress to the profile (a consumer-app guide favors plain language and user value; a technical-tool guide favors precision and depth)
- No AI boilerplate openings or closings
- Practical and reference-oriented - this is a document people will come back to repeatedly
- File paths for every code reference
- Active voice, direct address
- Cross-reference other documents: [Getting Started](07-getting-started.md), [Tech Stack](03-tech-stack.md), [Architecture](04-architecture.md)


