gsd-thread

<codex_skill_adapter>

A. Skill Invocation

• This skill is invoked by mentioning $gsd-thread.
• Treat all user text after $gsd-thread 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>

<objective> Create, list, or resume persistent context threads. Threads are lightweight cross-session knowledge stores for work that spans multiple sessions but doesn't belong to any specific phase. </objective> <process>

Parse {{GSD_ARGS}} to determine mode:

<mode_list> If no arguments or {{GSD_ARGS}} is empty:

List all threads:

ls .planning/threads/*.md 2>/dev/null

For each thread, read the first few lines to show title and status:

## Active Threads

| Thread | Status | Last Updated |
|--------|--------|-------------|
| fix-deploy-key-auth | OPEN | 2026-03-15 |
| pasta-tcp-timeout | RESOLVED | 2026-03-12 |
| perf-investigation | IN PROGRESS | 2026-03-17 |

If no threads exist, show:

No threads found. Create one with: $gsd-thread <description>

</mode_list>

<mode_resume> If {{GSD_ARGS}} matches an existing thread name (file exists):

Resume the thread — load its context into the current session:

cat ".planning/threads/${THREAD_NAME}.md"

Display the thread content and ask what the user wants to work on next. Update the thread's status to IN PROGRESS if it was OPEN. </mode_resume>

<mode_create> If {{GSD_ARGS}} is a new description (no matching thread file):

Create a new thread:

1. Generate slug from description:

   SLUG=$(node "/Users/richardhightower/clients/spillwave/src/agent-brain/.codex/get-shit-done/bin/gsd-tools.cjs" generate-slug "{{GSD_ARGS}}")
   

2. Create the threads directory if needed:

   mkdir -p .planning/threads
   

3. Write the thread file:

   cat > ".planning/threads/${SLUG}.md" << 'EOF'
   # Thread: {description}
   
   ## Status: OPEN
   
   ## Goal
   
   {description}
   
   ## Context
   
   *Created from conversation on {today's date}.*
   
   ## References
   
   - *(add links, file paths, or issue numbers)*
   
   ## Next Steps
   
   - *(what the next session should do first)*
   EOF
   

4. If there's relevant context in the current conversation (code snippets, error messages, investigation results), extract and add it to the Context section.

5. Commit:

   node "/Users/richardhightower/clients/spillwave/src/agent-brain/.codex/get-shit-done/bin/gsd-tools.cjs" commit "docs: create thread — ${ARGUMENTS}" --files ".planning/threads/${SLUG}.md"
   

6. Report:

   ## 🧵 Thread Created
   
   Thread: {slug}
   File: .planning/threads/{slug}.md
   
   Resume anytime with: $gsd-thread {slug}
   

</mode_create>

</process> <notes> - Threads are NOT phase-scoped — they exist independently of the roadmap - Lighter weight than $gsd-pause-work — no phase state, no plan context - The value is in Context and Next Steps — a cold-start session can pick up immediately - Threads can be promoted to phases or backlog items when they mature: $gsd-add-phase or $gsd-add-backlog with context from the thread - Thread files live in .planning/threads/ — no collision with phases or other GSD structures </notes>