| name | authoring-goal-prompts |
| description | Author a concise, self-contained prompt to hand to Claude Code's /goal command in a separate, unattended session. Researches the target project (CLAUDE.md, dev rules, baseline build/test state, existing patterns) and drafts a goal with measurable done-criteria, transcript-verifiable checks, scope + anti-cheat constraints, and stop rules. Outputs to chat by default; externalizes bulky context to ~/.claude/goal-prompts/<slug>/ only when inlining would bloat it. Decides autonomously, asking only when a goal-defining axis is genuinely ambiguous. Use PROACTIVELY when the user mentions /goal, goal prompt, ゴールプロンプト, /goal に渡す, 自走/無人実行させたい, unattended run, 完了条件を決めて goal を回す, or setting up a long-running autonomous Claude session. Examples: <example>Context: User wants an unattended run user: '/goal に渡すプロンプトを作って' assistant: 'I will use authoring-goal-prompts skill' <commentary>goal-prompt authoring request</commentary></example> |
| allowed-tools | Read, Grep, Glob, Bash, Write, Edit, Task, AskUserQuestion |
| argument-hint | [task to draft a /goal prompt for] |
Goal Prompt Author
Produce a ready-to-paste prompt for Claude Code's /goal command, which a person will run in a
separate, unattended session. Your output is the prompt itself — you do not run /goal.
Don't use this skill for: running or babysitting /goal yourself; one-turn tasks that finish
faster than setting up a goal; subjective goals with no measurable end state ("make the UX nicer").
Three truths about /goal that drive every decision
- No human is reachable mid-run. Every decision the goal session might otherwise ask about
must be pre-decided and encoded as a fallback rule. You cannot rely on a follow-up question.
- A small evaluator model judges only the transcript — it runs no commands and reads no files.
"Done" must be provable by text the goal session prints (an exit code, a sentinel line,
git status).
- Optimizing the transcript invites cheating. A model graded on "looks done" may skip/
xfail
tests, weaken assertions, or stub implementations. Forbid this explicitly.
Concise wins. A longer prompt is not a better prompt. Include a section only when it removes
ambiguity or changes behavior. Cut empty ceremony.
Workflow
Phase 1: Discovery (autonomous) → Phase 2: Draft → Phase 3: Decide output mode
→ Phase 4: Resolve residual ambiguity (ask only if needed) → Phase 5: Emit
Phase 1: Discovery (autonomous — decide, don't ask)
Investigate the target project before drafting. Default target is the current working directory
unless the user names another. Gather, in order:
- Project rules — read the target
CLAUDE.md and any dev-rule/contribution docs. Scope limits
(e.g. "don't rename/refactor unrelated code") become CONSTRAINTS verbatim.
- Baseline — find the verify command (test/build/lint) and determine its current state.
Run it if it's cheap and safe; otherwise confirm it exists and infer state from recent signals.
A terminal state you cannot reach from the current state is a goal that never ends. Capture this
as the
BASELINE section so the goal is reachable.
- Existing patterns — locate concrete files/idioms the work should imitate, to name in
PLAN
or CONTEXT ("follow the pagination in src/api/products.ts").
For a broad/uncertain scope, dispatch an Explore agent for items 1 and 3 in parallel. Resolve
everything you can here by investigation — only genuine, goal-defining unknowns reach Phase 4.
Phase 2: Draft
Fill the scaffold in assets/goal-prompt-template.md, including
only the sections that carry signal. Read references/goal-authoring-guide.md
while drafting for the mechanics, failure modes, and worked examples.
Always bake in:
- A single, unambiguous success sentinel the evaluator can read off the transcript (e.g. require
the goal session to print
GOAL_DONE: <command> exited 0). Prefer one objective line over a
compound multi-clause condition a small model may misjudge.
- Anti-cheat constraints: do not skip /
xfail / disable / delete tests; do not weaken
assertions; do not stub or mock to pass. The build/tests must pass on the real implementation.
- Encoded fallbacks: "if X is ambiguous, prefer Y; if blocked, stop and report" — because the
goal session cannot ask.
- A stop ceiling (
or stop after N turns) and, for long runs, commit-per-unit + a one-line
per-iteration progress log so the run is reviewable afterward.
Phase 3: Decide output mode (autonomous)
- Default: chat-only. Print the prompt as one copyable fenced block.
- Bundle to
~/.claude/goal-prompts/<slug>/ when supporting material would bloat the prompt —
rule of thumb: the prompt would exceed ~40–60 lines, or there is reusable reference material
(a migration inventory, research findings, a design spec, a generated checklist). Keep goal.md
itself short; move the bulk into sibling files and have CONTEXT point to them by absolute path
so the goal session reads them on demand. <slug> is a deterministic kebab-case summary of the
goal (~4–6 words); re-running the same goal overwrites the same dir (idempotent).
Phase 4: Resolve residual ambiguity (ask only if needed)
Use AskUserQuestion only if a goal-defining axis cannot be settled by investigation — and only
for these: the done-state, the scope boundary, the verify method, the stop ceiling.
One round, ≤4 questions, concrete options. If discovery answered it, do not ask. No question is the
expected outcome for well-specified tasks.
Phase 5: Emit
- Print the concise prompt in one fenced block, ready to paste after
/goal.
- If bundled: write the files, then print the directory path and a one-line note —
"In a fresh session run
/goal with the contents of ~/.claude/goal-prompts/<slug>/goal.md
(it references the sibling docs by absolute path)."
- Briefly state which sections you included/omitted and why, plus the baseline you found.
Self-QA bar (run before emitting — assume a problem exists)
Critical rules
- Never write a goal you cannot prove from the transcript, or one unreachable from the baseline.
- Never pad the prompt. Brevity over completeness.
- Never rely on asking mid-run — encode the fallback instead.
- Always include the anti-cheat clause for test/build goals.
- Always keep
goal.md short and push bulk to sibling files (absolute paths) when bundling.
Supporting files
