Menu
Use when a task needs an implementation-ready design document before code changes begin.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when auditing comments, docstrings, or embedded documentation prose in a scope — to strip bloat and rewrite cluttered-but-justified entries. Triggers on "audit comments", "clean up docstrings", "strip stale comments", "comment cleanup".
Use when the goal is to reduce code size, remove unnecessary complexity, or simplify a module without removing user-facing behavior.
Use when auditing and fixing end-to-end contracts and compatibility in a scope — HTTP/RPC APIs, events/messages, schemas, files, CLIs, libraries, configuration, database consumers, and external integrations. Triggers on "audit contracts", "API compatibility review", "schema compatibility audit", "check producer/consumer drift", "compatibility review", and "contract review". Performs an architecture-led review of semantic, backward, forward, and mixed-version compatibility; named interface classes are a minimum, never an exhaustive boundary.
Use when auditing and fixing logic bugs in a scope — off-by-one, wrong operator, inverted condition, unhandled boundary cases, unit/dimension mismatch, code that doesn't do what its name or docstring claims. Triggers on "audit correctness", "fix logic bugs", "check for off-by-one", "correctness review".
Use when auditing and fixing end-to-end data integrity in a scope — invariant violations, partial or conflicting writes, unsafe migrations/backfills, duplicate or reordered effects, precision or time corruption, stale derived stores, broken retention/deletion, and unrecoverable drift. Triggers on "audit data integrity", "review data consistency", "check migrations and invariants", "find data corruption", and related requests. Named risks are minimum, never exhaustive.
Use when auditing and fixing error handling in a scope — swallowed exceptions, defaults returned on error, optional chaining masking missing data, floating promises / missing awaits, entry points with no error boundary, resource leaks on error paths. Triggers on "audit error handling", "hunt silent failures", "fix swallowed errors", "check error boundaries", "missing await".
| name | plan |
| description | Use when a task needs an implementation-ready design document before code changes begin. |
task = $ARGUMENTS
Create the minimum implementation-ready plan: one canonical, self-contained HTML artifact that is both the human approval surface and the complete contract for a fresh coding agent with access to the plan and repository.
Research until the relevant behavior, change surface, constraints, reusable patterns, decisive tradeoffs, and acceptance boundary are clear. Cite repository precedent as file:line wherever the design adopts or departs from an existing pattern. Search current vendor documentation, libraries, and open-source prior art when an unfamiliar API, new pattern, or consequential design choice could change the decision; record the decisive fact and provenance, not the research process. Resolve every material in-scope uncertainty with evidence or user input. Treat hypothetical future needs as non-goals.
<artifact_contract>
Save or update docs/plans/<type>-<short-name>.html. Do not create companion requirements, research, task, or handoff files.
Describe the reviewed target state: what must exist and why, one abstraction level above pseudocode. Exclude code, pseudocode, statement-level mechanics, implementation order, task decomposition, verification commands, placeholders, open questions, and deferred decisions.
The artifact must carry all decision context required for implementation. External links are provenance, never required context. Use semantic HTML, in-file CSS, inline SVG where useful, explicit page and text colors, and no external assets or runtime. </artifact_contract>
The first screen is a visual nutshell: outcome, before → after, selected design, scope and non-goals, and observable acceptance. Every non-trivial plan includes at least one decision-bearing visual.
Select views by the question they answer; combine, omit, or introduce another view as the design warrants:
Visuals replace equivalent prose rather than repeat it. Keep labels, legends, and captions precise enough that each visual communicates an implementation constraint, not decoration.
Progressively disclose only what implementation requires:
Adapt, combine, or omit sections according to the task. Do not create ceremonial coverage. Keep the concise approval surface and detailed executor contract in the same file without duplicating them.
Before saving, read the artifact as a fresh coding agent. If it could choose the wrong behavior, interface, boundary, or code location, add the missing contract or evidence. If a detail dictates statements or execution sequence, remove it.
Present the completed artifact for explicit human approval and stop. Do not implement or run an independent review unless the user requests it. Approval freezes the artifact; a material execution conflict requires revising the affected design and obtaining approval again.
