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/simpleeve/development-skills/specnpx skills add SimpleEve/development-skills --skill specgit clone --depth 1 https://github.com/SimpleEve/development-skillsWhat 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.00060 | $0.01093 |
| Opus 5 | $0.00030 | $0.00547 |
| Sonnet 5 | $0.00012 | $0.00219 |
| Haiku 4.5 | $0.00006 | $0.00109 |
Grade A, and why
spec 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.
What it actually says
Spec - 需求规格说明技能
将模糊的需求意图转化为清晰、无歧义的需求规格文档。
核心原则
- 不猜测：遇到任何模糊点，必须向用户提问澄清，绝不自行假设
- 不模糊：每个需求边界必须是确定的，In Scope / Out of Scope 必须明确列出
- 不写代码：绝不写任何代码，包括伪代码。只用自然语言描述需求行为
- 固定产出：输出到项目既有的需求目录；若无统一约定，建议使用
spec/<spec-name>/spec.md
工作流程
第一步：理解与澄清
- 阅读用户给出的需求描述
- 阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在），理解整体背景
- 阅读已有的需求文档，避免重复或冲突
- 列出所有不确定的点，逐一向用户澄清
- 反复澄清直到无任何歧义
第二步：撰写 Spec
按照下方固定模板撰写，写入对应功能的 spec.md。
第三步：用户确认
将产出交给用户确认，根据反馈修订直到用户满意。
固定模板
# <功能名称> 需求规格说明
> 状态：草稿 | 已确认
> 创建日期：YYYY-MM-DD
> 所属里程碑：如项目使用里程碑则填写，否则写"无"
## 1. 概述
### 1.1 功能简述
一句话说清楚这个功能做什么。
### 1.2 所属模块
标明属于哪个系统、子模块、包、程序集、服务或运行时区域。
### 1.3 关联文档
列出关联的 PRD 章节、roadmap、设计稿、其他 spec。
## 2. 用户故事与场景
### 2.1 目标用户
明确这个功能服务于谁。
### 2.2 用户故事
使用 "作为 <角色>，我希望 <行为>，以便 <价值>" 格式。
### 2.3 使用场景
描述 2-3 个典型使用场景，包含前置条件和期望结果。
## 3. 功能需求
### 3.1 输入
明确所有输入来源、格式、必填/选填。
### 3.2 输出
明确所有输出目标、格式、成功/失败的结果。
### 3.3 核心行为描述
用自然语言逐条描述系统在每个场景下的具体行为。
**禁止使用代码或伪代码。**
### 3.4 业务规则与约束
列出所有业务逻辑规则、限制条件、异常处理要求。
## 4. 非功能需求
### 4.1 性能要求
如有明确指标则列出，无则标注"无特殊要求"。
### 4.2 安全要求
### 4.3 兼容性要求
## 5. 边界与限制
### 5.1 明确包含（In Scope）
逐条列出本次需求范围内的内容。
### 5.2 明确排除（Out of Scope）
逐条列出本次明确不做的内容。
### 5.3 已知约束
列出技术或业务上的已知限制。
## 6. 验收标准（Acceptance Criteria）
使用 "Given-When-Then" 格式逐条列出：
- **Given** <前置条件>
- **When** <用户操作>
- **Then** <期望结果>
## 7. 开放问题（Open Questions）
列出所有尚未解决的问题，标注负责人和期望解决日期。
如全部已解决则标注"无"。
## 8. 变更记录
| 日期 | 变更内容 | 变更人 |
|------|---------|--------|
关键约束
- 绝不写代码：包括伪代码、代码片段、接口定义。这些属于 plan 阶段的职责
- 绝不猜测：宁可多问一轮，也不要用"可能"、"大概"、"应该"这类词
- 一个 spec 一个功能：不要在一个 spec 里塞多个不相关的功能
- spec-name 命名规则：使用小写英文 kebab-case，如
user-auth、payment-retry
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 · 125 lines · 60 tokens per session scan A d8171e7dd64e
spec is a skill published in the GitHub repository SimpleEve/development-skills (33 stars, last pushed 5mo ago), licensed MIT. It adds 60 tokens to every session and 1,093 once invoked, about $0.0003 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
to-issues
Decompose a PRD and/or SPEC into implementable, vertically-sliced Issues with real blocking edges, then create them in your chosen platform (GitHub or Local). Use after /prd (and optionally /prd-to-spec) to turn requirements into agent-ready tickets. Triggers on: create issues, to-issues, 创建issue, 拆解issue, 生成卡片, 创建卡片…
article-icons
Illustrate an article (Markdown, HTML, etc.) with animated-style icons from itshover.com/icons. Fetches icons as clean inline SVG and places them at section headings, key concepts, lists, and callouts. Triggers on: /article-icons, 配图, 给文章配图标, add icons to article, illustrate with icons.
code-refactoring-assistant
Suggest and apply code refactorings to improve readability, maintainability, and code quality. Use this skill when improving existing code structure, eliminating code smells, applying design patterns, simplifying complex logic, extracting duplicated code, renaming for clarity, or preparing code for new features.…
bug-to-patch-generator
Generate code fixes and patches from bug reports, failing test cases, error messages, and stack traces. Use this skill when debugging code, fixing test failures, addressing GitHub issues, resolving runtime errors, or patching security vulnerabilities. Analyzes the bug context, identifies root causes, and generates…
code-comment-generator
Generates meaningful comments and documentation for code to improve maintenance and readability. Use when adding documentation to Python or Java code, including function/method docstrings, class documentation, inline explanations for complex logic, and code annotations (TODO, FIXME). Analyzes existing comment style in…
code-smell-detector
Identify and report code smells indicating poor design or maintainability issues in Python code, including duplicate code, magic numbers, hardcoded values, God classes, feature envy, inappropriate intimacy, data clumps, primitive obsession, and long parameter lists. Use when conducting code quality audits, preparing…