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-forensics3description: Post-mortem investigation for failed GSD workflows — analyzes git history, artifacts, and state to diagnose what went wrong4---56<codex_skill_adapter>7## A. Skill Invocation8- This skill is invoked by mentioning `$gsd-forensics`.9- Treat all user text after `$gsd-forensics` as `{{GSD_ARGS}}`.10- If no arguments are present, treat `{{GSD_ARGS}}` as empty.1112## B. AskUserQuestion → request_user_input Mapping13GSD workflows use `AskUserQuestion` (Claude Code syntax). Translate to Codex `request_user_input`:1415Parameter mapping:16- `header` → `header`17- `question` → `question`18- Options formatted as `"Label" — description` → `{label: "Label", description: "description"}`19- Generate `id` from header: lowercase, replace spaces with underscores2021Batched calls:22- `AskUserQuestion([q1, q2])` → single `request_user_input` with multiple entries in `questions[]`2324Multi-select workaround:25- Codex has no `multiSelect`. Use sequential single-selects, or present a numbered freeform list asking the user to enter comma-separated numbers.2627Execute mode fallback:28- When `request_user_input` is rejected (Execute mode), present a plain-text numbered list and pick a reasonable default.2930## C. Task() → spawn_agent Mapping31GSD workflows use `Task(...)` (Claude Code syntax). Translate to Codex collaboration tools:3233Direct mapping:34- `Task(subagent_type="X", prompt="Y")` → `spawn_agent(agent_type="X", message="Y")`35- `Task(model="...")` → omit (Codex uses per-role config, not inline model selection)36- `fork_context: false` by default — GSD agents load their own context via `<files_to_read>` blocks3738Parallel fan-out:39- Spawn multiple agents → collect agent IDs → `wait(ids)` for all to complete4041Result parsing:42- Look for structured markers in agent output: `CHECKPOINT`, `PLAN COMPLETE`, `SUMMARY`, etc.43- `close_agent(id)` after collecting results from each agent44</codex_skill_adapter>4546<objective>47Investigate 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.4849Purpose: Diagnose failed or stuck workflows so the user can understand root cause and take corrective action.50Output: Forensic report saved to `.planning/forensics/`, presented inline, with optional issue creation.51</objective>5253<execution_context>54@/home/delorenj/code/bhappy/.codex/get-shit-done/workflows/forensics.md55</execution_context>5657<context>58**Data sources:**59- `git log` (recent commits, patterns, time gaps)60- `git status` / `git diff` (uncommitted work, conflicts)61- `.planning/STATE.md` (current position, session history)62- `.planning/ROADMAP.md` (phase scope and progress)63- `.planning/phases/*/` (PLAN.md, SUMMARY.md, VERIFICATION.md, CONTEXT.md)64- `.planning/reports/SESSION_REPORT.md` (last session outcomes)6566**User input:**67- Problem description: {{GSD_ARGS}} (optional — will ask if not provided)68</context>6970<process>71Read and execute the forensics workflow from @/home/delorenj/code/bhappy/.codex/get-shit-done/workflows/forensics.md end-to-end.72</process>7374<success_criteria>75- Evidence gathered from all available data sources76- At least 4 anomaly types checked (stuck loop, missing artifacts, abandoned work, crash/interruption)77- Structured forensic report written to `.planning/forensics/report-{timestamp}.md`78- Report presented inline with findings, anomalies, and recommendations79- Interactive investigation offered for deeper analysis80- GitHub issue creation offered if actionable findings exist81</success_criteria>8283<critical_rules>84- **Read-only investigation:** Do not modify project source files during forensics. Only write the forensic report and update STATE.md session tracking.85- **Redact sensitive data:** Strip absolute paths, API keys, tokens from reports and issues.86- **Ground findings in evidence:** Every anomaly must cite specific commits, files, or state data.87- **No speculation without evidence:** If data is insufficient, say so — do not fabricate root causes.88</critical_rules>