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/misonl/ling/plan-writingnpx skills add MisonL/Ling --skill plan-writinggit clone --depth 1 https://github.com/MisonL/LingWhat 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.00035 | $0.01265 |
| Opus 5 | $0.00017 | $0.00633 |
| Sonnet 5 | $0.00007 | $0.00253 |
| Haiku 4.5 | $0.00003 | $0.00127 |
Grade A, and why
plan-writing scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
| “测试 API” | “`curl localhost:3000/api/users` 返回 200” | How it starts
The opening of the file, as written. The whole thing — 153 lines — stays where its author put it; the contents beside it link to each section on GitHub.
计划编写
来源：obra/superpowers
概览
该技能提供一套框架，用于将工作拆解为清晰、可执行、可验证的任务。
任务拆解原则
1. 小而聚焦的任务
- 每个任务建议控制在 2-5 分钟内
- 每个任务只对应一个明确结果
- 每个任务都应可独立验证
2. 明确的验证标准
- 如何判断它已经完成？
- 可以检查/测试什么？
- 预期输出是什么？
3. 合理的执行顺序
- 识别任务依赖关系
- 尽可能并行执行
- 标出关键路径（Critical Path）
- 阶段 X：验证（Verification）永远放在最后
4. 在项目根目录动态命名
- 计划文件保存为项目根目录下的
{task-slug}.md - 文件名由任务语义派生（例如“添加鉴权” ->
auth-feature.md） - 绝不能放在
.claude/、docs/或临时目录中
规划原则（不是模板）
[CRITICAL] 不要使用固定模板。每份计划都必须匹配当前任务。
原则 1：保持简洁
| [FAIL] 错误 | [OK] 正确 |
|---|---|
| 50 个任务并含多层子任务 | 最多 5-10 个清晰任务 |
| 罗列所有微步骤 | 只保留可执行项 |
| 描述冗长 | 每个任务一行说明 |
规则： 如果计划超过 1 页，通常就过长了。请继续精简。
原则 2：具体，不要泛化
| [FAIL] 错误 | [OK] 正确 |
|---|---|
| “搭建项目” | “运行 npx create-next-app” |
| “添加鉴权” | “安装 next-auth，并创建 /api/auth/[...nextauth].ts” |
| “美化界面” | “为 Header.tsx 添加 Tailwind 类” |
规则： 每个任务都要有清晰且可验证的完成结果。
原则 3：按项目类型动态生成内容
对于新项目（NEW PROJECT）：
- 技术栈是什么？（先决定）
- MVP（最小可行产品）是什么？（最小功能集合）
- 文件结构如何设计？
对于功能新增（FEATURE ADDITION）：
- 会影响哪些文件？
- 需要哪些依赖？
- 如何验证功能可用？
对于缺陷修复（BUG FIX）：
- 根因是什么？
- 需要改哪一个文件/哪一行？
- 如何验证修复有效？
原则 4：脚本必须与项目匹配
[CRITICAL] 不要复制粘贴脚本命令。必须按项目类型选择。
| 项目类型 | 相关脚本 |
|---|---|
| Frontend/React（前端/React） | ux_audit.py, accessibility_checker.py |
| Backend/API（后端/API） | api_validator.py, security_scan.py |
| Mobile（移动端） | mobile_audit.py |
| Database（数据库） | schema_validator.py |
| Full-stack（全栈） | 根据修改范围组合上述脚本 |
错误： 每份计划都塞入所有脚本
正确： 仅保留与当前任务相关的脚本
原则 5：验证应简单直接
| [FAIL] 错误 | [OK] 正确 |
|---|---|
| “验证组件工作正常” | “运行 npm run dev，点击按钮，看到 toast” |
| “测试 API” | “curl localhost:3000/api/users 返回 200” |
| “检查样式” | “打开浏览器，确认深色模式切换可用” |
计划结构（灵活而非固定）
# [任务名称]
## 目标（Goal）
一句话：我们要构建/修复什么？
## 任务（Tasks）
- [ ] 任务 1：[具体动作] -> 验证：[如何检查]
- [ ] 任务 2：[具体动作] -> 验证：[如何检查]
- [ ] 任务 3：[具体动作] -> 验证：[如何检查]
## 完成标准（Done When）
- [ ] [主要成功标准]
就这些。 除非确实必要，否则不要额外加阶段和子章节。
保持最小化，只有在需要时才增加复杂度。
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 · 153 lines · 35 tokens per session scan A 3872e050f1a8
plan-writing is a skill published in the GitHub repository MisonL/Ling (9 stars, last pushed 5mo ago), licensed MIT. It adds 35 tokens to every session and 1,265 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). 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…