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 YuDefine/nuxt-supabase-starter --skill clarify-over-specsgit clone --depth 1 https://github.com/YuDefine/nuxt-supabase-starterWrote 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/yudefine/nuxt-supabase-starter/clarify-over-specs)<a href="https://agentmods.dev/skills/yudefine/nuxt-supabase-starter/clarify-over-specs"><img src="https://agentmods.dev/badge/skills/yudefine/nuxt-supabase-starter/clarify-over-specs/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/yudefine/nuxt-supabase-starter/clarify-over-specs"><img src="https://agentmods.dev/badge/skills/yudefine/nuxt-supabase-starter/clarify-over-specs.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00120 | $0.01456 |
| Opus 5 | $0.00060 | $0.00728 |
| Sonnet 5 | $0.00024 | $0.00291 |
| Haiku 4.5 | $0.00012 | $0.00146 |
Grade A, and why
clarify-over-specs 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 today.
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 — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Clarify Over Specs
在 spec.md 已存在的前提下,對既有 spec artifact 進行主動式需求澄清。先對齊目標 spec.md 與 checklists/requirements.md,再以全 spec 掃描方式盤點高影響缺口,只把真正會改變規格正確性、驗收標準、故事邊界、資料模型、NFR 邊界或後續 readiness 判定的問題升級給 /clarify;資訊收斂後,將答案整合回 spec、清理矛盾與術語漂移,並同步更新 checklist 與完成回報。
SOP
Phase 1 -- 對齊目標 spec 與回寫範圍
- READ 讀取使用者需求、呼叫者要求、當前上下文、任何顯式覆寫參數,以及目前 feature 的
spec.md與checklists/requirements.md;確認本次要澄清的 spec 目標、是否存在 checklist、是否需要詳記完成回報。若找不到目標spec.md,停止並要求使用者先執行/specify或明確指定目標 spec 路徑。 - THINK 若需要決定目標
SPEC_FILE、CHECKLIST_FILE與覆寫優先順序,先讀取rules/目標spec定位與覆寫優先順序判準.md,再依其要求收斂本次目標檔案與回寫範圍。
Phase 2 -- 掃描全 spec 高影響缺口與 clarify 策略
- THINK 先從整份
spec.md盤點會影響需求正確性、驗收可驗證性、故事切分、資料模型、NFR 邊界、術語一致性或 readiness 判定的模糊、矛盾、缺漏與未拍板決策。 - THINK 若需要判斷哪些缺口必須升級為
/clarify、哪些可直接保留為 deferred 風險或留在 spec 中明示,先讀取rules/spec高影響缺口掃描與提問排序判準.md,再依其要求收斂本輪最高影響的 1 至 3 個缺口、指定提問面向,以及本輪不應追問的低影響細節。 - DELEGATE 若仍存在會改變 spec 正確性、正式驗收標準、跨故事需求邊界、關鍵資料約束、NFR 承諾或 readiness 判定的高影響缺口,呼叫
/clarify先訪談使用者,指定優先提問面向為本輪已收斂的缺口,並要求本輪只處理 1 至 3 題;未收斂前停止,不自行假設答案。
Phase 3 -- 將澄清結果整合回 spec
- READ 讀取
/clarify產出的已確認決策、使用者補充與剩餘風險,確認哪些答案需要回寫到spec.md,哪些缺口仍應保留為 deferred 或NEEDS CLARIFICATION。 - THINK 若需要判斷答案應寫回哪些 section、哪些舊敘述應被替換或刪除、哪些術語需要統一,先讀取
rules/spec回寫位置與矛盾清理判準.md,再依其要求收斂本次要更新的 section、矛盾清理方式與術語統一策略。 - WRITE 依思考結果更新
SPEC_FILE,把已確認答案整合進對應 section,清理被新答案推翻的舊敘述與術語漂移;若仍有高影響缺口未解,明示保留狀態與後續建議,不以腦補補完。
Phase 4 -- 回驗 spec 與 checklist
- THINK 若需要判斷哪些 checklist 項應切換狀態、哪些 section 已達到 ready、以及完成回報應呈現哪些更新結果,先讀取
rules/checklist回刷與完成報告判準.md,再依其要求收斂本次 checklist 更新、ready 判定、deferred 風險與完成回報重點。 - WRITE 若
CHECKLIST_FILE存在,依思考結果只更新實際狀態有變化的 checkbox,保留其餘內容不動;若本次沒有 checklist,跳過此步但保留對 ready 狀態的明示說明。 - READ 回頭檢查
SPEC_FILE、CHECKLIST_FILE(若存在)與本輪已確認答案是否一致,且沒有遺留被本輪答案推翻的舊敘述、重複規格或衝突結論;若不一致,立即修正。
Phase 5 -- 交付結果與後續 handoff
- WRITE 先讀取
templates/clarify-over-specs-report.md與templates/clarify-over-specs-report.example.md,再依其要求向使用者回報本次目標SPEC_FILE、是否進入/clarify、實際處理的高影響缺口、更新 section、checklist 變化、仍 deferred 的風險,以及建議下一步應直接進/plan或稍後再執行一次/clarify-over-specs。
What ships with it
7 files 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.
- today Changed 064ca3eeccea
- yesterday First seen · 47 lines · 120 tokens per session scan A 02c24cd23d11
clarify-over-specs is a skill published in the GitHub repository YuDefine/nuxt-supabase-starter (45 stars, last pushed today), licensed MIT. It adds 120 tokens to every session and 1,456 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-09-10.
Other skills, from other repositories
prd-v07-implementation-loop
Execute implementation within EPICs following test-first development, continuous SoT updates, and code traceability during PRD v0.7 Build Execution. Triggers on requests to start building, implement an epic, begin coding, or when user asks "start building", "implement epic", "coding", "development", "build execution"…
prd-v07-test-planning
Define test cases BEFORE implementation, ensuring every API, business rule, and user journey has verifiable acceptance criteria during PRD v0.7 Build Execution. Triggers on requests to define tests, plan test coverage, create test cases, or when user asks "define tests", "test planning", "what to test?", "test cases"…
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.
prd-v04-user-journey-mapping
Map user missions from trigger to value moment, organizing features into coherent paths during PRD v0.4 User Journeys. Triggers on requests to map user journeys, define user flows, describe how users accomplish goals, or when user asks "map user journeys", "define user flows", "user missions", "how do users accomplish…
atomic-tdd
Test-first discipline. Auto-triggers on "let's implement X", "add feature Y", "fix bug Z", "write a test for", "implement", "build out", and similar pre-code-change phrases. Iron rule: failing test exists before production code. Skip only for pure docs/config changes with an explicit "skipped because:" note. Explicit…
use-tdd
Implement a requested increment with red-green-refactor. Use when the user types /use-tdd.