メニュー
Use when implementing any change in existing code — when tempted to clean up nearby code, add unrequested validation or options, fix something "arguably in scope", or when the diff is growing past what was asked.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Run a large, multi-place, uncertain task to completion via "plan → adversarial review → serial execute → synthesize & verify." Trigger: cross-file refactor, data migration, large feature build, system audit, deep research — tasks that can't be done in one pass and touch many places. Manual invocation: /deep-work.
Use when asked to implement, build, add, fix, refactor, or change anything non-trivial in a codebase — especially vague asks ("do that", "make it work") that need clarification, planning, and verified delivery with tests and commits
Opinionated CORE Laravel 13 + Pest 4 conventions, applied by default on any Laravel project — artisan-first file creation, Eloquent/migration/queue/ scheduler patterns, fail-closed multi-tenancy, parallel-safe tests, and a "verified before done" bar. Composes with (never duplicates) maestro's stack-agnostic discipline. Use when / Trigger: editing or creating anything in a Laravel codebase — models, migrations, factories, jobs, scheduled commands, Filament resources, or Pest tests; whenever you reach for a file generator, design a schema/relationship, write a queued job or a tenant-scoped query, or are about to call a Laravel task "done."
Use before ending any turn that used tools or produced a deliverable — when tempted to ask "Want me to…?", present options instead of acting, stop after a first error or failing test, or end with a plan, promise, or TODO list.
Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits.
The discipline behind maestro:regression — prove a change didn't break existing work by running the suite, an adversarial bounded blast-radius probe against documented architecture contracts, and honest coverage, then emit a verdict taskmanager's done-gate enforces. Trigger: a change is about to be marked done / committed and you must confirm it didn't regress existing behavior or violate a documented boundary.
| name | scope-discipline |
| description | Use when implementing any change in existing code — when tempted to clean up nearby code, add unrequested validation or options, fix something "arguably in scope", or when the diff is growing past what was asked. |
Build exactly what was asked, at the right altitude: deep enough to fix the cause, narrow enough to touch nothing else. Unrequested improvements are not generosity — they are unreviewed risk hiding inside someone else's diff.
| Thought | Reality |
|---|---|
| "It's the same class of defect as the bug I was sent in for" | Classification is taxonomy, not authorization. The user named one defect. |
| "It lives in the same function's contract" | Location again. Contracts change by decision, not by proximity to your cursor. |
| "Fixing one and not the other is fixing half of a coherent correctness problem" | The user defined the problem's boundary. "Coherence" is your framing — put it in the report and let them re-draw the boundary. |
| "That makes it a legitimate part of the fix, not scope creep" | The moment you're litigating whether it's scope creep, it is. Done-with-the-argument ≠ authorized. |
| "Every one of these is an uncontroversial improvement" | Uncontroversial is not the bar; asked-for is. Improvements travel in their own reviewable diff. |
| "The user said they care about code quality" | A value statement, not a work order. Quality includes atomic, revertible, reviewable diffs. |
