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/report-coachingnpx skills add jtsang4/efficient-coding --skill report-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.00068 | $0.01143 |
| Opus 5 | $0.00034 | $0.00571 |
| Sonnet 5 | $0.00014 | $0.00229 |
| Haiku 4.5 | $0.00007 | $0.00114 |
Grade A, and why
report-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)而非存量清单,都是"最小化听众认知成本"的推论。
- 决策:给听众做决策所需的材料。汇报的基本单元是"判断 + 证据 + 含义",不是"产出"。
- 信任:汇报是重复博弈,长期积累的资产是"我的判断可以被直接相信"。缺口透明、归因克制是信任投资——一个被戳穿的美化数字,成本超过十个诚实的缺口。
文档长什么样是口径的产物,不预设固定模板。
模式
- 梳理模式(用户还没有稿子):阶段一 → 二 → 四
- 审稿模式(已有稿子):阶段一 → 三,❌ 项回到阶段二对应问题补足 → 四
访谈规则
全程遵循 /coaching-engine 的访谈规则。底稿文件名:<主题>-汇报底稿.md。
阶段一:定口径
依次确认(口径决定三件事中哪件占主导,以及全文详略):
- 汇报对象是谁?他们最关心什么、最可能挑战什么?
- 场合与形式:书面还是口头,多长时间。
- 时间范围;与上次汇报的关系——哪些是存量、哪些是增量、上次承诺了什么、兑现了没。
- 你希望听众带走的那一个判断是什么?你想要什么(资源、决策、认可、继续投入)?
参考:述职以信任与判断力展示为主;项目状态汇报以校准为主;争取资源以决策为主。
阶段二:提炼判断
对每块工作依次问四个问题:
- 这件事从什么状态推进到了什么状态?→ 逼出阶段判断
- 它对业务意味着什么?没有它会怎样?→ 逼出 so-what
- 有什么没做完、失败了、被拒绝了?打算怎么解释?→ 逼出缺口与归因
- 有什么数字?分母是什么?趋势如何?哪些结论它撑不住?→ 逼出数字的边界
阶段三:听众测试清单
逐条标 ✅/⚠️/❌。检查的是听众侧的结果,不是文档特征:
- 30 秒测试:听众读 30 秒后,能复述出你的核心判断吗?
- 删减测试:每一节删掉产出细节后,还剩一句站得住的话吗?
- 先手测试:听众自己能发现的缺口,有没有任何一个不是你先说的?
- 追问测试:每个数字被追问两层(分母、趋势、归因边界)后还站得住吗?
- 载体测试:最想让人记住的论点,有一个 10 秒能看懂的载体(图、表或一句话)吗?
- 口径测试:听众清楚时间范围、与上次汇报的关系、承诺兑现情况吗?
- 行动测试:听完后,听众知道你要什么、接下来会发生什么吗?
常用手法(可选的实现方式,不是要求):首屏核心结论 callout、状态色标、每节以阶段判断收尾、"对业务的意义"列、闭环示意图、预期问题附录。
阶段四:成稿与预答辩
- 按口径成稿:从判断到证据(金字塔结构),以阶段二确认的判断为骨架。
- 为核心论点提出配图建议:画什么、图里写什么结论。
- 切换为最挑剔的听众,向用户发起 3-5 个最狠的提问(攻击数字、归因、缺口和"所以呢"),一次一个、附上你的建议回答;站得住的答案补进稿子或预案。
- 交付:汇报稿 + 预期问题清单(附答案)+ 配图清单。
若材料同时包含向后看的总结与向前看的规划:本 skill 处理向后看部分,规划部分交给 /plan-coaching。
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 · 67 lines · 68 tokens per session scan A 26b7b010fc37
report-coaching is a skill published in the GitHub repository jtsang4/efficient-coding (2 stars, last pushed 7d ago), licensed MIT. It adds 68 tokens to every session and 1,143 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…