菜单
Guidance to apply before solving a problem: get the foundation right first. Use at the start of any non-trivial task, before designing or coding. Name what is actually being asked, the real constraints, the invariants, and the failure modes, so you don't build correctly on a wrong base.
用 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 | foundational-thinking |
| description | Guidance to apply before solving a problem: get the foundation right first. Use at the start of any non-trivial task, before designing or coding. Name what is actually being asked, the real constraints, the invariants, and the failure modes, so you don't build correctly on a wrong base. |
Most expensive mistakes are not bad code; they are good code built on an unexamined assumption. Spend the first effort on the foundation, because everything downstream inherits it.
Write, in a sentence, what is actually being asked, separate from the solution someone proposed. The proposed solution is often a guess at the problem; solve the problem, not the guess.
List what must always be true and what genuinely constrains the space (real limits, not inherited habits). These are the things a correct design has to respect; making them explicit is how you stop violating one by accident three layers in.
Ask what breaks this and what the worst input is, before you build the happy path. Designing with the failure cases in view produces a different, sturdier shape than bolting them on afterward.
When a plan rests on "I assume X," verify X or mark it as the risk. The cheapest place to catch a wrong foundation is before you have built on top of it.
