
Gsd Verify Work
- 1 installs
- 1 repo stars
- Updated May 10, 2026
- aesir-tecnologia/folhario
gsd-verify-work is a Claude Code skill that validates built features through conversational user-acceptance testing with persistent per-phase state.
About
gsd-verify-work is a Claude Code skill from the GSD workflow that validates built features through conversational user-acceptance testing. It runs one test at a time in plain language, records results to a {phase}-UAT.md file, and when issues surface it diagnoses the gaps and prepares verified fix plans for the execute-phase step. It includes a Codex adapter that maps Claude Code AskUserQuestion and Task calls onto Codex equivalents.
- Validates built features through conversational, one-test-at-a-time UAT
- Records results to a per-phase UAT.md file with persistent state
- On failures, diagnoses gaps and prepares fix plans for the execute step
Gsd Verify Work by the numbers
- 1 all-time installs (skills.sh)
- Ranked #1,750 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Jul 7, 2026 (Skillselion catalog sync)
gsd-verify-work capabilities & compatibility
- Capabilities
- feature verification · uat · test tracking
- Use cases
- testing · debugging
What gsd-verify-work says it does
Validate built features through conversational UAT
Confirm what the agent built actually works from user's perspective. One test at a time, plain text responses, no interrogation.
npx skills add https://github.com/aesir-tecnologia/folhario --skill gsd-verify-workAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 1 |
| Last updated | May 10, 2026 |
| Repository | aesir-tecnologia/folhario ↗ |
What it does
Confirm that features an agent built actually work from the user's perspective through conversational UAT.
When should I use this skill?
You want to confirm that what the agent just built works from the user's perspective, one test at a time.
What you get
A {phase}-UAT.md file tracking all test results, plus diagnosed gaps and verified fix plans when issues are found.
- Per-phase UAT.md file with all test results
- Diagnosed gaps and verified fix plans on failures
By the numbers
- Runs one test at a time with plain-text responses
- Writes results to a {phase_num}-UAT.md tracking file
Files
<codex_skill_adapter>
A. Skill Invocation
- This skill is invoked by mentioning
$gsd-verify-work. - Treat all user text after
$gsd-verify-workas{{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→headerquestion→question- Options formatted as
"Label" — description→{label: "Label", description: "description"} - Generate
idfrom header: lowercase, replace spaces with underscores
Batched calls:
AskUserQuestion([q1, q2])→ singlerequest_user_inputwith multiple entries inquestions[]
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_inputis rejected or unavailable, you MUST stop and present the questions as a plain-text numbered list, then wait for the user's reply. Do NOT pick a default and continue (#3018). - You may only proceed without a user answer when one of these is true:
(a) the invocation included an explicit non-interactive flag (--auto or --all), (b) the user has explicitly approved a specific default for this question, or (c) the workflow's documented contract says defaults are safe (e.g. autonomous lifecycle paths).
- Do NOT write workflow artifacts (CONTEXT.md, DISCUSSION-LOG.md, PLAN.md, checkpoint files) until the user has answered the plain-text questions or one of (a)-(c) above applies. Surfacing the questions and waiting is the correct response — silently defaulting and writing artifacts is the #3018 failure mode.
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.spawn_agenthas no inlinemodelparameter;
GSD embeds the resolved per-agent model directly into each agent's .toml at install time so model_overrides from .planning/config.json and ~/.gsd/defaults.json are honored automatically by Codex's agent router.
fork_context: falseby default — GSD agents load their own context via<files_to_read>blocks
Spawn restriction:
- Codex restricts
spawn_agentto cases where the user has explicitly
requested sub-agents. When automatic spawning is not permitted, do the work inline in the current agent rather than attempting to force a spawn.
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> Validate built features through conversational testing with persistent state.
Purpose: Confirm what the agent built actually works from user's perspective. One test at a time, plain text responses, no interrogation. When issues are found, automatically diagnose, plan fixes, and prepare for execution.
Output: {phase_num}-UAT.md tracking all test results. If issues found: diagnosed gaps, verified fix plans ready for $gsd-execute-phase </objective>
<execution_context> @/Users/machado/Projects/folhario/.codex/get-shit-done/workflows/verify-work.md @/Users/machado/Projects/folhario/.codex/get-shit-done/templates/UAT.md </execution_context>
<context> Phase: {{GSD_ARGS}} (optional)
- If provided: Test specific phase (e.g., "4")
- If not provided: Check for active sessions or prompt for phase
Context files are resolved inside the workflow (init verify-work) and delegated via <files_to_read> blocks. </context>
<process> Execute end-to-end. Preserve all workflow gates (session management, test presentation, diagnosis, fix planning, routing). </process>