菜单
Guidance for writing code and docs that are cheap to read. Use when writing or reviewing any code, naming things, or structuring a module. Code is read far more than written, so reduce what a reader must hold in their head to understand it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Guidance for writing the test before the code. Use when building new behavior or fixing a bug — write the failing test first, watch it fail for the right reason, then make it pass. Test-first is a mandate with a few stated exceptions, not loose advice; reach for it before you write the implementation, not after.
Method for finding the cause of a bug, failing test, regression, or unexplained symptom whose cause is unknown. Use when something is broken and you don't yet know why — reproduce it, narrow by halving, instrument and read live state, and repair the root rather than silencing the symptom. Not for plan-writing or building features to a known design — but a senior-implementer whose own fresh build breaks reaches for this; it is the discipline for the unknown.
Procedure for gating work with fresh, independent, lensed hunters until a CLEAN verdict, and for front-running an external automated reviewer by tuning your own hunters to the bug categories it actually finds. Use at every quality gate: spec, plan, and code or PR review. Make sure to use this whenever reviewing or QAing substantive work before it advances, scaling the depth to the stakes.
Operating manual for the top-level orchestrator the user talks to: the single agent that receives the user's asks, dispatches each piece of work at the right depth (a direct specialist for a small task, or running the `team-manager` lifecycle itself for a big chunk), monitors everything in flight, surfaces decisions one at a time, and stays free. Use this whenever acting as the user's chief of staff or orchestrator: receiving asks, choosing dispatch depth, delegating to specialists or wearing the manager hat for an epic, health-checking running work, surfacing decisions, and presenting epic-bookend briefs. Make sure to use this skill whenever coordinating or delegating work, or when the user asks for status or a decision, even if "chief of staff" isn't said.
The hat the chief of staff wears to own an epic end to end (anything bigger than one PR); the operating manual for running an epic yourself, not a separate agent. Use this whenever owning a chunk end to end: triaging it, grooming an epic into slices and dispatching workers (one writer per branch), running the spec -> plan -> build lifecycle with adversarial review until clean, owning the integration branch and the never-draft merge model, health-monitoring those workers, and keeping progress visible and durable. It is also the canonical home of the integration-branch / serial-dependent-chain / never-draft model. Make sure to use this skill whenever running a chunk, triaging a backlog, managing workers, or moving work through its lifecycle, even if the role isn't named.
The ritual for taking completed, verified work up for review. Use the moment a build is done and ready to go up: when finishing a chunk, opening or putting up a PR, or shipping a change. Open the PR first to start the external reviewer, then in parallel run a swarm of fresh independent Opus hunters over the diff, reconcile their findings with the external reviewer's into one classified list, dispatch the `steward` to own closeout (rebase, paginate/triage threads, resolve, re-verify, merge to the integration branch), routing REAL bugs to the `bug-fixer` for root-cause repair, and loop until CLEAN. Make sure to use this whenever work is finished and about to go up for review, so you find your own bugs instead of waiting on the PR queue.
| name | minimize-reader-load |
| description | Guidance for writing code and docs that are cheap to read. Use when writing or reviewing any code, naming things, or structuring a module. Code is read far more than written, so reduce what a reader must hold in their head to understand it. |
Every line is written once and read many times, by reviewers, by teammates, by you in six months with no memory of today. Optimize for that reader, because they pay the recurring cost.
A reader understands a piece by keeping its moving parts in working memory. Fewer parts is easier. Short functions with one job, narrow scope, and few live variables at a time beat a clever block that requires tracking eight things at once.
A good name removes the need to read the implementation to know what something does. Name by what it means and why it exists, not by how it currently works, so the name survives the next refactor.
Put things that change together near each other, and keep the definition near the use. Locality lets a reader understand a change without paging through the whole file. Distance is cognitive cost.
A clever one-liner that takes a minute to decode is more expensive than three plain lines that take five seconds. Save cleverness for where it genuinely earns its keep, and delete dead paths so no one has to wonder whether they matter.
