How do I install the Goat Workflow skill?

Run npx skillmds@latest add hypnguyen1209/goat-workflow in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Goat Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Goat Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Goat Workflow free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Goat Workflow?

hypnguyen1209 (@hypnguyen1209) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Goat Workflow by hypnguyen1209 — Agent Skill

Name: Goat Workflow
Author: hypnguyen1209

Goat Workflow

Use when unsure whether to plan, execute, review, or QA, or the user asks what should we do next. Chooses which codex-goat stage fits the current request and checks whether it can start right now. Part of codex-goat.

File contents

$goat-workflow

One consistent workflow, six independent entry points. This card decides which one.

The stages

Stage	Use when	Needs
`$clarify`	The request could mean several different things	nothing
`$plan`	The approach needs to be written down and agreed	an objective
`$ultragoal`	Work needs finishing, with proof, across turns	an objective + an approach
`$team`	The work splits into 2+ independent lanes	an objective + real lanes
`$code-review`	A concrete change needs judging	a change
`$ultraqa`	Behavior needs proving by execution	something runnable

There is no fixed chain

The usual order is clarify → plan → execute → review → QA, but nothing enforces it, because most real requests do not start at the beginning:

"Review my changes" → $code-review. No plan, no objective needed.
"Test this properly" → $ultraqa. Straight in.
"Fix the login bug, tests must pass" → $ultragoal. The approach is already implied.
"I'm not sure what I want" → $clarify.

Ask what the request needs, not what stage comes next in a diagram.

Routing

Is there a concrete change to judge? → $code-review
Is there runnable behavior to prove? → $ultraqa
Is the request ambiguous enough that two people would build different things? → $clarify
Is the approach contested, risky, or spanning subsystems? → $plan
Does it split into 2+ lanes with disjoint files? → $team
Otherwise → $ultragoal

If none of these fit — a single obvious edit, a question, a lookup — use no stage at all. Loading a workflow for a one-line fix is the most common way to waste a session.

Check before you start

goat contract            # every stage: ready, or what is missing
goat contract ultraqa    # one stage
goat status              # what has already run, and what it proved

A requirement reported as inline means the user's own message can satisfy it. Take it from there and proceed — do not force an earlier stage to manufacture it.

Evidence is the constant

Whatever stage runs, the rule does not change: a claim needs a command that ran.

goat ledger evidence --stage <stage> --exit <code> -- <command>

goat status marks a stage complete* when its evidence does not back the claim — none recorded, every command exited non-zero, or every command is a shell no-op. Treat that as unfinished work, not as a formatting detail.

---name: goat-workflowdescription: Use when unsure whether to plan, execute, review, or QA, or the user asks what should we do next. Chooses which codex-goat stage fits the current request and checks whether it can start right now. Part of codex-goat.---# $goat-workflowOne consistent workflow, six independent entry points. This card decides which one.## The stages| Stage | Use when | Needs || --- | --- | --- || `$clarify` | The request could mean several different things | nothing || `$plan` | The approach needs to be written down and agreed | an objective || `$ultragoal` | Work needs finishing, with proof, across turns | an objective + an approach || `$team` | The work splits into 2+ independent lanes | an objective + real lanes || `$code-review` | A concrete change needs judging | a change || `$ultraqa` | Behavior needs proving by execution | something runnable |## There is no fixed chainThe usual order is clarify → plan → execute → review → QA, but **nothing enforces it**,because most real requests do not start at the beginning:- "Review my changes" → `$code-review`. No plan, no objective needed.- "Test this properly" → `$ultraqa`. Straight in.- "Fix the login bug, tests must pass" → `$ultragoal`. The approach is already implied.- "I'm not sure what I want" → `$clarify`.Ask what the request needs, not what stage comes next in a diagram.## Routing1. **Is there a concrete change to judge?** → `$code-review`2. **Is there runnable behavior to prove?** → `$ultraqa`3. **Is the request ambiguous enough that two people would build different things?** → `$clarify`4. **Is the approach contested, risky, or spanning subsystems?** → `$plan`5. **Does it split into 2+ lanes with disjoint files?** → `$team`6. **Otherwise** → `$ultragoal`If none of these fit — a single obvious edit, a question, a lookup — use no stage at all.Loading a workflow for a one-line fix is the most common way to waste a session.## Check before you start```shgoat contract # every stage: ready, or what is missinggoat contract ultraqa # one stagegoat status # what has already run, and what it proved```A requirement reported as `inline` means the user's own message can satisfy it. Take itfrom there and proceed — do not force an earlier stage to manufacture it.## Evidence is the constantWhatever stage runs, the rule does not change: a claim needs a command that ran.```shgoat ledger evidence --stage <stage> --exit <code> -- <command>````goat status` marks a stage `complete*` when its evidence does not back the claim — nonerecorded, every command exited non-zero, or every command is a shell no-op. Treat that asunfinished work, not as a formatting detail.

Frequently asked questions