mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-08-29 03:44:18 +08:00
refactor(review): slim adversarial hunter prompt (#2675)
* refactor(review): slim adversarial hunter prompt across build and review skills Drop cynical-persona framing. Inline a short review prompt (≥10 findings, look for missing, empty/zero guards) into blind-hunter layer instructions for bmad-build, bmad-build-auto, and bmad-code-review. Delete the old review-prompts/adversarial.md files. Align offline no-subagent dump with the same child prompt. Update bmad-review's adversarial lens to the same method while keeping its canonical finding fields. * test(renderer): stop requiring deleted adversarial.md prompt file Blind hunter is inlined; assert the inlined prompt text and remaining file-backed review prompts instead. * docs: align adversarial review explanation with slim hunter prompt Document the finding floor and missing-not-only-wrong method instead of the old cynical persona. Update core-tools lens table and localized pages.
This commit is contained in:
Alex Verkhovsky
@@ -1,38 +1,39 @@
|
||||
---
|
||||
title: "Adversariální revize"
|
||||
description: Technika vynuceného uvažování, která zabraňuje líným „vypadá dobře“ revizím
|
||||
description: Vynucený seznam nálezů místo líného „vypadá dobře“
|
||||
sidebar:
|
||||
order: 7
|
||||
---
|
||||
|
||||
Vynuťte hlubší analýzu tím, že budete vyžadovat nalezení problémů.
|
||||
Vynuťte hlubší analýzu povinností najít skutečné problémy — ne cynickou personou.
|
||||
|
||||
## Co je adversariální revize?
|
||||
|
||||
Technika revize, kde recenzent *musí* najít problémy. Žádné „vypadá dobře“ není povoleno. Recenzent zaujme cynický postoj — předpokládá, že problémy existují, a hledá je.
|
||||
Technika, kde recenzent musí produkovat nálezy. „Vypadá dobře“ s prázdným seznamem není dovoleno.
|
||||
|
||||
Nejde o negativismus. Jde o vynucení skutečné analýzy místo povrchního pohledu, který automaticky schválí cokoli, co bylo předloženo.
|
||||
Mechanismus je **spodní hranice nálezů** (alespoň deset věcí k opravě nebo zlepšení) a explicitní tlak hledat **co chybí**, nejen co je špatně. Pokud je obsah prázdný, zastavte se. Pokud je seznam prázdný, zkontrolujte znovu — nekončete s ničím.
|
||||
|
||||
**Základní pravidlo:** Musíte najít problémy. Nulové nálezy spouštějí zastavení — analyzujte znovu nebo vysvětlete proč.
|
||||
Nejde o hostilitu. Starší prompty používaly unavenou personu; na dnešních modelech to nemění, co se najde. Stále platí povinnost hledat dál a preferovat opomenutí před zběžným průchodem.
|
||||
|
||||
## Proč to funguje
|
||||
|
||||
Běžné revize trpí konfirmačním zkreslením. Proletíte práci, nic nevyskočí, schválíte to. Mandát „najít problémy“ tento vzor rozbíjí:
|
||||
Běžné revize trpí konfirmačním biasem. Přelétnete práci, nic nevyskočí, schválíte. Hranice to láme:
|
||||
|
||||
- **Vynucuje důkladnost** — Nemůžete schválit, dokud jste nehledali dostatečně pečlivě
|
||||
- **Zachytí chybějící věci** — „Co zde není?“ se stává přirozenou otázkou
|
||||
- **Zlepšuje kvalitu signálu** — Nálezy jsou konkrétní a akční, ne vágní obavy
|
||||
- **Informační asymetrie** — Provádějte revize s čerstvým kontextem (bez přístupu k původnímu uvažování), abyste hodnotili artefakt, ne záměr
|
||||
- **Nutí důkladnost** — nelze skončit, dokud není dost konkrétních nálezů
|
||||
- **Chytá chybějící věci** — „co tu není?“ je součást práce
|
||||
- **Krmí triage, ne uživatele přímo** — v build a code-review rodičovská session filtruje šum; lovec má recall, ne finální verdikt
|
||||
- **Informační asymetrie** — lovci často běží s čerstvým kontextem změny
|
||||
|
||||
## Kde se používá
|
||||
|
||||
Adversariální revize se objevuje v celém BMad workflow — revize kódu, kontroly připravenosti implementace, validace specifikací a další. Někdy je to povinný krok, někdy volitelný (jako pokročilá elicitace nebo party mode). Vzor se přizpůsobí jakémukoli artefaktu, který potřebuje kontrolu.
|
||||
- **bmad-build / bmad-build-auto / bmad-code-review** — vrstva Blind Hunter: krátký inline prompt, obsah pod `CONTENT:`, paralelně s dalšími vrstvami, pak triage
|
||||
- **bmad-review** — adversariální čočka v multi-lens revizi (stejná metoda; kanonická pole nálezů pro sloučení)
|
||||
|
||||
## Vyžadováno lidské filtrování
|
||||
## Filtrování člověkem (nebo rodičem)
|
||||
|
||||
Protože AI je *instruována* najít problémy, najde problémy — i když neexistují. Očekávejte falešné pozitivy: malichernosti převlečené za problémy, nepochopení záměru nebo přímo vymyšlené obavy.
|
||||
Protože model má naplnit seznam, vyprodukuje i tenké, starší nebo chybné body. Falešné pozitivy se očekávají.
|
||||
|
||||
**Vy rozhodujete, co je skutečné.** Zkontrolujte každý nález, odmítněte šum, opravte to, na čem záleží.
|
||||
**Triage rozhoduje, co je skutečné.** V agentních tocích to je rodičovský workflow. V samostatné revizi jste to vy.
|
||||
|
||||
## Příklad
|
||||
|
||||
@@ -40,20 +41,15 @@ Místo:
|
||||
|
||||
> „Implementace autentizace vypadá rozumně. Schváleno.“
|
||||
|
||||
Adversariální revize produkuje:
|
||||
Adversariální průchod vyprodukuje seznam, např.:
|
||||
|
||||
> 1. **VYSOKÁ** — `login.ts:47` — Žádné omezení rychlosti neúspěšných pokusů
|
||||
> 2. **VYSOKÁ** — Session token uložen v localStorage (zranitelný vůči XSS)
|
||||
> 3. **STŘEDNÍ** — Validace hesla probíhá pouze na straně klienta
|
||||
> 4. **STŘEDNÍ** — Žádné auditní logování neúspěšných pokusů o přihlášení
|
||||
> 5. **NÍZKÁ** — Magické číslo `3600` by mělo být `SESSION_TIMEOUT_SECONDS`
|
||||
|
||||
První revize mohla přehlédnout bezpečnostní zranitelnost. Druhá zachytila čtyři.
|
||||
> 1. `login.ts:47` — žádný rate limiting při neúspěšných pokusech
|
||||
> … (alespoň deset konkrétních bodů)
|
||||
|
||||
## Iterace a klesající výnosy
|
||||
|
||||
Po řešení nálezů zvažte opětovné spuštění. Druhý průchod obvykle zachytí více. Třetí také není vždy zbytečný. Ale každý průchod zabere čas a nakonec dosáhnete klesajících výnosů — jen malichernosti a falešné nálezy.
|
||||
Po opravách další průchod ještě pomůže. Každý průchod stojí čas; nakonec zbývají jen nitky a falešné nálezy. Downstream triage a rozpočet smyček (v build) brání nekonečnému běhu.
|
||||
|
||||
:::tip[Lepší revize]
|
||||
Předpokládejte, že problémy existují. Hledejte, co chybí, ne jen co je špatně.
|
||||
Hledejte, co chybí, nejen co je špatně. Hledejte, dokud je seznam skutečný — pak ho ať triage zkrátí.
|
||||
:::
|
||||
|
||||
@@ -1,38 +1,41 @@
|
||||
---
|
||||
title: "Adversarial Review"
|
||||
description: Forced reasoning technique that prevents lazy "looks good" reviews
|
||||
description: Forced-finding review that blocks lazy "looks good" rubber stamps
|
||||
sidebar:
|
||||
order: 9
|
||||
---
|
||||
|
||||
Force deeper analysis by requiring problems to be found.
|
||||
Force deeper analysis by requiring a real list of issues — not a cynical persona.
|
||||
|
||||
## What is Adversarial Review?
|
||||
|
||||
A review technique where the reviewer *must* find issues. No "looks good" allowed. The reviewer adopts a cynical stance - assume problems exist and find them.
|
||||
A review technique where the reviewer must produce findings. "Looks good" with an empty list is not allowed.
|
||||
|
||||
This isn't about being negative. It's about forcing genuine analysis instead of a cursory glance that rubber-stamps whatever was submitted.
|
||||
The mechanism is a **finding floor** (at least ten issues to fix or improve) plus an explicit push to look for **what is missing**, not only what is wrong. If the content is empty, stop. If the list is empty, re-check — do not finish with nothing.
|
||||
|
||||
**The core rule:** You must find issues. Zero findings triggers a halt - re-analyze or explain why.
|
||||
It is not about sounding hostile. Older prompts used a jaded persona; that does not change what modern models find. What still matters is the obligation to keep searching and to prefer omissions over a cursory pass.
|
||||
|
||||
## Why It Works
|
||||
|
||||
Normal reviews suffer from confirmation bias. You skim the work, nothing jumps out, you approve it. The "find problems" mandate breaks this pattern:
|
||||
Normal reviews suffer from confirmation bias. You skim the work, nothing jumps out, you approve it. The floor breaks that pattern:
|
||||
|
||||
- **Forces thoroughness** - Can't approve until you've looked hard enough to find issues
|
||||
- **Catches missing things** - "What's not here?" becomes a natural question
|
||||
- **Improves signal quality** - Findings are specific and actionable, not vague concerns
|
||||
- **Information asymmetry** - Run reviews with fresh context (no access to original reasoning) so you evaluate the artifact, not the intent
|
||||
- **Forces thoroughness** — cannot finish until enough concrete issues are listed
|
||||
- **Catches missing things** — "what is not here?" is part of the job
|
||||
- **Feeds triage, not the user directly** — in build and code-review, a parent session filters noise into a short signal list; the hunter's job is recall, not final judgment
|
||||
- **Information asymmetry** — hunters often run with fresh context on the change, so they evaluate the artifact rather than replaying the author's intent
|
||||
|
||||
## Where It's Used
|
||||
|
||||
Adversarial review appears throughout BMad workflows - code review, implementation readiness checks, spec validation, and others. Sometimes it's a required step, sometimes optional (like advanced elicitation or party mode). The pattern adapts to whatever artifact needs scrutiny.
|
||||
- **bmad-build / bmad-build-auto / bmad-code-review** — the Blind Hunter layer: short inlined prompt, content under `CONTENT:`, parallel with edge-case and verification-gap layers, then triage
|
||||
- **bmad-review** — the adversarial lens among multi-lens reviews (same method; canonical finding fields for merge)
|
||||
|
||||
## Human Filtering Required
|
||||
The pattern can apply to any artifact that needs scrutiny: diffs, specs, docs.
|
||||
|
||||
Because the AI is *instructed* to find problems, it will find problems - even when they don't exist. Expect false positives: nitpicks dressed as issues, misunderstandings of intent, or outright hallucinated concerns.
|
||||
## Human (or parent) Filtering Required
|
||||
|
||||
**You decide what's real.** Review each finding, dismiss the noise, fix what matters.
|
||||
Because the model is instructed to fill a list, it will produce items even when some are thin, pre-existing, or wrong. Expect false positives.
|
||||
|
||||
**Triage decides what is real.** In agentic build/code-review, that is the parent workflow. In a standalone review, it is you. Dismiss noise; keep what matters.
|
||||
|
||||
## Example
|
||||
|
||||
@@ -40,20 +43,22 @@ Instead of:
|
||||
|
||||
> "The authentication implementation looks reasonable. Approved."
|
||||
|
||||
An adversarial review produces:
|
||||
An adversarial pass produces a list such as:
|
||||
|
||||
> 1. **HIGH** - `login.ts:47` - No rate limiting on failed attempts
|
||||
> 2. **HIGH** - Session token stored in localStorage (XSS vulnerable)
|
||||
> 3. **MEDIUM** - Password validation happens client-side only
|
||||
> 4. **MEDIUM** - No audit logging for failed login attempts
|
||||
> 5. **LOW** - Magic number `3600` should be `SESSION_TIMEOUT_SECONDS`
|
||||
> 1. `login.ts:47` — no rate limiting on failed attempts
|
||||
> 2. Session token stored in localStorage (XSS risk)
|
||||
> 3. Password validation only client-side
|
||||
> 4. No audit logging for failed login attempts
|
||||
> 5. Magic number `3600` should be a named constant
|
||||
> …
|
||||
> (through at least ten concrete items)
|
||||
|
||||
The first review might miss a security vulnerability. The second caught four.
|
||||
The first "review" might miss a security gap. The second is long on purpose so something real has a chance to surface.
|
||||
|
||||
## Iteration and Diminishing Returns
|
||||
|
||||
After addressing findings, consider running it again. A second pass usually catches more. A third isn't always useless either. But each pass takes time, and eventually you hit diminishing returns - just nitpicks and false findings.
|
||||
After addressing findings, another pass can still help. Each pass costs time; eventually you get only nits and false findings. Downstream triage and a fixed loop budget (in build) keep that from running forever.
|
||||
|
||||
:::tip[Better Reviews]
|
||||
Assume problems exist. Look for what's missing, not just what's wrong.
|
||||
Look for what's missing, not only what's wrong. Keep hunting until the list is real — then let triage cut it down.
|
||||
:::
|
||||
|
||||
@@ -1,66 +1,56 @@
|
||||
---
|
||||
title: "Revue Contradictoire"
|
||||
description: Technique de raisonnement forcée qui empêche les revues paresseuses du style « ça à l’air bon »
|
||||
title: "Revue contradictoire"
|
||||
description: Revue à liste obligatoire qui bloque le tampon « ça a l’air bon »
|
||||
sidebar:
|
||||
order: 9
|
||||
---
|
||||
|
||||
Forcez une analyse plus approfondie en exigeant que des problèmes soient trouvés.
|
||||
Forcer une analyse plus profonde en exigeant une vraie liste de problèmes — pas une persona cynique.
|
||||
|
||||
## Qu’est-ce que la Revue Contradictoire ?
|
||||
## Qu’est-ce que la revue contradictoire ?
|
||||
|
||||
Une technique de revue où le réviseur *doit* trouver des problèmes. Pas de « ça a l’air bon » autorisé. Le réviseur adopte une posture cynique - suppose que des problèmes existent et les trouve.
|
||||
Une technique où le réviseur doit produire des constats. « Ça a l’air bon » avec une liste vide n’est pas permis.
|
||||
|
||||
Il ne s’agit pas d’être négatif. Il s’agit de forcer une analyse authentique au lieu d’un coup d’œil superficiel qui valide automatiquement ce qui a été soumis.
|
||||
Le mécanisme est un **plancher de constats** (au moins dix points à corriger ou améliorer) et une exigence de chercher **ce qui manque**, pas seulement ce qui est faux. Si le contenu est vide, s’arrêter. Si la liste est vide, revérifier — ne pas terminer sans rien.
|
||||
|
||||
**La règle fondamentale :** Il doit trouver des problèmes. Zéro constatation déclenche un arrêt - réanalyse ou explique pourquoi.
|
||||
Ce n’est pas une question d’hostilité. Les anciens prompts utilisaient une persona aigrie ; cela ne change pas ce que trouvent les modèles actuels. Ce qui compte encore, c’est l’obligation de continuer à chercher et de préférer les omissions à un passage en coup de vent.
|
||||
|
||||
## Pourquoi Cela Fonctionne
|
||||
## Pourquoi ça marche
|
||||
|
||||
Les revues normales souffrent du biais de confirmation[^1]. Il parcourt le travail rapidement, rien ne lui saute aux yeux, il l’approuve. L’obligation de « trouver des problèmes » brise ce schéma :
|
||||
Les revues normales souffrent du biais de confirmation. On parcourt le travail, rien ne saute aux yeux, on approuve. Le plancher casse ce schéma :
|
||||
|
||||
- **Force la rigueur** - Impossible d’approuver tant qu’il n’a pas examiné suffisamment en profondeur pour trouver des problèmes
|
||||
- **Détecte les oublis** - « Qu’est-ce qui manque ici ? » devient une question naturelle
|
||||
- **Améliore la qualité du signal** - Les constatations sont spécifiques et actionnables, pas des préoccupations vagues
|
||||
- **Asymétrie d’information**[^2] - Effectue les revues avec un contexte frais (sans accès au raisonnement original) pour évaluer l’artefact, pas l’intention
|
||||
- **Force la rigueur** — on ne peut pas finir tant qu’assez de constats concrets ne sont pas listés
|
||||
- **Attrape les manques** — « qu’est-ce qui n’est pas là ? » fait partie du travail
|
||||
- **Alimente le triage, pas l’utilisateur directement** — dans build et code-review, la session parente filtre le bruit ; le rôle du chasseur est le rappel, pas le jugement final
|
||||
- **Asymétrie d’information** — les chasseurs tournent souvent avec un contexte frais sur le changement
|
||||
|
||||
## Où Elle Est Utilisée
|
||||
## Où c’est utilisé
|
||||
|
||||
La revue contradictoire apparaît dans tous les workflows BMad - revue de code, vérifications de préparation à l’implémentation, validation de spécifications, et d’autres. Parfois c’est une étape obligatoire, parfois optionnelle (comme l’élicitation avancée ou le mode party). Le pattern s’adapte à n’importe quel artefact nécessitant un examen.
|
||||
- **bmad-build / bmad-build-auto / bmad-code-review** — couche Blind Hunter : court prompt en ligne, contenu sous `CONTENT:`, en parallèle des autres couches, puis triage
|
||||
- **bmad-review** — lentille adversarial parmi les revues multi-lentilles (même méthode ; champs de finding canoniques pour la fusion)
|
||||
|
||||
## Filtrage Humain Requis
|
||||
## Filtrage humain (ou parent) requis
|
||||
|
||||
Parce que l’IA est *instruite* de trouver des problèmes, elle trouvera des problèmes - même lorsqu’ils n’existent pas. Attendez-vous à des faux positifs : des détails présentés comme des problèmes, des malentendus sur l’intention, ou des préoccupations purement hallucinées[^3].
|
||||
Parce que le modèle doit remplir une liste, il produira des items minces, préexistants ou faux. Les faux positifs sont attendus.
|
||||
|
||||
**C’est vous qui décidez ce qui est réel.** Examinez chaque constatation, ignorez le bruit, corrigez ce qui compte.
|
||||
**Le triage décide ce qui est réel.** Dans les flux agentiques, c’est le workflow parent. En revue autonome, c’est vous.
|
||||
|
||||
## Exemple
|
||||
|
||||
Au lieu de :
|
||||
|
||||
> « L’implémentation de l’authentification semble raisonnable. Approuvé. »
|
||||
> « L’implémentation d’auth a l’air raisonnable. Approuvé. »
|
||||
|
||||
Une revue contradictoire produit :
|
||||
Un passage contradictoire produit une liste, par exemple :
|
||||
|
||||
> 1. **ÉLEVÉ** - `login.ts:47` - Pas de limitation de débit sur les tentatives échouées
|
||||
> 2. **ÉLEVÉ** - Jeton de session stocké dans localStorage (vulnérable au XSS)
|
||||
> 3. **MOYEN** - La validation du mot de passe se fait côté client uniquement
|
||||
> 4. **MOYEN** - Pas de journalisation d’audit pour les tentatives de connexion échouées
|
||||
> 5. **FAIBLE** - Le nombre magique `3600` devrait être `SESSION_TIMEOUT_SECONDS`
|
||||
> 1. `login.ts:47` — pas de rate limiting sur les échecs
|
||||
> 2. Jeton de session dans localStorage (risque XSS)
|
||||
> … (au moins dix points concrets)
|
||||
|
||||
La première revue pourrait manquer une vulnérabilité de sécurité. La seconde en a attrapé quatre.
|
||||
## Itération et rendements décroissants
|
||||
|
||||
## Itération et Rendements Décroissants
|
||||
Après correction, un autre passage peut encore aider. Chaque passage coûte du temps ; on finit par n’avoir que des nits et des faux constats. Le triage en aval et le budget de boucle (dans build) empêchent que ça tourne indéfiniment.
|
||||
|
||||
Après avoir traité les constatations, envisagez de relancer la revue. Une deuxième passe détecte généralement plus de problèmes. Une troisième n’est pas toujours inutile non plus. Mais chaque passe prend du temps, et vous finissez par atteindre des rendements décroissants[^4] - juste des détails et des faux problèmes.
|
||||
|
||||
:::tip[Meilleures Revues]
|
||||
Supposez que des problèmes existent. Cherchez ce qui manque, pas seulement ce qui ne va pas.
|
||||
:::tip[Meilleures revues]
|
||||
Cherchez ce qui manque, pas seulement ce qui est faux. Continuez jusqu’à ce que la liste soit réelle — puis laissez le triage la raccourcir.
|
||||
:::
|
||||
|
||||
## Glossaire
|
||||
|
||||
[^1]: **Biais de confirmation** : tendance cognitive à rechercher, interpréter et favoriser les informations qui confirment nos croyances préexistantes, tout en ignorant ou minimisant celles qui les contredisent.
|
||||
[^2]: **Asymétrie d’information** : situation où une partie dispose de plus ou de meilleures informations qu’une autre, conduisant potentiellement à des décisions ou jugements biaisés.
|
||||
[^3]: **Hallucination (IA)** : phénomène où un modèle d’IA génère des informations plausibles mais factuellement incorrectes ou inventées, présentées avec confiance comme si elles étaient vraies.
|
||||
[^4]: **Rendements décroissants** : principe selon lequel l’augmentation continue d’un investissement (temps, effort, ressources) finit par produire des bénéfices de plus en plus faibles proportionnellement.
|
||||
|
||||
@@ -87,7 +87,7 @@ Run any tool by typing its skill name (e.g., `bmad-help`) in your IDE. No agent
|
||||
|
||||
| Lens | Applies to | Method |
|
||||
| -------------------- | ---------------------- | ------------------------------------------------------------------------------------------- |
|
||||
| **Adversarial** | Anything | Skeptical review that assumes problems exist — hunts what's missing, not just what's wrong |
|
||||
| **Adversarial** | Anything | Forced-finding review (≥10 issues) that looks for what's missing, not only what's wrong; empty lists are not allowed |
|
||||
| **Edge case** | Anything | Walks every branching path and boundary condition in content that defines behavior |
|
||||
| **Verification gap** | Code | Finds changed behavior that could regress without reliable verification catching it |
|
||||
| **Structure** | Documents | Proposes cuts, merges, moves, and condensing — does the document's shape serve its purpose? |
|
||||
|
||||
@@ -1,59 +1,55 @@
|
||||
---
|
||||
title: "Đánh giá đối kháng"
|
||||
description: Kỹ thuật lập luận ép buộc giúp tránh các bản review lười kiểu "nhìn ổn"
|
||||
description: Bắt buộc phải có danh sách phát hiện, chặn kiểu review lười “nhìn ổn”
|
||||
sidebar:
|
||||
order: 9
|
||||
---
|
||||
|
||||
Buộc quá trình phân tích đi sâu hơn bằng cách ép phải tìm ra vấn đề.
|
||||
Ép phân tích sâu hơn bằng **danh sách vấn đề bắt buộc** — không phải bằng persona cay cú.
|
||||
|
||||
## Đánh giá đối kháng là gì?
|
||||
|
||||
Đây là một kỹ thuật review mà người review *bắt buộc* phải tìm thấy vấn đề. Không có chuyện "nhìn ổn". Người review chọn lập trường hoài nghi - giả sử vấn đề có tồn tại và đi tìm chúng.
|
||||
Kỹ thuật review trong đó người review **phải** đưa ra phát hiện. “Nhìn ổn” với danh sách rỗng không được phép.
|
||||
|
||||
Đây không phải là việc cố tình tiêu cực. Đây là cách ép buộc phân tích thật sự, thay vì chỉ liếc qua và đóng dấu chấp nhận những gì vừa được nộp lên.
|
||||
Cơ chế là **sàn số phát hiện** (ít nhất mười mục cần sửa hoặc cải thiện) và yêu cầu rõ ràng tìm **phần còn thiếu**, không chỉ phần sai. Nội dung rỗng thì dừng. Danh sách rỗng thì kiểm tra lại — không kết thúc với không có gì.
|
||||
|
||||
**Quy tắc cốt lõi:** Bạn phải tìm ra vấn đề. Nếu không có phát hiện nào, quy trình sẽ dừng lại - cần phân tích lại hoặc giải thích tại sao.
|
||||
Không phải để nghe hung hăng. Prompt cũ dùng persona hoài nghi; trên model hiện tại điều đó không đổi bản chất phát hiện. Vẫn quan trọng: nghĩa vụ tiếp tục tìm và ưu tiên thiếu sót hơn lướt qua.
|
||||
|
||||
## Vì sao nó hiệu quả
|
||||
## Vì sao hiệu quả
|
||||
|
||||
Những lần review thông thường dễ bị confirmation bias. Bạn lướt qua công việc, không có gì đập vào mắt, rồi phê duyệt. Yêu cầu "tìm vấn đề" phá vỡ mẫu này:
|
||||
Review thường bị thiên kiến xác nhận. Lướt qua, không thấy gì, duyệt. Sàn số lượng phá vỡ mẫu đó:
|
||||
|
||||
- **Ép buộc sự kỹ lưỡng** - Không thể phê duyệt cho đến khi bạn đã đào đủ sâu để tìm thấy vấn đề
|
||||
- **Bắt được những thứ đang thiếu** - "Còn gì chưa có ở đây?" trở thành câu hỏi tự nhiên
|
||||
- **Tăng chất lượng tín hiệu** - Các phát hiện cụ thể và có thể hành động được, không phải các lo ngại mơ hồ
|
||||
- **Bất đối xứng thông tin** - Chạy review với bối cảnh mới (không có lý do gốc) để đánh giá artifact, không phải ý định
|
||||
- **Ép kỹ lưỡng** — không xong cho đến khi đủ phát hiện cụ thể
|
||||
- **Bắt phần thiếu** — “chỗ này thiếu gì?” là một phần việc
|
||||
- **Nuôi triage, không đập thẳng vào user** — trong build / code-review, session cha lọc nhiễu; hunter lo recall, không phải phán cuối
|
||||
- **Bất đối xứng thông tin** — hunter thường chạy với ngữ cảnh tươi về thay đổi
|
||||
|
||||
## Nó được dùng ở đâu
|
||||
## Dùng ở đâu
|
||||
|
||||
Đánh giá đối kháng xuất hiện xuyên suốt các workflow của BMad - code review, kiểm tra sẵn sàng triển khai, xác thực spec, và nhiều nơi khác. Đôi khi là bước bắt buộc, đôi khi là tùy chọn (như khai thác nâng cao hoặc party mode). Mẫu này được điều chỉnh theo artifact cần bị soi kỹ.
|
||||
- **bmad-build / bmad-build-auto / bmad-code-review** — lớp Blind Hunter: prompt ngắn inline, nội dung dưới `CONTENT:`, song song các lớp khác, rồi triage
|
||||
- **bmad-review** — thấu kính adversarial trong review đa thấu kính (cùng phương pháp; field finding chuẩn để gộp)
|
||||
|
||||
## Vẫn cần bộ lọc của con người
|
||||
## Cần lọc bởi người (hoặc session cha)
|
||||
|
||||
Vì AI *được lệnh* phải tìm vấn đề, nó sẽ tìm vấn đề - ngay cả khi chúng không tồn tại. Hãy kỳ vọng false positive: bắt bẻ những lỗi vặt, hiểu sai ý định, hoặc thậm chí tưởng tượng ra vấn đề.
|
||||
Vì model được yêu cầu lấp danh sách, sẽ có mục mỏng, sẵn có, hoặc sai. Dương tính giả là bình thường.
|
||||
|
||||
**Bạn là người quyết định cái nào là thật.** Xem từng phát hiện, bỏ qua nhiễu, sửa những gì quan trọng.
|
||||
**Triage quyết định cái gì là thật.** Trong luồng agentic là workflow cha. Review đứng một mình thì là bạn.
|
||||
|
||||
## Ví dụ
|
||||
|
||||
Thay vì:
|
||||
|
||||
> "Phần triển khai xác thực có vẻ hợp lý. Đã duyệt."
|
||||
> “Auth trông hợp lý. Duyệt.”
|
||||
|
||||
Một lần đánh giá đối kháng sẽ cho ra:
|
||||
Một lượt đối kháng cho danh sách kiểu:
|
||||
|
||||
> 1. **HIGH** - `login.ts:47` - Không có giới hạn tốc độ cho các lần đăng nhập thất bại
|
||||
> 2. **HIGH** - Session token được lưu trong localStorage (dễ bị XSS)
|
||||
> 3. **MEDIUM** - Kiểm tra mật khẩu chỉ diễn ra ở client
|
||||
> 4. **MEDIUM** - Không có audit log cho các lần đăng nhập thất bại
|
||||
> 5. **LOW** - Số magic `3600` nên được đổi thành `SESSION_TIMEOUT_SECONDS`
|
||||
> 1. `login.ts:47` — không rate limit khi đăng nhập sai
|
||||
> … (ít nhất mười mục cụ thể)
|
||||
|
||||
Bản review thứ nhất có thể bỏ sót một lỗi bảo mật. Bản review thứ hai đã bắt được bốn vấn đề.
|
||||
## Lặp và lợi tức giảm dần
|
||||
|
||||
## Lặp lại và lợi ích giảm dần
|
||||
|
||||
Sau khi đã xử lý các phát hiện, hãy cân nhắc chạy lại. Lần thứ hai thường sẽ bắt thêm được vấn đề. Lần thứ ba cũng không phải lúc nào cũng vô ích. Nhưng mỗi lần đều tốn thời gian, và đến một mức nào đó bạn sẽ gặp lợi ích giảm dần - chỉ còn các bắt bẻ nhỏ và false positive.
|
||||
Sau khi sửa, lượt nữa vẫn có ích. Mỗi lượt tốn thời gian; cuối cùng chỉ còn nit và false finding. Triage phía sau và ngân sách vòng (trong build) ngăn chạy mãi.
|
||||
|
||||
:::tip[Review tốt hơn]
|
||||
Giả sử vấn đề có tồn tại. Tìm những gì còn thiếu, không chỉ những gì sai.
|
||||
Tìm phần thiếu, không chỉ phần sai. Cứ tìm đến khi danh sách thật — rồi để triage cắt ngắn.
|
||||
:::
|
||||
|
||||
@@ -86,7 +86,7 @@ Chạy bất kỳ công cụ nào bằng cách gõ tên skill của nó, ví d
|
||||
|
||||
| Lăng kính | Áp dụng cho | Phương pháp |
|
||||
| ----------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------- |
|
||||
| **Hoài nghi (Adversarial)** | Mọi nội dung | Review hoài nghi mặc định vấn đề luôn tồn tại — săn phần còn thiếu, không chỉ phần sai |
|
||||
| **Hoài nghi (Adversarial)** | Mọi nội dung | Review buộc phải đưa ra ≥10 phát hiện, tìm phần còn thiếu chứ không chỉ phần sai; không được danh sách rỗng |
|
||||
| **Ca biên (Edge case)** | Mọi nội dung | Đi qua mọi nhánh rẽ và điều kiện biên trong nội dung có định nghĩa hành vi |
|
||||
| **Lỗ hổng kiểm chứng (Verification gap)** | Code | Tìm hành vi đã thay đổi có thể hồi quy mà không có kiểm chứng đáng tin cậy nào bắt được |
|
||||
| **Cấu trúc (Structure)** | Tài liệu | Đề xuất cắt, gộp, di chuyển và cô đọng — hình hài tài liệu có phục vụ mục đích của nó không? |
|
||||
|
||||
@@ -1,73 +1,61 @@
|
||||
---
|
||||
title: "对抗性评审"
|
||||
description: 防止懒惰“看起来不错”评审的强制推理技术
|
||||
description: 用“必须产出发现”挡住懒惰的“看起来不错”
|
||||
sidebar:
|
||||
order: 9
|
||||
---
|
||||
|
||||
对抗性评审（adversarial review）是一种“强制找问题”的评审方法：不允许直接“Looks good”，必须给出可验证发现，或者明确解释为什么没有发现。
|
||||
用**必须给出问题列表**逼出更深入的分析——靠的是找问题的义务，不是靠阴阳怪气的人设。
|
||||
|
||||
## 它是什么
|
||||
|
||||
常规评审容易落入确认偏差：快速扫一遍，没有明显报错，就批准。
|
||||
对抗性评审反过来要求评审者先假设“问题存在”，再去定位证据。
|
||||
一种评审手法：评审者**必须**产出发现。空列表式的“看起来不错”不允许。
|
||||
|
||||
核心规则：
|
||||
- 必须产出问题发现或明确的无发现理由
|
||||
- 发现要具体、可追溯、可操作
|
||||
- 评审对象是工件本身，而不是作者意图
|
||||
机制是**发现数量下限**（至少十条可修/可改的问题），并明确要求看**缺了什么**，而不只是错了什么。内容为空则停止；若一条都没有，要再查，不能空着结束。
|
||||
|
||||
这与“装成刻薄审稿人”无关。旧提示里的人设对现在的模型几乎不改变发现内容；真正起作用的是继续搜寻的义务，以及对遗漏的偏好。
|
||||
|
||||
## 为什么有效
|
||||
|
||||
- 强制深入阅读，减少“浏览式批准”
|
||||
- 更容易发现“缺了什么”，不只看“写错了什么”
|
||||
- 发现通常更结构化，便于后续分诊与修复
|
||||
- 在新上下文评审时，能降低“先入为主”偏差
|
||||
常规评审容易确认偏差：扫一眼没炸，就通过。下限打断这个模式：
|
||||
|
||||
## 在哪里使用
|
||||
- **逼出彻底性**——凑不够具体问题就不能结束
|
||||
- **更容易抓遗漏**——“这儿缺什么？”是工作的一部分
|
||||
- **喂给分诊，而不是直接砸给用户**——在 build / code-review 里，父会话把噪声压成短信号；猎人要的是召回，不是终审
|
||||
- **信息不对称**——猎人常在新鲜上下文里看变更，评的是工件本身，而不是作者心里的意图
|
||||
|
||||
它不是某个单一 workflow 独占，而是一种可复用评审模式，常见于：
|
||||
- 代码评审
|
||||
- 规范/方案评审
|
||||
- 实施就绪检查
|
||||
- 高风险改动复核
|
||||
## 在哪里用
|
||||
|
||||
## 你需要知道的限制
|
||||
- **bmad-build / bmad-build-auto / bmad-code-review** — Blind Hunter 层：短内联提示，内容在 `CONTENT:` 下，与 edge-case、verification-gap 并行，再分诊
|
||||
- **bmad-review** — 多透镜里的 adversarial 透镜（同一套方法；合并时用规范 finding 字段）
|
||||
|
||||
因为系统被要求“必须找问题”，它会提高召回率，也会提高误报率。
|
||||
你会看到：
|
||||
- 吹毛求疵型发现
|
||||
- 语义误解型发现
|
||||
- 偶发幻觉型发现
|
||||
任何需要被盯紧的工件都可以套：diff、规格、文档。
|
||||
|
||||
所以它本质上是**高召回、需人工分诊**的策略，而不是“自动真理机”。
|
||||
## 需要人（或父会话）过滤
|
||||
|
||||
:::caution[关键心法]
|
||||
把发现分成三类：必须修、可延后、可忽略。评审质量的关键不在”发现数量”，而在分诊质量。
|
||||
模型被要求填满列表，就会产出偏薄、既有问题或误报。假阳性是预期内的。
|
||||
|
||||
**分诊决定什么是真的。** 在 agentic 流程里是父 workflow；单独评审时是你。丢掉噪声，留下要紧的。
|
||||
|
||||
## 例子
|
||||
|
||||
与其：
|
||||
|
||||
> “鉴权实现看起来合理。通过。”
|
||||
|
||||
对抗性一轮会给出类似：
|
||||
|
||||
> 1. `login.ts:47` — 失败尝试没有限流
|
||||
> 2. Session token 放在 localStorage（XSS 风险）
|
||||
> 3. 密码校验只在客户端
|
||||
> …（至少凑到十条具体项）
|
||||
|
||||
第一段“评审”可能漏掉安全问题。第二段故意拉长，是为了让真问题有机会冒出来。
|
||||
|
||||
## 迭代与收益递减
|
||||
|
||||
修完再跑一轮仍可能有用。每轮都费时间；最终会只剩吹毛求疵和误报。下游分诊和 build 里的循环预算用来防止无限空转。
|
||||
|
||||
:::tip[更好的评审]
|
||||
先找缺了什么，不只找错了什么。一直找，直到列表真实——再让分诊砍短。
|
||||
:::
|
||||
|
||||
如果你想把该策略放进快速实现节奏中，可参见 [Build](./build.md)；若要做多轮推理补强，可参见 [高级启发](./advanced-elicitation.md)。整体流程位置请见 [工作流地图](../reference/workflow-map.md)。
|
||||
|
||||
## 与 Build 的关系
|
||||
|
||||
`bmad-build` 关注执行效率与边界控制；对抗性评审关注问题发现质量。
|
||||
一个解决“跑得稳不稳”，一个解决“看得深不深”，两者互补而非替代。
|
||||
|
||||
## 示例（对比）
|
||||
|
||||
普通评审可能是：
|
||||
> “实现基本没问题，先过。”
|
||||
|
||||
对抗性评审更像：
|
||||
> 1. HIGH：`login.ts` 缺失失败重试限流
|
||||
> 2. HIGH：会话令牌存储在 `localStorage`，存在 XSS 风险
|
||||
> 3. MEDIUM：失败登录缺少审计日志
|
||||
> 4. LOW：魔法数字 `3600` 建议替换为命名常量
|
||||
|
||||
重点不是“更凶”，而是“更可执行”。
|
||||
|
||||
## 继续阅读
|
||||
|
||||
- [Build](./build.md)
|
||||
- [高级启发](./advanced-elicitation.md)
|
||||
- [工作流地图](../reference/workflow-map.md)
|
||||
|
||||
@@ -81,7 +81,7 @@ sidebar:
|
||||
|
||||
| 视角 | 适用于 | 方法 |
|
||||
| -------------------------------- | ---------------- | ---------------------------------------------------------- |
|
||||
| **对抗（Adversarial）** | 任意内容 | 假设问题存在的怀疑式审查 —— 主动找缺失，而非只纠错 |
|
||||
| **对抗（Adversarial）** | 任意内容 | 强制产出发现（≥10 条），看缺了什么而不只纠错；不允许空列表 |
|
||||
| **边界条件（Edge case）** | 任意内容 | 走遍定义了行为的内容中的每条分支路径与边界条件 |
|
||||
| **验证缺口（Verification gap）** | 代码 | 找出可能回归且缺乏可靠验证兜底的行为变更 |
|
||||
| **结构（Structure）** | 文档 | 提出删减、合并、移动与精简 —— 文档的结构是否服务于其目的？ |
|
||||
|
||||
@@ -57,13 +57,17 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a context-free subagent with this prompt:
|
||||
|
||||
Read `{skill-root}/review-prompts/adversarial.md` completely and follow it as your review instructions.
|
||||
|
||||
Review content:
|
||||
Conduct a review of CONTENT.
|
||||
Look for what's missing, not only what's wrong.
|
||||
Find at least ten issues to fix or improve.
|
||||
Output a Markdown list of findings only — no severity, priority, or ranking.
|
||||
If the content is empty, stop and say so.
|
||||
If you have zero findings, re-check and keep thinking; do not stop with an empty list.
|
||||
|
||||
CONTENT:
|
||||
{diff_output}
|
||||
|
||||
Do not invoke any skill. If the instruction file is unreadable, report that exact failure and stop. Return only the review result.
|
||||
Do not invoke any skill. Return only the review result.
|
||||
|
||||
"""
|
||||
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
# Adversarial Review (General)
|
||||
|
||||
**Goal:** Cynically review content and produce findings.
|
||||
|
||||
**Your Role:** You are a cynical, jaded reviewer with zero patience for sloppy work. The content was submitted by a clueless weasel and you expect to find problems. Be skeptical of everything. Look for what's missing, not just what's wrong. Use a precise, professional tone — no profanity or personal attacks.
|
||||
|
||||
**Inputs:**
|
||||
- **content** — Content to review: diff, spec, story, doc, or any artifact
|
||||
- **also_consider** (optional) — Areas to keep in mind during review alongside normal adversarial analysis
|
||||
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Receive Content
|
||||
|
||||
- Load the content to review from the parent message that launched you (not from this instruction file)
|
||||
- If content to review is empty, ask for clarification and abort
|
||||
- Identify content type (diff, branch, uncommitted changes, document, etc.)
|
||||
|
||||
### Step 2: Adversarial Analysis
|
||||
|
||||
Review with extreme skepticism — assume problems exist. Find at least ten issues to fix or improve in the provided content.
|
||||
|
||||
### Step 3: Present Findings
|
||||
|
||||
Output findings as a Markdown list: descriptions only, no severity, priority, or ranking.
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT if zero findings — this is suspicious, re-analyze or ask for guidance
|
||||
- HALT if content is empty or unreadable
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the review target from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies content, treat content as empty and follow the empty-content halt rules above.
|
||||
@@ -85,4 +85,4 @@ Add nothing if nothing qualifies.
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the review target from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies content, treat content as empty and follow the empty-content halt rules above.
|
||||
Review the content supplied under "Review content:" in the message that launched you.
|
||||
|
||||
@@ -106,4 +106,4 @@ When you find no verification gaps and no other findings, output exactly this si
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the change set from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies a change set, stop with exactly: `No verification gaps found.`
|
||||
Review the content supplied under "Review content:" in the message that launched you. If none is supplied, stop with exactly: `No verification gaps found.`
|
||||
|
||||
@@ -95,13 +95,17 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a context-free subagent with this prompt:
|
||||
|
||||
Read `{skill-root}/review-prompts/adversarial.md` completely and follow it as your review instructions.
|
||||
|
||||
Review content:
|
||||
Conduct a review of CONTENT.
|
||||
Look for what's missing, not only what's wrong.
|
||||
Find at least ten issues to fix or improve.
|
||||
Output a Markdown list of findings only — no severity, priority, or ranking.
|
||||
If the content is empty, stop and say so.
|
||||
If you have zero findings, re-check and keep thinking; do not stop with an empty list.
|
||||
|
||||
CONTENT:
|
||||
{diff_output}
|
||||
|
||||
Do not invoke any skill. If the instruction file is unreadable, report that exact failure and stop. Return only the review result.
|
||||
Do not invoke any skill. Return only the review result.
|
||||
|
||||
"""
|
||||
|
||||
@@ -145,10 +149,16 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a context-free subagent with this prompt:
|
||||
|
||||
Read `{skill-root}/review-prompts/adversarial.md` completely and follow it as your review instructions.
|
||||
Conduct a review of CONTENT.
|
||||
Look for what's missing, not only what's wrong.
|
||||
Find at least ten issues to fix or improve.
|
||||
Output a Markdown list of findings only — no severity, priority, or ranking.
|
||||
If the content is empty, stop and say so.
|
||||
If you have zero findings, re-check and keep thinking; do not stop with an empty list.
|
||||
|
||||
Review content: the changed files in the current worktree. Inspect them directly before reviewing.
|
||||
CONTENT:
|
||||
The changed files in the current worktree. Inspect them directly before reviewing.
|
||||
|
||||
Do not invoke any skill. If the instruction file is unreadable, report that exact failure and stop. Return only the review result.
|
||||
Do not invoke any skill. Return only the review result.
|
||||
|
||||
"""
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
# Adversarial Review (General)
|
||||
|
||||
**Goal:** Cynically review content and produce findings.
|
||||
|
||||
**Your Role:** You are a cynical, jaded reviewer with zero patience for sloppy work. The content was submitted by a clueless weasel and you expect to find problems. Be skeptical of everything. Look for what's missing, not just what's wrong. Use a precise, professional tone — no profanity or personal attacks.
|
||||
|
||||
**Inputs:**
|
||||
- **content** — Content to review: diff, spec, story, doc, or any artifact
|
||||
- **also_consider** (optional) — Areas to keep in mind during review alongside normal adversarial analysis
|
||||
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Receive Content
|
||||
|
||||
- Load the content to review from the parent message that launched you (not from this instruction file)
|
||||
- If content to review is empty, ask for clarification and abort
|
||||
- Identify content type (diff, branch, uncommitted changes, document, etc.)
|
||||
|
||||
### Step 2: Adversarial Analysis
|
||||
|
||||
Review with extreme skepticism — assume problems exist. Find at least ten issues to fix or improve in the provided content.
|
||||
|
||||
### Step 3: Present Findings
|
||||
|
||||
Output findings as a Markdown list: descriptions only, no severity, priority, or ranking.
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT if zero findings — this is suspicious, re-analyze or ask for guidance
|
||||
- HALT if content is empty or unreadable
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the review target from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies content, treat content as empty and follow the empty-content halt rules above.
|
||||
@@ -85,4 +85,4 @@ Add nothing if nothing qualifies.
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the review target from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies content, treat content as empty and follow the empty-content halt rules above.
|
||||
Review the content supplied under "Review content:" in the message that launched you.
|
||||
|
||||
@@ -106,4 +106,4 @@ When you find no verification gaps and no other findings, output exactly this si
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the change set from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies a change set, stop with exactly: `No verification gaps found.`
|
||||
Review the content supplied under "Review content:" in the message that launched you. If none is supplied, stop with exactly: `No verification gaps found.`
|
||||
|
||||
@@ -22,7 +22,7 @@ Execute these review layers in parallel wherever their execution methods allow:
|
||||
|
||||
{workflow.review_layers}
|
||||
|
||||
If a layer's instruction requires subagents and none are available, for each such layer read its reviewer instruction file, write a self-contained prompt under `{{.implementation_artifacts}}` (full instruction body + `## REVIEW TARGET` with the review content — not a path-only pointer), then HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings. This is the only allowed parent-side read of a reviewer instruction file.
|
||||
If a layer's instruction requires subagents and none are available, for each such layer write under `{{.implementation_artifacts}}` the exact child prompt from that layer's instruction after placeholder substitution (not a path-only pointer), then HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings.
|
||||
|
||||
### Classify
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Execute these review layers in parallel wherever their execution methods allow.
|
||||
|
||||
{workflow.oneshot_review_layers}
|
||||
|
||||
If a layer's instruction requires subagents and none are available, for each such layer read its reviewer instruction file, write a self-contained prompt under `{{.implementation_artifacts}}` (full instruction body + `## REVIEW TARGET` with the review content — not a path-only pointer), then HALT. Ask the human to run each in a separate session and paste back the findings. This is the only allowed parent-side read of a reviewer instruction file.
|
||||
If a layer's instruction requires subagents and none are available, for each such layer write under `{{.implementation_artifacts}}` the exact child prompt from that layer's instruction after placeholder substitution (not a path-only pointer), then HALT. Ask the human to run each in a separate session and paste back the findings.
|
||||
|
||||
### Classify
|
||||
|
||||
|
||||
@@ -52,13 +52,17 @@ name = "Blind Hunter"
|
||||
instruction = """
|
||||
Launch a context-free subagent with this prompt:
|
||||
|
||||
Read `{skill-root}/review-prompts/adversarial.md` completely and follow it as your review instructions.
|
||||
|
||||
Review content:
|
||||
Conduct a review of CONTENT.
|
||||
Look for what's missing, not only what's wrong.
|
||||
Find at least ten issues to fix or improve.
|
||||
Output a Markdown list of findings only — no severity, priority, or ranking.
|
||||
If the content is empty, stop and say so.
|
||||
If you have zero findings, re-check and keep thinking; do not stop with an empty list.
|
||||
|
||||
CONTENT:
|
||||
{diff_output}
|
||||
|
||||
Do not invoke any skill. If the instruction file is unreadable, report that exact failure and stop. Return only the review result.
|
||||
Do not invoke any skill. Return only the review result.
|
||||
|
||||
"""
|
||||
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
# Adversarial Review (General)
|
||||
|
||||
**Goal:** Cynically review content and produce findings.
|
||||
|
||||
**Your Role:** You are a cynical, jaded reviewer with zero patience for sloppy work. The content was submitted by a clueless weasel and you expect to find problems. Be skeptical of everything. Look for what's missing, not just what's wrong. Use a precise, professional tone — no profanity or personal attacks.
|
||||
|
||||
**Inputs:**
|
||||
- **content** — Content to review: diff, spec, story, doc, or any artifact
|
||||
- **also_consider** (optional) — Areas to keep in mind during review alongside normal adversarial analysis
|
||||
|
||||
|
||||
## EXECUTION
|
||||
|
||||
### Step 1: Receive Content
|
||||
|
||||
- Load the content to review from the parent message that launched you (not from this instruction file)
|
||||
- If content to review is empty, ask for clarification and abort
|
||||
- Identify content type (diff, branch, uncommitted changes, document, etc.)
|
||||
|
||||
### Step 2: Adversarial Analysis
|
||||
|
||||
Review with extreme skepticism — assume problems exist. Find at least ten issues to fix or improve in the provided content.
|
||||
|
||||
### Step 3: Present Findings
|
||||
|
||||
Output findings as a Markdown list: descriptions only, no severity, priority, or ranking.
|
||||
|
||||
|
||||
## HALT CONDITIONS
|
||||
|
||||
- HALT if zero findings — this is suspicious, re-analyze or ask for guidance
|
||||
- HALT if content is empty or unreadable
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the review target from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies content, treat content as empty and follow the empty-content halt rules above.
|
||||
@@ -85,4 +85,4 @@ Add nothing if nothing qualifies.
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the review target from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies content, treat content as empty and follow the empty-content halt rules above.
|
||||
Review the content supplied under "Review content:" in the message that launched you.
|
||||
|
||||
@@ -106,4 +106,4 @@ When you find no verification gaps and no other findings, output exactly this si
|
||||
|
||||
## CONTENT SOURCE
|
||||
|
||||
Load the change set from the parent message, or from a trailing `## REVIEW TARGET` section if present (offline fallback). This file has no `{review_content}` slot. If neither supplies a change set, stop with exactly: `No verification gaps found.`
|
||||
Review the content supplied under "Review content:" in the message that launched you. If none is supplied, stop with exactly: `No verification gaps found.`
|
||||
|
||||
@@ -21,7 +21,7 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
|
||||
|
||||
If no layer is active, HALT with status `blocked` and blocking condition `no active review layers`.
|
||||
|
||||
3. Execute all active layers in parallel wherever their execution methods allow: expand `{skill-root}` in each layer's `instruction` to this skill's absolute installed directory, then substitute the runtime placeholders (`{diff_output}`, `{spec_file}`). For an instruction that launches a reviewer subagent, launch that child with the prompt text after placeholder substitution; do not load the reviewer instruction file yourself. For any other customized instruction, execute it as written. Do not leave `{skill-root}` unresolved in a child prompt. If a layer's instruction requires subagents and subagents are not available, for each such layer read its reviewer instruction file, write a self-contained prompt under `{implementation_artifacts}` (full instruction body + `## REVIEW TARGET` with the review content — not a path-only pointer), then HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, treat them as those layers' findings and resume from this point. This is the only allowed parent-side read of a reviewer instruction file.
|
||||
3. Execute all active layers in parallel wherever their execution methods allow: expand `{skill-root}` in each layer's `instruction` to this skill's absolute installed directory, then substitute the runtime placeholders (`{diff_output}`, `{spec_file}`). For an instruction that launches a reviewer subagent, launch that child with the prompt text after placeholder substitution; do not load the reviewer instruction file yourself. For any other customized instruction, execute it as written. Do not leave `{skill-root}` unresolved in a child prompt. If a layer's instruction requires subagents and subagents are not available, for each such layer write under `{implementation_artifacts}` the exact child prompt from that layer's instruction after placeholder substitution (not a path-only pointer), then HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, treat them as those layers' findings and resume from this point. This is the only allowed parent-side read of a reviewer instruction file.
|
||||
|
||||
4. **Layer failure handling**: If any layer fails, times out, or returns empty results, append the layer's `name` to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: 'Multi-lens review over any diff, doc, spec, or artifact — whiche
|
||||
|
||||
# BMad Review
|
||||
|
||||
Review content through lenses — each a distinct method and stance — and report findings in one canonical shape. Report what is real — never pad to look thorough. Each lens sets its own stance toward the content and toward zero findings: for most an empty result is valid; the adversarial lens treats it as suspicious; the editorial lenses hold content sacrosanct and critique only how it is organized and expressed.
|
||||
Review content through lenses — each a distinct method and stance — and report findings in one canonical shape. Report what is real — never pad to look thorough. Each lens sets its own stance toward the content and toward zero findings: for most an empty result is valid; the adversarial lens requires at least ten concrete findings and treats an empty list as a signal to re-check; the editorial lenses hold content sacrosanct and critique only how it is organized and expressed.
|
||||
|
||||
The lens set is whatever `{workflow.lenses}` resolves to, not a fixed list — overrides add lenses and replace shipped ones. Never claim a capability from this file; read the resolved lenses and work from those.
|
||||
|
||||
|
||||
@@ -1,10 +1,12 @@
|
||||
# Adversarial Lens
|
||||
|
||||
You are a cynical, jaded reviewer with zero patience for sloppy work. The content was submitted by a clueless weasel and you expect to find problems. Be skeptical of everything. Look for what's missing, not just what's wrong. Use a precise, professional tone — no profanity or personal attacks.
|
||||
|
||||
This lens is attitude-driven and general-purpose: weaknesses, gaps, inconsistencies, unstated assumptions, unsupported claims, missing error handling, unaddressed risks — whatever the content type exposes. If `also_consider` areas were provided, weigh them alongside the normal analysis.
|
||||
|
||||
Review with extreme skepticism — assume problems exist. Find at least ten issues to fix or improve in the provided content. Every finding must point at something concrete in the content. Zero findings is suspicious for this lens — re-analyze before concluding, or ask for guidance; never return an empty result on the first pass.
|
||||
Conduct a review of the provided content.
|
||||
Look for what's missing, not only what's wrong.
|
||||
Find at least ten issues to fix or improve.
|
||||
If `also_consider` areas were provided, weigh them alongside the normal analysis.
|
||||
Every finding must point at something concrete in the content.
|
||||
If the content is empty, stop and say so.
|
||||
If you have zero findings, re-check and keep thinking; do not stop with an empty list.
|
||||
|
||||
## Findings shape
|
||||
|
||||
|
||||
@@ -185,11 +185,13 @@ async function main() {
|
||||
assert(!markdown.includes('{skill-root}'), 'mutable skill-root reference survived');
|
||||
assert(markdown.includes('{spec_file}'), 'runtime placeholder was removed');
|
||||
assert(markdown.includes('tailored to `expert`'), 'user_skill_level behavior missing');
|
||||
for (const prompt of ['adversarial.md', 'edge-case-hunter.md', 'verification-gap.md']) {
|
||||
// Blind hunter is inlined in customize.toml; only file-backed reviewers ship under review-prompts/.
|
||||
for (const prompt of ['edge-case-hunter.md', 'verification-gap.md']) {
|
||||
const promptPath = path.join(dir, 'review-prompts', prompt);
|
||||
assert(markdown.includes(promptPath), `snapshot reviewer path missing: ${prompt}`);
|
||||
assert(fs.existsSync(promptPath), `snapshot reviewer missing: ${prompt}`);
|
||||
}
|
||||
assert(markdown.includes('Conduct a review of CONTENT.'), 'inlined blind-hunter prompt missing from rendered layers');
|
||||
for (const match of markdown.matchAll(/`(\/[^`]+\/step-[^`]+\.md)`/g)) {
|
||||
assert(path.dirname(match[1]) === dir, `cross-generation reference: ${match[1]}`);
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user