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 skills add YangFan-Code-Star/context-dev --skill ship-changegit clone --depth 1 https://github.com/YangFan-Code-Star/context-devWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yangfan-code-star/context-dev/ship-change)<a href="https://agentmods.dev/skills/yangfan-code-star/context-dev/ship-change"><img src="https://agentmods.dev/badge/skills/yangfan-code-star/context-dev/ship-change/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yangfan-code-star/context-dev/ship-change"><img src="https://agentmods.dev/badge/skills/yangfan-code-star/context-dev/ship-change.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00072 | $0.01755 |
| Opus 5.5 | $0.00029 | $0.00702 |
| Sonnet 5.5 | $0.00014 | $0.00351 |
| Haiku 4.5 | $0.00007 | $0.00176 |
Grade A, and why
ship-change 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 1mo 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
交付一次改动
目的是让"收尾"不依赖记性。多数项目的文档腐烂不是因为没人愿意写，而是因为写文档不在流程里。
流程
- [ ] 1. 对范围
- [ ] 2. 摸清现状
- [ ] 3. 定方案（有取舍才需要）
- [ ] 4. 实现
- [ ] 5. 自测
- [ ] 6. 收尾同步
- [ ] 7. 复盘蒸馏
1. 对范围
先看项目根目录的 docs/roadmap.md。不在里面的需求，先补一条再动手——不是走形式，是为了在写代码之前发现"这个其实不该做"。
同时确认边界：这次做什么、明确不做什么。把不做的部分说出来，比默默不做要好，用户会当场纠正你的理解偏差。
2. 摸清现状
动手前先读相关代码。重点是已有的模式：类似的功能现在是怎么写的？有没有可以复用的工具函数？
新代码应该读起来像周围的代码——命名习惯、错误处理方式、注释密度、目录约定都要对齐。写出一段风格突兀的正确代码，也是一种债。
如果本次改动范围内还有轻量初始化留下的 TODO(init) 欠账，停下来问清那一格，补上再继续；与本次改动无关的欠账不要顺手全补。
3. 定方案
只有存在真实取舍时才需要这一步。有的话，把两个方案和各自的代价说给用户听，选定后走 /record-decision 记下来。
没有取舍就直接做，不要为了显得严谨而编造一个方案对比。
4. 实现
范围与验证的口径以 AGENTS.md 的铁律为准，这里不复述一份——两处都写就会漂，改一处忘另一处，agent 读到互相矛盾的两句话。本步只补铁律没说的操作细节：
- 小步走，每一步都保持仓库可运行。
- 用最直接的方式实现，最小改动优先。 新建文件、引入依赖、加抽象层（接口 / 工厂 / 基类 / 配置文件），必须先有一句"现有结构为什么不够"的理由；没有理由就内联、就地改，不要为"以后可能要用"预支复杂度。能一个函数解决的不建模块，能改现有代码的不另起一套。
- 注释只写"为什么"——约束、取舍、来源。不写"这行在做什么"，更不要写"我把这里改成了 X"这种给 reviewer 看的话。
- 不确定的地方停下来问，不要猜一个 API 的行为然后写下去。
5. 自测
跑哪些命令、跑到什么范围，以 AGENTS.md 的验证命令表和铁律为准——那是这个项目验证口径的唯一来源，本步不再复述。
这里只补它管不到的部分：跑完问自己，边界情况处理了吗（空输入、零、负数、超长、并发、网络失败）？失败路径试过吗，还是只跑通了顺利路径？
通过一次就停。 不要反复读同一个文件、重复跑同一命令来"确认"同一结果，也不要为一次小改动额外编写探索性验证脚本。范围在步骤 1 已经对齐，超出的验证意味着范围又漂了。
6. 收尾同步
这一步是这个技能存在的理由。逐条过：
| 如果这次改动 | 就更新 |
|---|---|
| 加了或改了命令 | AGENTS.md 命令表 |
| 加了顶层目录 | AGENTS.md 目录地图 |
| 引入了新的领域概念或口径 | docs/glossary.md |
| 改变了分层或数据流 | docs/architecture.md |
| 包含有取舍的技术选择 | 新的 ADR（/record-decision） |
| 完成或改变了 roadmap 条目 | docs/roadmap.md 状态 |
| 排查超过 20 分钟才解决的问题 | docs/troubleshooting.md（已确认事实，直接写） |
| 暴露出上下文里缺了一条违反后果不可逆或不可发现的高风险规则 | AGENTS.md 加一条铁律（唯一允许立即进铁律的情形） |
| 暴露出上下文里缺了一句话，但风险没到不可逆/不可发现 | docs/learning-inbox.md（待第二次出现再晋升） |
本次改动范围内还有轻量初始化留下的 TODO(init) 欠账 |
现场问清后填入对应文件，范围外的留给 /ship-change 或 /maintain-context |
和代码在同一次提交里更新，不要留到"以后统一整理"——那个"以后"不会到来。
7. 复盘蒸馏
收尾同步是把「改了什么」写回文档，这一步是把「学到了什么」写进收件箱——前者更新现状，后者更新理解，两者分开。
任务里出现过四种信号中的任何一种——我一开始理解错了什么 / 用户纠正了我什么 / 我花了超过 20 分钟才搞清什么 / 同一个流程或概念被解释了 2 次以上——先问自己：这件事是不是已经在步骤 6 写进权威文件了？写过了就不要重复入箱；收件箱只装待观察、待第二次出现再晋升的候选（通常是「纠正」和「流程」两类）。「坑」类在步骤 6 已写进 docs/troubleshooting.md，不重复入箱；「澄清」类如果已在步骤 6 更新了 goals.md / glossary.md / architecture.md，也不重复入箱。每种信号对应的类型、去向和条目格式都写在 docs/learning-inbox.md 里，追加时必然要打开它，这里不重复一份。
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.
- 1mo ago First seen · 97 lines · 72 tokens per session scan A b6632075a949
ship-change is a skill published in the GitHub repository YangFan-Code-Star/context-dev (2 stars, last pushed 2mo ago), licensed MIT. It adds 72 tokens to every session and 1,755 once invoked, about $0.0003 per session on Opus 5.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
openspec-bulk-archive-change
Archive multiple completed OpenSpec changes at once. Use when archiving several parallel changes. Also use for a plural archive request - "openspec bulk-archive", "opsx bulk-archive", "openspec archive all", or "openspec archive these changes".
openspec-bulk-apply-change
Use when multiple active OpenSpec changes should be applied concurrently in isolated worktrees with delegated verification and no merge.
openspec-new-change
Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach. Also use when the user says "openspec new change" or "opsx new".
openspec-archive-change
Archive a completed OpenSpec change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. Also use when the user says "openspec archive" or "opsx archive".
product-manager
A product-management guide covering work from discovering a need through launch and measurement. It includes tools such as PRDs, which describe a product requirement, and RICE, a method for ranking opportunities.
product-sprint-prioritizer
A product-planning skill that ranks a list of requests with frameworks such as RICE, a method that compares reach, impact, confidence, and effort. It can also organize work into iterations or Sprints, which are fixed periods for completing a selected group of tasks.