菜单
Use when a decision, gotcha, or preference would otherwise be re-derived next session — capture it as an indexed note, then verify before trusting stale ones.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
| name | decision-memory |
| description | Use when a decision, gotcha, or preference would otherwise be re-derived next session — capture it as an indexed note, then verify before trusting stale ones. |
When you discover why something must be done a certain way — a decision, a trap, a preference — write it down at that moment as a small, dated, cross-linked note. A rationale that lives only in chat history is lost the instant the session ends, and the next session pays to re-derive it.
Reach for this the moment you learn something a future session would otherwise have to rediscover:
Red-flag thoughts — if you catch yourself thinking any of these, STOP and write the note:
The expensive part of agent work is not typing code — it's the reasoning that produced a non-obvious choice. That reasoning is path-dependent: it took a failed attempt, a confusing error, or a careful experiment to arrive at. If it evaporates with the chat, the next session repeats the failure, re-reads the same docs, and re-runs the same dead-end experiment. A two-line indexed note converts that one-time cost into a permanent asset. The index and cross-links are what make it retrievable — an un-indexed note is nearly as lost as no note. And the verify step is what keeps the memory trustworthy: a stale note that's blindly trusted is worse than no note, because it actively misleads.
On the project this was distilled from — a hexagonal, human-in-the-loop AI agent shipped to a cloud runtime — an end-to-end run wrote its results to an evidence JSON file, and one field flagged a serialization library quietly warning that its current message format "will be blocked in a future version." Rather than let that scroll past in the run log, the agent captured it as a forward-compat note in that evidence JSON: the symptom, the two remediations (register the domain models with the serializer, or keep the library pinned before any major upgrade), and a pointer to the ops-runbook's troubleshooting section. A separate note recorded a live gotcha — the search index lags document creation, which matters for test timing but not for real usage — so a future session wouldn't "fix" a non-bug. All notes sat behind a single index file that listed each workstream and its state (one eval task marked done, the next marked next). When a licensing flag later flipped, the relevant note was edited in place rather than left to contradict reality. None of this requires knowing that specific project: the move is discover → write one small dated note → index it → link it → verify before reuse, in whatever note store your setup provides (a memory/ folder, a docs directory, an issue tracker, an ADR log).
What a machine can check: that no note can be silently orphaned. An index-completeness check — every note linked from the index, every link resolving (this pack's own check-readme-index and check-crosslinks-resolve are the worked pattern) — and dates on every note so staleness is at least visible. Whether a note still holds is judgment the skill already assigns (verify before trusting); the machine just guarantees you can find what needs verifying.
Related skills:
