메뉴
Guidance for doing the least work that fully solves the problem. Use on any task. Reuse before building, don't solve problems you don't have, don't gold-plate, and automate the repetitive, while holding "fully solves" as the hard constraint.
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 | laziness-protocol |
| description | Guidance for doing the least work that fully solves the problem. Use on any task. Reuse before building, don't solve problems you don't have, don't gold-plate, and automate the repetitive, while holding "fully solves" as the hard constraint. |
Productive laziness is doing the least work that completely solves the problem. The discipline is in both halves: the least work, and completely. Cutting effort is good; cutting correctness is not laziness, it's just a bug you'll pay for later.
Check whether something that already exists solves this, with a small adaptation, before writing a new thing. The cheapest code is the code you didn't write and don't have to maintain.
Build for the need in front of you, not for imagined future ones. Gold-plating, extra options, and speculative generality are work that adds permanent cost for a benefit that may never arrive.
If you've done the same manual sequence three times, the lazy move is to automate it so you never do it a fourth. Spend once to stop spending repeatedly.
Laziness that leaves the problem half-solved, or quietly drops a case, is false economy: it reappears as a bug, a support ticket, or a redo. Do less, but finish.
