Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add pyyush/goal --skill goalframegit clone --depth 1 https://github.com/pyyush/goalWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pyyush/goal/goalframe)<a href="https://agentmods.dev/skills/pyyush/goal/goalframe"><img src="https://agentmods.dev/badge/skills/pyyush/goal/goalframe/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pyyush/goal/goalframe"><img src="https://agentmods.dev/badge/skills/pyyush/goal/goalframe.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00150 | $0.02168 |
| Opus 5.5 | $0.00060 | $0.00867 |
| Sonnet 5.5 | $0.00030 | $0.00434 |
| Haiku 4.5 | $0.00015 | $0.00217 |
Grade A, and why
goalframe scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 166 lines — stays where its author put it; the contents beside it link to each section on GitHub.
goalframe — give the objective a shape before it becomes a goal
Purpose
A one-off prompt can be vague — the user is right there to course-correct. A goal cannot. It runs across many turns with no one steering, so it needs to carry, in itself, everything required to (a) pick the next action, (b) know what "done" means, and (c) know when to stop and ask. Raw objectives almost never do. "Improve performance" has no finish line. "Refactor the auth module" has no verification surface. "Make the app better" is not a goal at all.
goalframe converts a raw objective into a goal spec: six fields, a title,
and a small task-level verification plan. It is the entry-side counterpart to
overclaim (the exit-side gate). The two share one contract — the
verification field and tasks[] this skill writes are exactly what
overclaim later audits claims against. Frame the goal well here and the
completion check downstream becomes mechanical.
This is also what makes the goal loop token-efficient and keeps the Stop-hook UX tolerable. The spec is written to the goal record once. The continuation dispatcher then drives the run by referencing that record, not by re-pasting the objective every turn — and compact Stop-hook mode may show only the title and record path in the host-visible row. The spec must therefore be compact: each field one or two sentences, the title ≤ 80 chars. A tight spec is cheap to re-read; a rambling one is not.
When this runs
Before writing any goal record — i.e. inside /goal <objective> and before
mcp__goal__create_goal. It runs on the raw objective and emits the spec
object the goal record will store. It does not write the record itself.
A goal spec — the six fields, title, and tasks
| field | what it pins down | Codex term |
|---|---|---|
title |
one imperative line, ≤ 80 chars, no newlines — used in continuation prompts and compact Stop-hook rows | — |
outcome |
what must be true when the work is done | Outcome |
verification |
the test, command, benchmark, artifact, or source that proves it | Verification surface |
constraints |
what must not regress or change while the goal runs | Constraints |
boundaries |
which files, dirs, tools, services the goal may touch | Boundaries |
iteration |
how to choose the next action after each attempt | Iteration policy |
blocked_when |
the condition under which to stop and report rather than push on | Blocked stop condition |
tasks |
3-7 task checkpoints: the current controllable units of work | Task ledger |
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 166 lines · 150 tokens per session scan A 77ddd3b2757d
goalframe is a skill published in the GitHub repository pyyush/goal (1 stars, last pushed 5mo ago), licensed MIT. It adds 150 tokens to every session and 2,168 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
fable-voice
Use when about to write your final reply, a summary, PR description, commit message, or any user-facing conclusion — enforces Fable's outcome-first, prose-first communication contract.
fable-fanout
Use when a task involves 2+ independent units of work (files, modules, questions) or any broad codebase sweep — enforces Fable's delegation-first parallel orchestration.
fable-turn-check
Use before ending any turn that involved multi-step work — Fable's end-of-turn gate catches promised-but-undone work, buried findings, and unverified claims.
confidence-gate
When you're about to claim success ("fixed", "done", "works", "passing tests") at the end of a turn, verify the claim is backed by actual evidence in this session. presence's Stop hook will flag a success claim that has no recent test/build pass behind it. Be aware of this gate and either run the verification, or…
baton-setup
One-time setup and health check for fable-baton. Use when the user asks to set up, configure, verify, or troubleshoot fable-baton - sets the default model to "best" (Fable 5 with Opus fallback) in /.claude/settings.json and verifies the plugin is fully installed.
are-you-done
A completion checker for coding work that asks for evidence before allowing an assistant to say a task is finished.