菜单
Guidance for designing from the outside in. Use when designing a feature, an API, a CLI, or any interface. Start from the experience of whoever will use the thing, the user, the caller, the operator, and work back to the implementation, not the other way around.
用 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 | experience-first |
| description | Guidance for designing from the outside in. Use when designing a feature, an API, a CLI, or any interface. Start from the experience of whoever will use the thing, the user, the caller, the operator, and work back to the implementation, not the other way around. |
Design that starts from the implementation produces things that are convenient to build and awkward to use. Start from the experience you want on the other side, and let that pull the implementation into shape.
Before building, write the call site, the command, or the screen flow as you wish it existed. The ergonomics you want at the point of use are the requirements; the implementation's job is to deliver them, not to dictate them.
For a product feature, design from the user's experience. For an API, from the caller's ergonomics. For a tool or service, from the operator's. Name whose experience leads, and make their common path the easy one.
The default should be the correct, safe, common case; the unusual case can cost more. If the easy path is the wrong one, people will take it anyway and you'll own the consequences.
When wrapping something external, shape the interface around what your side actually needs, not around the vendor's API. Genericize from your own use, so the abstraction fits the experience you're building, not the tool you happened to pick.
