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/frostney/pascal-mcp-sdk/implement-ideanpx skills add frostney/pascal-mcp-sdk --skill implement-ideagit clone --depth 1 https://github.com/frostney/pascal-mcp-sdkWhat 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.00052 | $0.01149 |
| Opus 5 | $0.00026 | $0.00575 |
| Sonnet 5 | $0.00010 | $0.00230 |
| Haiku 4.5 | $0.00005 | $0.00115 |
Grade A, and why
implement-idea 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 2d 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 — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implement idea
Turn the idea into a confirmed mini-spec, then deliver it end to end in the current repository.
Gates
- Start with a provisional mini-spec of at most 400 characters, including spaces. Confirm the final mini-spec covering the user-visible outcome, scope/non-goals, and verifiable success criteria only after the artifact-assisted grill.
- Read project instructions, vision, contribution guidance, Definition of Ready, Definition of Done, relevant domain skills, real project commands, affected code paths, tests, and related work before deciding.
- Always perform and record web search for current evidence before presenting options. Prefer official and primary sources, reconcile them with the versions in the checkout, and treat remembered links only as search leads. Stop if the search cannot produce current evidence relevant to the decision.
- When
grill-with-docsorgrill-meis registered, run its actual user-question loop before presenting options. Prefergrill-with-docs; if neither exists, note that once and continue. - During the grill, proactively give the user visual or dynamic context selected
by the affected surface:
- for UI/UX, show upfront mockups for every materially different experience;
- for architecture or workflows, show a diagram or flow;
- for interaction-heavy or technical behavior, create a short-lived dynamic prototype for the recommendation or the interaction that cannot be judged statically. Show a shared current-state view when it helps compare options. Clearly label observed facts, proposed behavior, and prototype-only shortcuts.
- Keep prototypes local and disposable, retain only reviewable captures and
findings, and remove them when the grill concludes. Do not deploy or publish
them. Preserve or promote a prototype only with explicit user approval; keep
approved prototype material outside the selected worktree until its
git-workflowsynchronization gate passes. - Present two to four genuinely distinct evidence-backed options, recommend one, and wait for the user's choice unless automatic mode applies. Include a compact evidence digest with links to the most relevant current sources, checked project versions, and any mismatch or remaining uncertainty.
- For any code or test change, complete the project gate, one bounded
/code-review fix-all, and/create-pr.
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.
- 2d ago First seen · 101 lines · 52 tokens per session scan A f9c41ef25149
implement-idea is a skill published in the GitHub repository frostney/pascal-mcp-sdk (2 stars, last pushed 7d ago), licensed MIT. It adds 52 tokens to every session and 1,149 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-31.
Other skills, from other repositories
prepare-release
Run all GocciaScript release-preparation tasks before /create-release — verify the build is green, sync docs and the website to source truth (numbers and claims), preview the changelog, run the conformance and generated-data checks, and open a prep PR — ending strictly before the version/changelog/tag work that…
profile-report-review
Review GocciaScript retained VM profile reports from test262 and benchmark main-CI runs. Use when Codex is asked to inspect uploaded test262 or benchmark performance/profile artifacts, compare week-over-week or main-run trends, investigate aggregate/detailed profile data, or turn profiling findings into compiler…
gocciascript-issue-validation
Validate GocciaScript engine issues against the project-specific test262 harness. Use alongside implement-issue for GocciaScript issues that mention test262, ECMA-262/ECMA-402 conformance, Intl, or parser compatibility flags.
implement-idea
Turns an unfiled idea into a confirmed mini-spec, implements and validates the selected approach, reviews it, and opens a draft pull request. Use when the user runs /implement-idea or asks to build something without an existing issue.
implement-issue
Validates and implements a GitHub issue against current repository evidence, runs the project's completion gate, reviews the change, and opens a draft pull request. Use when the user runs /implement-issue with an issue number.
review-pr
Resolves current pull-request review findings in place, validates and pushes fixes, and can autonomously converge and merge an opted-in pull request. Use when the user runs /review-pr or /review-pr automatic-merge.