Date: 2026-05-20
## Objectif
Donner a un autre developpeur un prompt autonome pour installer dans un repo les memes regles que celles ajoutees ici:
– un guard `adversarial-implementer-guard`;
– une obligation de l’utiliser apres tout changement de code substantiel et pendant les reviews;
– une discipline de progressive disclosure appliquee aux docs, specs, plans, code, APIs, prompts, tests, verifications et reviews;
– une regle racine dans `AGENTS.md` ou fichier equivalent;
– un miroir dans `CLAUDE.md` si ce repo l’utilise.
## Criteres d’acceptation
– Le repo contient un skill local `adversarial-implementer-guard` ou equivalent, cree si absent.
– Le fichier racine d’instructions agents impose le guard en post-coding et en review.
– La progressive disclosure est formulee comme contrainte de correction, pas comme preference stylistique.
– Le changement ne cree pas un second registre de skills ou de routes de gouvernance si `AGENTS.md` existe deja.
– Le prompt demande explicitement de ne pas supposer que le developpeur dispose deja du guard.
– Le resultat final indique les fichiers modifies et les verifications faites.
## Adversarial implementer pass
– Likely bad interpretation: le dev cree seulement un skill, mais oublie la regle racine qui force son usage.
– Guardrail added: le prompt exige `AGENTS.md` ou fichier equivalent comme source de verite.
– Likely bad interpretation: le dev ajoute une recommandation vague au lieu d’une obligation post-coding.
– Guardrail added: le prompt exige `MUST run after substantial code changes` et `first post-coding step`.
– Likely bad interpretation: le dev applique progressive disclosure uniquement a la documentation.
– Guardrail added: le prompt liste explicitement docs, specs, plans, code, APIs, prompts, tests, verifications et reviews.
– Likely bad interpretation: le dev cree un nouveau systeme de gouvernance parallele.
– Guardrail added: le prompt interdit de creer un second registre si une racine comme `AGENTS.md` existe.
– Existing behavior that must be preserved: les instructions existantes du repo restent en place, les sections ajoutees doivent completer sans supprimer les regles locales.
– Forbidden implementation shortcuts: ne pas remplacer tout `AGENTS.md`, ne pas ecrire un skill `sg-*`, ne pas cacher la regle uniquement dans un document de chat, ne pas creer un fichier geant si une section precise suffit.
– Regression proof required: relire le diff final et verifier que le guard est present dans le skill, dans la racine agents, et dans le miroir Claude si applicable.
## Prompt a donner au dev
« `text
Tu dois ajouter dans ce repo une regle fondamentale de qualite d’implementation. Attention: tu ne disposes pas encore du skill `adversarial-implementer-guard`; tu dois donc le creer ou le mettre a jour toi-meme dans ce repo, puis l’utiliser pour controler ton propre changement avant de finir.
Objectif:
– Creer ou mettre a jour un skill local `adversarial-implementer-guard`.
– Ajouter dans le fichier racine d’instructions agents du repo (`AGENTS.md` si present, sinon le fichier equivalent) une obligation d’utiliser ce guard:
– avant toute spec, plan, implementation prompt, architecture review, UX critique, handoff doc ou code review destinee a guider un autre dev;
– apres tout changement de code substantiel, comme premiere etape post-coding, avant polish UI, refactor opportuniste ou reponse finale.
– Ajouter une discipline de progressive disclosure applicable partout: docs, specs, plans, code, APIs/discovery, prompts/agents, tests, verifications et reviews.
– Si le repo a aussi un fichier `CLAUDE.md`, y ajouter un miroir court de ces memes regles pour que les agents Claude appliquent la meme discipline.
Contraintes:
– MUST preserve les instructions existantes du repo. Ajoute des sections ciblees, ne remplace pas tout le fichier.
– MUST keep `AGENTS.md` ou le fichier racine equivalent comme source de verite. Le skill est une procedure detaillee, pas un second registre concurrent.
– MUST NOT creer un nouveau registre de skills ou de gouvernance si un registre racine existe deja.
– MUST NOT creer de skill `sg-*` ou modifier des skills ShipGuard locaux si ce repo a une regle qui les reserve a un plugin externe.
– MUST make progressive disclosure a correctness constraint, not a style preference.
– MUST mention that new files should normally stay under roughly 200 lines; if a file must exceed that, split it or justify it.
Contenu minimum du skill `adversarial-implementer-guard`:
– Description: use when finishing substantial code changes, reviewing code, or writing specs/plans/prompts/reviews/handoffs.
– Required pass:
1. Preserve existing behavior and contracts: files, callbacks, routes, stores, database tables, queues, state machines, endpoints, pipelines.
2. Red-team dangerous wording such as `refactor`, `simplify`, `wire`, `orchestrate`, `reuse`, `clean up`, `support`, `improve`, `adapt`.
3. Convert ambiguity into hard constraints:
– MUST preserve …
– MUST call/use …
– MUST NOT replace …
– MUST NOT create a parallel engine/pipeline/store/router/state machine …
– MUST NOT remove working code unless the replacement is wired and verified end-to-end …
4. Add non-goals and forbidden shortcuts.
5. Add regression proof on real product/public entry paths, not only isolated components.
6. Enforce progressive disclosure across docs, specs, plans, code, APIs, prompts, tests, verification, and reviews.
– Post-coding mode:
– inspect the actual diff;
– check for parallel engines/pipelines/stores/routers/state machines/prompt paths/persistence contracts/UI workflows;
– check that existing public entry paths and runtime flows still reach the intended behavior;
– check that tests cover the real path;
– check file sizes and split broad files;
– report skipped or blocked verification.
– Code review mode:
– flag implementations that follow words but violate intent;
– flag ignored callbacks/props, duplicate pipelines, skipped tests, tests that only assert component presence, and over-broad prompts/docs/files that dump whole catalogs or doctrines.
– Handoff requirement:
– every substantial durable handoff must include a section named `Adversarial implementer pass`.
Contenu minimum a ajouter dans `AGENTS.md` ou fichier racine equivalent:
– Une section `Adversarial Implementer Guard` indiquant que le guard est obligatoire pour specs/plans/prompts/reviews/handoffs et apres tout changement de code substantiel.
– Une checklist post-coding:
– inspect actual changed files;
– no parallel engine/pipeline/store/router/state machine/route family/prompt path/persistence contract unless explicitly required;
– existing public entry paths, callbacks, endpoints, storage keys and runtime flows still work;
– tests/verification exercise real paths;
– skipped or blocked verification is reported.
– Une section `Progressive Disclosure Discipline`:
– docs/specs/plans: index/top-level plan + smaller phase/decision/domain/implementation files;
– code: split by responsibility, keep new files normally under ~200 lines;
– APIs/discovery: list/search returns summaries, detail endpoints return full detail on demand;
– prompts/agents: select targeted domains/capabilities before injecting details;
– tests/verification: start with smallest high-signal checks, broaden only as risk requires;
– UI: implement the real workflow first, no cosmetic polish before MVP workflow verification;
– reviews: read root context first, then only files needed to prove or disprove risks.
– Final wording: progressive disclosure is a correctness constraint; dumping all knowledge/domains/tests/UI into one large artifact is a failed implementation unless explicitly requested.
Si `CLAUDE.md` existe:
– Ajouter une section courte equivalent:
– post-code adversarial pass obligatoire;
– progressive disclosure partout;
– fichiers courts, summaries avant details, prompts cibles, tests/verifications graduels.
Verification attendue:
– Relis le diff final.
– Confirme que la regle existe a la fois dans le skill et dans le fichier racine agents.
– Confirme que le miroir `CLAUDE.md` a ete ajoute si applicable.
– Indique les fichiers modifies.
– Si aucun test automatique n’est pertinent parce que c’est un changement Markdown/regles, dis-le explicitement.
« `