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
Purpose: Diagnose failed or stuck workflows so the user can understand root cause and take corrective action.
Output: Forensic report saved to .planning/forensics/, presented inline, with optional issue creation.
User input:
- Problem description: {{GSD_ARGS}} (optional — will ask if not provided)
1---2name: "gsd-forensics"3description: "Post-mortem investigation for failed GSD workflows — analyzes git history, artifacts, and state to diagnose what went wrong"4metadata:5 short-description: "Post-mortem investigation for failed GSD workflows — analyzes git history, artifacts, and state to diagnose what went wrong"6---78<codex_skill_adapter>9## A. Skill Invocation10- This skill is invoked by mentioning `$gsd-forensics`.11- Treat all user text after `$gsd-forensics` as `{{GSD_ARGS}}`.12- If no arguments are present, treat `{{GSD_ARGS}}` as empty.1314## B. AskUserQuestion → request_user_input Mapping15GSD workflows use `AskUserQuestion` (Claude Code syntax). Translate to Codex `request_user_input`:1617Parameter mapping:18- `header` → `header`19- `question` → `question`20- Options formatted as `"Label" — description` → `{label: "Label", description: "description"}`21- Generate `id` from header: lowercase, replace spaces with underscores2223Batched calls:24- `AskUserQuestion([q1, q2])` → single `request_user_input` with multiple entries in `questions[]`2526Multi-select workaround:27- Codex has no `multiSelect`. Use sequential single-selects, or present a numbered freeform list asking the user to enter comma-separated numbers.2829Execute mode fallback:30- When `request_user_input` is rejected (Execute mode), present a plain-text numbered list and pick a reasonable default.3132## C. Task() → spawn_agent Mapping33GSD workflows use `Task(...)` (Claude Code syntax). Translate to Codex collaboration tools:3435Direct mapping:36- `Task(subagent_type="X", prompt="Y")` → `spawn_agent(agent_type="X", message="Y")`37- `Task(model="...")` → omit (Codex uses per-role config, not inline model selection)38- `fork_context: false` by default — GSD agents load their own context via `<files_to_read>` blocks3940Parallel fan-out:41- Spawn multiple agents → collect agent IDs → `wait(ids)` for all to complete4243Result parsing:44- Look for structured markers in agent output: `CHECKPOINT`, `PLAN COMPLETE`, `SUMMARY`, etc.45- `close_agent(id)` after collecting results from each agent46</codex_skill_adapter>4748<objective>49Investigate what went wrong during a GSD workflow execution. Analyzes git history, `.planning/` artifacts, and file system state to detect anomalies and generate a structured diagnostic report.5051Purpose: Diagnose failed or stuck workflows so the user can understand root cause and take corrective action.52Output: Forensic report saved to `.planning/forensics/`, presented inline, with optional issue creation.53</objective>5455<execution_context>56@/Users/richardhightower/clients/spillwave/src/agent-brain/.codex/get-shit-done/workflows/forensics.md57</execution_context>5859<context>60**Data sources:**61- `git log` (recent commits, patterns, time gaps)62- `git status` / `git diff` (uncommitted work, conflicts)63- `.planning/STATE.md` (current position, session history)64- `.planning/ROADMAP.md` (phase scope and progress)65- `.planning/phases/*/` (PLAN.md, SUMMARY.md, VERIFICATION.md, CONTEXT.md)66- `.planning/reports/SESSION_REPORT.md` (last session outcomes)6768**User input:**69- Problem description: {{GSD_ARGS}} (optional — will ask if not provided)70</context>7172<process>73Read and execute the forensics workflow from @/Users/richardhightower/clients/spillwave/src/agent-brain/.codex/get-shit-done/workflows/forensics.md end-to-end.74</process>7576<success_criteria>77- Evidence gathered from all available data sources78- At least 4 anomaly types checked (stuck loop, missing artifacts, abandoned work, crash/interruption)79- Structured forensic report written to `.planning/forensics/report-{timestamp}.md`80- Report presented inline with findings, anomalies, and recommendations81- Interactive investigation offered for deeper analysis82- GitHub issue creation offered if actionable findings exist83</success_criteria>8485<critical_rules>86- **Read-only investigation:** Do not modify project source files during forensics. Only write the forensic report and update STATE.md session tracking.87- **Redact sensitive data:** Strip absolute paths, API keys, tokens from reports and issues.88- **Ground findings in evidence:** Every anomaly must cite specific commits, files, or state data.89- **No speculation without evidence:** If data is insufficient, say so — do not fabricate root causes.90</critical_rules>