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/stanshy/agenthub/spec-updatenpx skills add Stanshy/AgentHub --skill spec-updategit clone --depth 1 https://github.com/Stanshy/AgentHubWrote 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/stanshy/agenthub/spec-update)<a href="https://agentmods.dev/skills/stanshy/agenthub/spec-update"><img src="https://agentmods.dev/badge/skills/stanshy/agenthub/spec-update.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.00031 | $0.00870 |
| Opus 5 | $0.00015 | $0.00435 |
| Sonnet 5 | $0.00006 | $0.00174 |
| Haiku 4.5 | $0.00003 | $0.00087 |
Grade A, and why
spec-update 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 5d 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.
What it actually says
規範文件更新
修改任何 .knowledge/specs/ 下的規範文件時,必須透過此 skill 執行,確保版本號遞增、變更有記錄、相關任務被通知。
使用方式
/spec-update <spec-file> <變更摘要>
參數
$0: 規範文件路徑(如.knowledge/specs/api-design.md)$ARGUMENTS: 完整參數(含變更摘要)
執行步驟
STEP 1 — 讀取目標規範文件
讀取 $0,確認:
- 當前版本號(文件標題或頂部 metadata 中的
vX.Y) - 文件結構與現有內容
⛔ STEP 2 — 確認變更範圍
說明本次變更:
- 變更內容:新增 / 修改 / 刪除了什麼
- 影響範圍:哪些模組、API、功能受影響
- 向後相容性:是否有 breaking change
輸出:
📋 變更摘要
規範文件:$0
當前版本:vX.Y
變更類型:[新增欄位 / 修改行為 / 刪除功能 / 其他]
影響範圍:[描述]
Breaking change:[是 / 否]
✋ 確認變更範圍正確後再繼續。
STEP 3 — 執行變更
對 $0 進行實際修改。
⛔ STEP 4 — 遞增版本號
在規範文件頂部更新版本號:
- Minor change(新增、修改):
vX.Y→vX.Y+1 - Breaking change:
vX.Y→vX+1.0
在文件頂部加入變更記錄(若無 Changelog 區塊則新增):
## Changelog
### vX.Y+1 — {YYYY-MM-DD}
{變更摘要}
✋ 確認版本號已遞增、變更記錄已寫入後再繼續。
STEP 5 — 更新 file-index.md
找到 .knowledge/file-index.md,更新對應規範文件的版本標註:
| `.knowledge/specs/api-design.md` | API 設計規格 vX.Y+1(🔴 規範) |
STEP 6 — 掃描受影響任務
!find .tasks -name "*.md" 2>/dev/null | xargs grep -l "api-design\|data-model\|feature-spec" 2>/dev/null | head -10
列出目前 in_progress 或 assigned 狀態、且與本規範相關的任務。
STEP 7 — 輸出通知
✅ 規範更新完成
規範文件:$0
版本:vX.Y → vX.Y+1
file-index 已更新:✅
受影響的進行中任務:
- T3: {名稱} (in_progress → 需確認是否受影響)
- T5: {名稱} (assigned → 執行前請重新閱讀規範)
建議動作:
1. 通知相關 L2 Agent 重新讀取規範後繼續執行
2. 若有 breaking change,請 L1 確認已完成任務是否需要返工
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.
- 5d ago First seen · 103 lines · 31 tokens per session scan A 465e94d9c06a
spec-update is a skill published in the GitHub repository Stanshy/AgentHub (200 stars, last pushed 4mo ago), licensed MIT. It adds 31 tokens to every session and 870 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-30.
Other skills, from other repositories
comet-native
Comet Native 工作流。当用户明确调用 /comet-native、要求启动或恢复 Native change,或入口路由到 Native 时使用。.
comet-classic
Comet Classic 工作流(OpenSpec + Superpowers)。当用户明确调用 /comet-classic、要求启动或恢复 Comet Classic,或 resume-probe 返回可无歧义恢复的 active Classic change 时使用。.
comet-build
Comet Classic 阶段 3 —— 恢复或创建实施计划并执行其任务。.
comet-github-idea-to-issue
基于当前代码库,将本地 Comet 想法、观察到的回归或改进提案整理为聚焦的 GitHub Issue 草稿。用户要求把本地调查转换为 Issue、后续 Issue、Bug、Feature 或维护任务时使用。.
create-request
Create, update, or scan per-task request tickets for progress tracking. These are date-prefixed non-lifecycle docs under requests/, NOT feature-level requirements (use /req-analyze for those). Use when: tracking task progress, updating completion status, scanning incomplete requests, checking request status dashboard.…
kn-handoff
Use when a feature crosses repository boundaries and one side must hand work to the other - generates a self-contained frontend-to-backend brief or backend-to-frontend API contract.