| name | gsd-thread |
| description | Manage persistent context threads for cross-session work |
| metadata | {"short-description":"Manage persistent context threads for cross-session work"} |
<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>
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.
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:
-
Generate slug from description:
SLUG=$(node "/Users/diegocaminor/Documents/proyectos/anyone-ai/final-project/AnyoneAIInterviewerBackend/.codex/get-shit-done/bin/gsd-tools.cjs" generate-slug "{{GSD_ARGS}}")
-
Create the threads directory if needed:
mkdir -p .planning/threads
-
Write the thread file:
cat > ".planning/threads/${SLUG}.md" << 'EOF'
{description}
*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
-
If there's relevant context in the current conversation (code snippets,
error messages, investigation results), extract and add it to the Context
section.
-
Commit:
node "/Users/diegocaminor/Documents/proyectos/anyone-ai/final-project/AnyoneAIInterviewerBackend/.codex/get-shit-done/bin/gsd-tools.cjs" commit "docs: create thread — ${ARGUMENTS}" --files ".planning/threads/${SLUG}.md"
-
Report:
## 🧵 Thread Created
Thread: {slug}
File: .planning/threads/{slug}.md
Resume anytime with: $gsd-thread {slug}
</mode_create>
- 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