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/plannpx skills add SimpleEve/development-skills --skill plangit 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.00061 | $0.01348 |
| Opus 5 | $0.00030 | $0.00674 |
| Sonnet 5 | $0.00012 | $0.00270 |
| Haiku 4.5 | $0.00006 | $0.00135 |
Grade A, and why
plan 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.
How it starts
The opening of the file, as written. The whole thing — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan - 实施计划技能
将已确认的 spec 文档转化为可执行落地的详细实施计划与任务清单。
核心原则
- 不猜测：代码侧的技术细节遇到不确定的，必须向用户澄清
- 不模糊：每个 TODO 子项必须描述清楚做什么、影响哪些文件、验收标准是什么
- 不写代码：不写详细实现代码，但可以描述接口签名、数据结构、模块职责
- 固定产出：输出到项目既有的需求目录；若无统一约定，建议使用
spec/<spec-name>/plan.md
前置条件
- 对应功能的
spec.md必须已存在且状态为"已确认" - 如果项目有统一文档目录，遵循现有约定；如果没有，建议使用
spec/<spec-name>/spec.md - 如果 spec 不存在，提示用户先执行
/spec
工作流程
第一步：阅读上下文
- 阅读对应功能的
spec.md - 阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在）
- 阅读现有代码结构，理解当前架构、模块划分、命名规范
- 阅读已有的其他 plan，理解整体技术方向一致性
第二步：技术澄清
- 识别 spec 中在代码层面仍有歧义的点
- 使用当前环境可用的提问方式向用户澄清技术选型、方案偏好
- 反复澄清直到所有技术决策确定
第三步：撰写 Plan
按照下方固定模板撰写，写入对应功能的 plan.md。
第四步：用户确认
将产出交给用户确认，根据反馈修订直到用户满意。
固定模板
# <功能名称> 实施计划
> 关联 Spec：<spec 文档路径>
> 创建日期：YYYY-MM-DD
> 状态：草稿 | 已确认
## 1. 技术方案概述
用 1-3 段话概述整体技术实现思路。
## 2. 技术决策
### 2.1 方案选型
如有多种实现方案，列出各方案的优劣对比，并标注最终选择及理由。
### 2.2 外部依赖
列出需要引入的第三方库、服务、SDK、引擎能力或工具。
### 2.3 内部依赖
列出依赖的内部模块、已有接口、资源或数据结构。
## 3. 任务拆解
### 3.1 核心逻辑 / Runtime / 运行时模块（按项目实际情况命名）
- [ ] **TODO-S1: <任务标题>**
- **描述**：详细说明要做什么
- **涉及模块**：对应子系统、运行时模块或核心逻辑层
- **涉及文件**：预估需要新建或修改的文件路径
- **依赖**：依赖哪些前置 TODO（如 TODO-S0）
- **验收标准**：完成后如何验证
- [ ] **TODO-S2: ...**
### 3.2 表现层 / Tooling / 工具模块（按项目实际情况命名）
- [ ] **TODO-C1: <任务标题>**
- **描述**：详细说明要做什么
- **涉及模块**：对应 UI 层、编辑器工具、页面、交互模块或辅助工具模块
- **涉及文件**：预估需要新建或修改的文件路径
- **依赖**：依赖哪些前置 TODO
- **验收标准**：完成后如何验证
- [ ] **TODO-C2: ...**
### 3.3 共享 / 通用模块
- [ ] **TODO-G1: <任务标题>**
- **描述**：类型定义、工具函数、配置、共享资源等通用部分
- **涉及文件**：...
- **依赖**：...
- **验收标准**：...
## 4. 依赖关系与执行顺序
用文字或 ASCII 图描述 TODO 之间的依赖关系，标明哪些可以并行。
示例：
- TODO-G1 → TODO-S1（G1 完成后 S1 才能开始）
- TODO-S2 ‖ TODO-C1（可并行）
## 5. 测试标准
### 5.1 单元测试标准
逐条列出每个 TODO 需要的单元测试覆盖点。
### 5.2 集成 / 场景验证标准
描述完整流程的集成测试或场景验证，包括：
- 前置条件
- 操作步骤
- 期望结果
- 异常场景
## 6. 风险与缓解
| 风险 | 影响 | 缓解措施 |
|------|------|---------|
## 7. 开放问题
列出所有尚未解决的技术问题。如全部已解决则标注"无"。
关键约束
- TODO 颗粒度：每个 TODO 应该是一个开发者能在 1-4 小时内完成的工作单元
- 并行友好：不同层次或模块的 TODO 应尽量解耦，方便并行开发
- 测试先行：每个 TODO 必须附带验收标准，测试标准章节必须完整
- 不写实现代码：可以描述"创建一个 XxxManager / System / Service，提供核心方法或职责边界"，但不要写出具体实现
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 · 138 lines · 61 tokens per session scan A 64104bd93711
plan is a skill published in the GitHub repository SimpleEve/development-skills (33 stars, last pushed 5mo ago), licensed MIT. It adds 61 tokens to every session and 1,348 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…