| name | gsd-map-codebase |
| description | Analyze codebase with parallel mapper agents to produce .planning/codebase/ documents |
| metadata | {"short-description":"Analyze codebase with parallel mapper agents to produce .planning/codebase/ documents"} |
<codex_skill_adapter>
A. Skill Invocation
- This skill is invoked by mentioning
$gsd-map-codebase.
- Treat all user text after
$gsd-map-codebase as {{GSD_ARGS}}.
- If no arguments are present, treat
{{GSD_ARGS}} as empty.
B. AskUserQuestion → request_user_input Mapping
GSD workflows use AskUserQuestion (Claude Code syntax). Translate to Codex request_user_input:
Parameter mapping:
header → header
question → question
- Options formatted as
"Label" — description → {label: "Label", description: "description"}
- Generate
id from header: lowercase, replace spaces with underscores
Batched calls:
AskUserQuestion([q1, q2]) → single request_user_input with multiple entries in questions[]
Multi-select workaround:
- Codex has no
multiSelect. Use sequential single-selects, or present a numbered freeform list asking the user to enter comma-separated numbers.
Execute mode fallback:
- When
request_user_input is rejected (Execute mode), present a plain-text numbered list and pick a reasonable default.
C. Task() → spawn_agent Mapping
GSD workflows use Task(...) (Claude Code syntax). Translate to Codex collaboration tools:
Direct mapping:
Task(subagent_type="X", prompt="Y") → spawn_agent(agent_type="X", message="Y")
Task(model="...") → omit (Codex uses per-role config, not inline model selection)
fork_context: false by default — GSD agents load their own context via <files_to_read> blocks
Parallel fan-out:
- Spawn multiple agents → collect agent IDs →
wait(ids) for all to complete
Result parsing:
- Look for structured markers in agent output:
CHECKPOINT, PLAN COMPLETE, SUMMARY, etc.
close_agent(id) after collecting results from each agent
</codex_skill_adapter>
Analyze existing codebase using parallel gsd-codebase-mapper agents to produce structured codebase documents.
Each mapper agent explores a focus area and writes documents directly to .planning/codebase/. The orchestrator only receives confirmations, keeping context usage minimal.
Output: .planning/codebase/ folder with 7 structured documents about the codebase state.
<execution_context>
@/Users/teo/src/tempo/.codex/get-shit-done/workflows/map-codebase.md
</execution_context>
Focus area: {{GSD_ARGS}} (optional - if provided, tells agents to focus on specific subsystem)
Load project state if exists:
Check for .planning/STATE.md - loads context if project already initialized
This command can run:
- Before $gsd-new-project (brownfield codebases) - creates codebase map first
- After $gsd-new-project (greenfield codebases) - updates codebase map as code evolves
- Anytime to refresh codebase understanding
<when_to_use>
Use map-codebase for:
- Brownfield projects before initialization (understand existing code first)
- Refreshing codebase map after significant changes
- Onboarding to an unfamiliar codebase
- Before major refactoring (understand current state)
- When STATE.md references outdated codebase info
Skip map-codebase for:
- Greenfield projects with no code yet (nothing to map)
- Trivial codebases (<5 files)
</when_to_use>
1. Check if .planning/codebase/ already exists (offer to refresh or skip)
2. Create .planning/codebase/ directory structure
3. Spawn 4 parallel gsd-codebase-mapper agents:
- Agent 1: tech focus → writes STACK.md, INTEGRATIONS.md
- Agent 2: arch focus → writes ARCHITECTURE.md, STRUCTURE.md
- Agent 3: quality focus → writes CONVENTIONS.md, TESTING.md
- Agent 4: concerns focus → writes CONCERNS.md
4. Wait for agents to complete, collect confirmations (NOT document contents)
5. Verify all 7 documents exist with line counts
6. Commit codebase map
7. Offer next steps (typically: $gsd-new-project or $gsd-plan-phase)
<success_criteria>