Writing goals
Agent skills by Trent Sikute, installable via npx skills add trentsikute/skills
npx -y skills add trentsikute/skills --skill writing-goalsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Prepare a `/goal` condition that gates an autonomous agent run on a transcript-verifiable check. Use when setting up success criteria, an end-state signal, scope constraints, and a stopping budget before launching a long-running task with /goal.
SKILL.md
3.3 KB, as published. Nobody here has run it
Turn a fuzzy task into a /goal condition that can be judged from the conversation transcript alone; the evaluator never runs commands at evaluation time. Refuse to write the condition until five components are concrete.
For /goal syntax, limits, and enablement, read the bundled reference for the host tool: Claude Code in references/claude-code-goal.md, Codex in references/codex-goal.md.
If the user passed an argument, treat it as their framing. Otherwise ask one sentence about the task. If the goal is a multi-module refactor, migration, or new feature and no plan.md exists, suggest the user produce one first, manually or via an installed planning skill (scan available skills by description; never invent names).
Grill these five, one focused structured question per round. Use your tool's structured-question mechanism if one is available; otherwise ask in prose with labeled (a)/(b)/(c)/Other options:
- End state — one observable signal: test result, exit code, file/byte count, empty queue, lint clean.
- Stated check — the exact CLI command + stdout pattern proving the end state from the transcript (e.g.,
pnpm testexits 0 with0 failedin stdout). Reject answers that defer to model judgment ("Claude verifies", "the agent confirms"). Push for a concrete command whose stdout lands in the transcript. If the test runner is unclear, scan the project's manifest files and bias options to the user's ecosystem. - Constraints — scope fence (paths in/out), quality fence (no
eslint-disable, noas any, no test deleted or skipped), process fence (one logical change per commit). - Disciplines — name installed skills the agent should follow throughout. Scan available skills for descriptions matching planning, test-first, diagnosis, pre-completion verification, or general hygiene; offer the matches by their actual installed names, filtered by goal type. Never invent skill names. If none match, "none" is fine.
- Stopping budget — a hard ceiling on how long the goal can run, in whatever unit your tool exposes: "stop after 40 turns", "stop after 2 hours", or similar (defaults: 20 for short tasks, 40 for migrations). If your tool is turn-based, check whether resuming a session resets the counter. Many do.
Demand concrete answers verifiable from transcript output. Do not infer; ask.
For long goals (>10 turns), ask whether to maintain a per-turn progress log (e.g. progress.md appended and committed per turn, recording what changed and the stated-check result). This guards against context summarization in long sessions erasing the trail. Skip for short goals.
Write the goal document with: title, the /goal condition one-liner in a fenced block, plain-English goal, the user's answers, and a one-line invocation note. Save it to a path produced by mktemp -t goal-XXXXXX.md (read the file before you write to it).
Report the file path and the /goal <condition> in a fenced code block. Do not fire /goal; the user does.