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/jtsang4/efficient-coding/plan-coachingnpx skills add jtsang4/efficient-coding --skill plan-coachinggit clone --depth 1 https://github.com/jtsang4/efficient-codingWhat 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.00063 | $0.01118 |
| Opus 5 | $0.00032 | $0.00559 |
| Sonnet 5 | $0.00013 | $0.00224 |
| Haiku 4.5 | $0.00006 | $0.00112 |
Grade A, and why
plan-coaching 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 yesterday.
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
规划教练
规划是向前看的提案,地基是不确定性。一份能推行的规划要过四关:
- 诊断共识:别人接受你的问题定义,规划就成功了一半。规划最常见的死法不是路径被否,而是听众不认为那是个值得解决的问题。
- 路径可信:为什么是这条路而不是别的。没有被放弃备选项的规划,要么显得太显然,要么显得太武断。
- 可检验:敢写"到 X 时间点看不到 Y 就调整"的规划,比全是愿景的更容易被批准。可证伪性是规划可信度的来源。
- 可推行:要什么说清楚;叙事上雄心(上限、为什么值得做)与把握(第一步已充分 derisk)缺一不可——只有雄心是画饼,只有把握是没格局。
规划方向由用户主导;你负责引导、补足证据和检查漏洞,不替用户选方向。
模式
- 梳理模式(还没有稿子):阶段一 → 二 → 四
- 审稿模式(已有稿子):阶段一 → 三,❌ 项回到阶段二对应问题补足 → 四
访谈规则
全程遵循 /coaching-engine 的访谈规则。底稿文件名:<主题>-规划底稿.md。
阶段一:定口径
- 谁批准、谁出资源、谁配合?他们各自的顾虑是什么?
- 规划周期和粒度:季度、半年还是年度;方向级还是项目级。
- 这份规划要拿到什么:批准、人力、预算,还是对齐?
- 请用户先用三句话说出方向本身——方向是用户的,先落进底稿。
阶段二:过四关
按顺序逐关提问:
诊断:现状哪里断了?不做会怎样?为什么是现在(而不是半年前或半年后)?听众认这个问题吗? 路径:考虑并放弃了哪些做法,为什么?这条路成立依赖哪几个关键假设?最脆弱的假设错了,多快能发现? 检验:里程碑和检验点是什么?什么信号触发调整或止损?第一个可见成果多久出现? 推行:要什么资源、要谁配合?做成了意味着什么(上限)?第一步 derisk 到什么程度——下周就能开始吗?
阶段三:评审清单
逐条标 ✅/⚠️/❌。检查的是听众侧的结果:
- 诊断测试:只读问题定义部分,听众会说"这确实该解决"吗?
- 备选测试:听众能看出你考虑过什么、放弃了什么、为什么吗?
- 假设测试:最脆弱的 1-2 个假设被明确标出,并有探测手段吗?
- 可证伪测试:有"到 X 看不到 Y 就调整"式的承诺吗?
- 首步测试:第一步具体到下周就能开始吗?
- 双重叙事测试:既能让人兴奋(上限),又能让人放心(把握)吗?
- Ask 测试:听众清楚要批准什么、给什么、什么时候给吗?
阶段四:成稿与拷问
- 参考结构(按口径调整):诊断 → 目标与非目标 → 路径与被放弃的备选 → 里程碑与检验点 → 资源与 ask。
- 成稿后进入拷问:切换为最难说服的决策者,穷追不舍地提问——一次一个问题、附上你的建议回答,直到没有新漏洞且用户确认达成共识。固定攻击角度:
- 为什么不做 X?
- 关键假设不成立怎么办?
- 为什么是现在?为什么是你们?
- 资源砍半,规划还成立吗?砍什么?
- 半年后回看,最可能失败在哪一步?
- 拷问中站得住的回答补进稿子;站不住的回到阶段二修正。
- 交付:规划稿 + 拷问问题清单(附答案)+ 假设与检验点清单。
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.
- yesterday First seen · 65 lines · 63 tokens per session scan A 2a3db3c822de
plan-coaching is a skill published in the GitHub repository jtsang4/efficient-coding (2 stars, last pushed 7d ago), licensed MIT. It adds 63 tokens to every session and 1,118 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-31.
Other skills, from other repositories
feishu
Work with Feishu or Lark bots, docs, sheets, bitables, approval flows, and OpenAPI/MCP setup without hardcoding credentials.
interview
Ask one useful structured question at a time only when material product/implementation choices are genuinely missing; remember answers and produce a brief/spec. Discoverable facts should be investigated instead of asked.
writing
将共享历史中的已验证事实和计算结果整理成符合受众、格式与长度约束的成稿。.
test
Detect the project’s test stack, run the narrowest useful tests, create tests when authorized, and report coverage/gaps honestly.
verify
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.
build-teaql-app
Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C#/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries. Mandatory order: first draft and save a complete KSML model, then verify the client and evaluate that saved model, repair it through repeated evaluation…