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 agentmods add skills/pyyush/goal/goalframenpx 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.svg" alt="Measured on agentmods" 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 | $0.00150 | $0.02168 |
| Opus 5 | $0.00075 | $0.01084 |
| Sonnet 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 3d 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.
- 3d 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 3mo ago), licensed MIT. It adds 150 tokens to every session and 2,168 once invoked, about $0.0007 per session on Opus 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
decision-ledger
Maintain an append-only decision ledger (DECISIONS.md). Use when the user confirms a decision, reverses or changes a past decision, asks what was decided and why, or at session start to load standing decisions.
checkpoint
Maintain a thirty-second return point (CHECKPOINT.md) and a single-use handoff (HANDOFF.md) so any session can resume mid-goal without archaeology. Use when a large unit of work finishes, a session enters its closing stretch, when leaving instructions for the next session, or when resuming and the user asks where…
knowledge-base
Keep verified findings in memory/knowledge/ so the same research is never done twice. Use before researching any topic, when a finding passes the verify gate, or when about to answer from something learned in an earlier session.
verify-gate
Treat research results and model knowledge as drafts until verified. Use when researching, quoting numbers or sources, recording knowledge as fact, or before declaring a task successful.
craft-style
Builds a personal output style on hush's frame — the user's voice on the surface, hush's silence-and-structure mechanics copied verbatim underneath. Manages its own creations: lists them alongside stock Hush and edits them. A mechanical verifier confirms every invariant survived. Activation is hush:pick-style's job …
pick-style
Lists every output style available to this plugin — stock Hush and anything craft-style has built — and switches the active one. Activation swaps the chosen style into the plugin's own slot so it binds like stock, and hands back to stock on request. This skill owns the swap procedure; craft-style calls into it. Only…