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-issuenpx skills add frostney/pascal-mcp-sdk --skill implement-issuegit 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.00048 | $0.01178 |
| Opus 5 | $0.00024 | $0.00589 |
| Sonnet 5 | $0.00010 | $0.00236 |
| Haiku 4.5 | $0.00005 | $0.00118 |
Grade A, and why
implement-issue 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 — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implement issue
Resolve the issue end to end against the current repository, or establish with evidence that no implementation is needed.
Gates
- Read the issue, project instructions, vision, contribution guidance, Definition of Ready, Definition of Done, relevant domain skills, real project commands, affected code paths, tests, and reproduction 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.
- When current evidence conclusively fails a required prototype or readiness threshold, report that stop without asking whether to bypass the gate.
- 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 · 105 lines · 48 tokens per session scan A fd46439047f5
implement-issue is a skill published in the GitHub repository frostney/pascal-mcp-sdk (2 stars, last pushed 6d ago), licensed MIT. It adds 48 tokens to every session and 1,178 once invoked, about $0.0002 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
create-issue
Investigates and creates a project-aligned GitHub issue from a tagline or short description, using the repository's template, evidence, and labels. Use when the user runs /create-issue or asks to file a GitHub issue.
roadmap-review
Reviews a roadmap from fresh project evidence and produces a verified, throughput-anchored version plan, with execution gated on confirmation. Use when reviewing a roadmap, planning releases, or sequencing a backlog.
report-issue
File a bug or feature request against this repository (cyanheads/git-mcp-server) using the gh CLI. Use for tool logic bugs, git provider misbehavior, transport issues, auth/config problems, or new feature proposals.
approval-workflows
Configure ServiceNow approval rules and sysapprovalapprover records — manager/group/script approvers, multi-level routing, delegation via sysuserdelegate, and parent-record state rollup.
change-management
Create and transition ServiceNow change requests (normal/standard/emergency), change tasks, affected CIs, approval routing, CAB scheduling, and conflict detection across maintenance windows.
incident-management
Manage ServiceNow incidents — creation with impact/urgency priority calc, auto-assignment by category, reassignment tracking, major incident declaration with bridge calls, time-based escalation, MTTR metrics.