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/xtyooo/specpilot-codex/specpilot-execnpx skills add xtyooo/specpilot-codex --skill specpilot-execgit clone --depth 1 https://github.com/xtyooo/specpilot-codexWhat 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.00046 | $0.01358 |
| Opus 5 | $0.00023 | $0.00679 |
| Sonnet 5 | $0.00009 | $0.00272 |
| Haiku 4.5 | $0.00005 | $0.00136 |
Grade A, and why
specpilot-exec 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 3d 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 — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SpecPilot: 执行需求
按照 SpecPilot 工作流执行需求。
参数
the user-provided arguments after the command text- 要执行的需求编号（如 REQ-001）
规则约束
- 必须先读取项目指南：
docs/specpilot/project-guide.md - 必须先读取需求草稿再开始
- 如果需求已经过
/specpilot:confirm确认，以【需求确认】部分为准进行设计和实施 - 遵循草稿中指定的执行模式
- 不修改与需求无关的代码
- 保持实现最小化、聚焦
- 技术方案确认后必须写入 draft 文件
- 代码实施后必须进行两轮自动审查（重要！不可跳过！）
执行步骤
阶段一：准备
- 从
the user-provided arguments after the command text解析需求编号（去除空格） - 如果未提供编号，运行
ls docs/specpilot/requirements/并询问用户要执行哪个需求 - 读取草稿文件：
docs/specpilot/requirements/REQ-{编号}-draft.md - 读取项目指南：
docs/specpilot/project-guide.md - 更新
docs/specpilot/requirements/index.md：将状态改为🚧 in_progress
阶段二：上下文收集
- 如果指定了"关联需求"，读取那些已存档的需求文件
- 如果指定了"代码位置说明"，读取相关文件
- 如果未提供"上下文信息"，自行分析相关代码理解上下文
- 检查是否存在
REQ-{编号}-tasks.md，如有则使用它作为任务清单
阶段三：技术方案设计
如果是"先出方案"模式（默认）：
- 输出技术方案：
## 需求理解
[对需求的理解总结]
## 技术方案
### 改动范围
- 新增文件：xxx
- 修改文件：xxx
### 数据模型设计
[新增/修改的数据结构定义]
### 实现思路
[核心实现逻辑]
### 数据流/调用链路
[完整的数据流向说明，从输入到最终处理]
### 关键代码设计
[重要的代码设计，如核心方法签名、关键逻辑]
## 风险点分析
- [潜在风险1]
- [潜在风险2]
## 待确认
- [待确认点1]
- [待确认点2]
- 等待用户确认："方案确认，请开始实施"
如果是"直接实施"模式：
- 仍然需要先设计技术方案（可简化），然后直接进入实施
阶段四：技术方案记录（重要）
用户确认方案后，必须将技术方案写入 draft 文件：
- 在 draft 文件中添加或更新【技术方案】章节
- 如果方案有调整，更新版本号并记录变更原因
阶段五：实施开发
- 如果存在
REQ-{编号}-tasks.md，按任务顺序执行并标记完成 - 遵循
project-guide.md中的项目规范 - 最小范围实现变更
- 添加必要的注释和日志
阶段六：代码自审（重要！不可跳过！）
代码实施完成后，必须进行两轮自动审查：
第一轮审查：完整性检查
-
需求覆盖检查：
- 对照需求确认中的每一项，检查是否都已实现
- 检查所有字段是否都已正确处理
- 检查边界条件是否都已覆盖
-
数据流检查：
- 追踪数据从输入到输出的完整路径
- 检查 MQ/异步场景下数据是否能正确传递
- 检查数据存储和读取的时序是否正确
-
代码一致性检查：
- 检查字段命名是否与需求/规范一致
- 检查数据格式是否符合外部接口要求
第二轮审查：质量检查
-
代码质量：
- 是否有重复代码可以抽取公共方法
- 错误处理是否完善
- 日志是否充足
-
潜在问题：
- 是否有数据覆盖风险（更新嵌套字段时）
- 是否有并发安全问题
- 默认值处理是否正确
-
输出审查结果：
## 代码自审结果
### 第一轮：完整性检查
- [x] 需求覆盖：所有功能点已实现
- [x] 数据流：数据传递路径正确
- [ ] 发现问题：[问题描述]
### 第二轮：质量检查
- [x] 代码质量：无重复代码
- [ ] 发现问题：[问题描述]
### 需要修复的问题
1. [问题1]：[修复方案]
2. [问题2]：[修复方案]
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.
- 3d ago First seen · 171 lines · 46 tokens per session scan A b1a9f641bba7
specpilot-exec is a skill published in the GitHub repository xtyooo/specpilot-codex (10 stars, last pushed 6d ago), licensed MIT. It adds 46 tokens to every session and 1,358 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
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…