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 tt-a1i/matt-skills-with-to-goal --skill to-goalgit clone --depth 1 https://github.com/tt-a1i/matt-skills-with-to-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/tt-a1i/matt-skills-with-to-goal/to-goal)<a href="https://agentmods.dev/skills/tt-a1i/matt-skills-with-to-goal/to-goal"><img src="https://agentmods.dev/badge/skills/tt-a1i/matt-skills-with-to-goal/to-goal/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/tt-a1i/matt-skills-with-to-goal/to-goal"><img src="https://agentmods.dev/badge/skills/tt-a1i/matt-skills-with-to-goal/to-goal.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00062 | $0.02253 |
| Opus 5 | $0.00031 | $0.01126 |
| Sonnet 5 | $0.00012 | $0.00451 |
| Haiku 4.5 | $0.00006 | $0.00225 |
Grade A, and why
to-goal 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 12d 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 — 187 lines — stays where its author put it; the contents beside it link to each section on GitHub.
To Goal
Compile existing planning and repository evidence into an execution goal. Do not implement, mutate the tracker, create a branch, or modify files.
Source of truth
Read ../goal-crafter/SKILL.md only for compiled-handoff mode, Phase 2 harness formats, Phase 3's four self-checks, and Special Rules (never re-interview; one verifiable condition per checkbox). Skip Phase 1 and Examples. This skill owns context gathering, frontier selection, readiness checks, and execution handoff. Do not reopen decisions already made by to-spec, to-tickets, or triage.
Accepted inputs
Resolve one of:
- no argument: inspect the configured tracker and select the current unblocked, agent-ready frontier ticket;
- a ticket number or URL: read that ticket in full;
- a parent spec issue: read the spec, sub-issues, and blocking graph, then select its current frontier;
- a local spec or ticket path: read the complete file and any directly referenced local planning document (local tracker:
.scratch/<feature>/spec.mdand one file per ticket under.scratch/<feature>/issues/<NN>-<slug>.md); --all <parent>: generate one dependency-ordered cross-ticket goal.
Always read ticket comments. For a tracker parent, use native sub-issue and dependency relationships when available; otherwise use explicit blocker text. Do not infer that a ticket is ready merely from its label.
If no argument yields several frontier tickets, list them and ask the user to choose one. Do not silently combine them. If a requested ticket is blocked, report its blockers and do not generate an implementation goal.
For a spec with no tickets, generate a goal directly only when the entire work fits one fresh context window. If it is multi-session work, route it through to-tickets instead of bypassing the context boundary.
Gather current evidence
Before drafting:
- Read the complete source spec and selected ticket, including acceptance criteria and comments.
- Inspect the repository instructions and relevant design vocabulary.
- Inspect the current branch, HEAD, worktree status, recent commits, and diff. Record the pre-implementation HEAD as the code-review fixed point.
- Compare current behavior and tests with every acceptance criterion.
- Classify criteria as evidenced complete, demonstrably incomplete, or unverified. A commit message is not evidence.
- Discover validation commands from the repository's own scripts, CI, documentation, and existing tests.
- Preserve user-established permissions and workspace boundaries from the source context.
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.
- 12d ago First seen · 187 lines · 62 tokens per session scan A 4cddcae6e274
to-goal is a skill published in the GitHub repository tt-a1i/matt-skills-with-to-goal (160 stars, last pushed 15d ago), licensed MIT. It adds 62 tokens to every session and 2,253 once invoked, about $0.0003 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-30.
Other skills, from other repositories
handing-off-work
Hands off unfinished work with a closed-loop briefing of state, changed conditions, remaining scope, authority limits, and open evidence. Use when AI-agent, reviewer, verifier, releaser, or resumed-thread work transfers to a new owner. Do not use when the same owner continues uninterrupted with full context.
tracking-deficiencies
Keeps a standing register of known deficiencies so flaky tests, noisy alerts, unowned services, and recurring incidents get aged, owned, and fixed or formally risk-accepted instead of quietly normalized. Use when a known problem will outlive a single change. Do not use for a one-off lesson already closed inside a…
pace-bridge
Use to bridge a confirmed Superpowers/native plan into PACEflow CHG/HOTFIX artifacts, create artifact-writer prompts, and mark the specific plan as synced.
trellis-workflow-enhancer
Audit and apply real, project-local Trellis integrations for Matt Pocock and Waza skills, with phase routing, hook injection, durable artifact handoffs, and smoke-test evidence. Use when a user wants to strengthen, compare, modernize, integrate, or debug Trellis with Matt/Waza workflows, especially when skills are…
specgate-work-preparation
Use when preparing a request or existing source documents for SpecGate approval, creating quick SpecGate work, publishing an artifact version, or repairing artifact readiness before implementation.
jira-issue-create
Create one or more Jira issues through acli from user-approved drafts using heading-based Context, Acceptance criteria, and Engineering notes sections. Use only when explicitly invoked to create Jira issues; use jira-issue-refine when requirements still need refinement.