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/pandysp/claude-plugins/clarifynpx skills add pandysp/claude-plugins --skill clarifygit clone --depth 1 https://github.com/pandysp/claude-pluginsWrote 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/pandysp/claude-plugins/clarify)<a href="https://agentmods.dev/skills/pandysp/claude-plugins/clarify"><img src="https://agentmods.dev/badge/skills/pandysp/claude-plugins/clarify.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.00112 | $0.00625 |
| Opus 5 | $0.00056 | $0.00313 |
| Sonnet 5 | $0.00022 | $0.00125 |
| Haiku 4.5 | $0.00011 | $0.00063 |
Grade A, and why
clarify 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 4d 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 — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Clarify: exhaust questions before designing
Before proposing design options, surface the synthesis questions: places where the task and terrain leave something genuinely undecided. Locking a design around a hidden assumption is more expensive than asking up front.
Dimensions to cover
Skip dimensions that don't matter here. For each, ask only what's genuinely unclear:
- Scope & boundaries: what's in, out, deferred.
- Edge & extreme behavior: what happens at unusual conditions.
- Trade-offs & calibration: where on the spectrum to land.
- Integration with surroundings: what must this fit alongside or interact with.
- Hard constraints: what would create downstream problems if violated (compliance, deadlines, budget).
- Audience specifics: what does the actual consumer of this need.
What to surface
Ask only what's genuinely unclear AND would change the design. Skip what task + terrain already answer, and what wouldn't change the proposed options. Group related questions. If a dimension has no open question, say so. Shows you considered it.
Format
Each question gets specific phrasing: not "any thoughts on edge cases?" but a concrete, scoped question with named alternatives, plus a default when applicable.
### Scope & boundaries
- [Specific question with named alternatives]? My read: [recommendation].
### Edge & extreme behavior
- [Edge case condition] — [option A] *(default)* or [option B]?
### Hard constraints
- No open questions — [brief reason].
When the user defers
If the user says "whatever you think is best" or similar: provide a specific recommendation per question, get explicit confirmation. Don't silently absorb. That's the "I assumed you wanted X" failure mode.
After clarification
Briefly recap the resolved decisions: "Confirmed: [decision 1], [decision 2]." Then proceed to design.
Common pitfalls
- Asking what task + terrain already answer. If the answer is implicit, commit instead of asking.
- Leaving the user to do synthesis. Specific questions with defaults, not "any thoughts on X?"
- Ignoring user delegation. "Whatever you think" requires recommendation + confirmation, not silent picking.
- Treating it as task interpretation. This is post-task-understanding and post-terrain synthesis, not a substitute for either.
- Mechanical run-through. Skip dimensions that don't matter here.
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.
- 4d ago First seen · 55 lines · 112 tokens per session scan A e25c4e68b756
clarify is a skill published in the GitHub repository pandysp/claude-plugins (5 stars, last pushed 13d ago), licensed MIT. It adds 112 tokens to every session and 625 once invoked, about $0.0006 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…