claude-code-plugins: Skill for Claude Code

Goalify

Write the line the user pastes after /goal: the condition, and only the condition. The work it describes is the next session's, not yours.

A /goal condition is read twice. Claude reads it as the directive of the next turn. A small evaluator model reads it after every turn, against the conversation alone: it runs no command and opens no file, so it can only judge what Claude has printed. The condition is written for that second reader. A clause the evaluator cannot settle from the transcript is a clause that never resolves, and the loop runs until the turn cap or the user kills it.

Input

$ARGUMENTS

A draft condition as input is rewritten clause by clause, keeping its intent and replacing what the evaluator could not settle.

interactive as the first word: settle each clause below with AskUserQuestion, one at a time, the recommended answer first; inspect the repository instead of asking when it holds the answer. Otherwise infer, and ask only when two readings of the task give two different end states.

Five clauses

End state. One measurable fact that holds when the work is done, in the present tense: a test result, an exit code, a file count, an empty queue, a score at or above a threshold. Not an activity ("migrate the module") but its trace ("every call site of oldApi is gone and the build passes"), and not an order ("make the case pass") but the fact ("the case passes 20 runs"). Several facts joined by "and" are one end state; two unrelated ones are two goals, run in sequence.

Proof. The command Claude runs and the exact line of its output that shows the end state, printed in the conversation: "bun test --parallel exits 0 and its summary shows 0 fail", not "tests pass". Take the command from the repository's own checks when it has them (package.json scripts, AGENTS.md, CI config); write the proof clause first and derive the end state from it when the task is vague. The proof is the command's own summary line, never an echoed exit code (Gotchas).