Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions core/golden-prompts/review-mine-max.txt
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
Go through each currently-open PR (draft or ready-for-review) of mine (authored by @testuser) in software-mansion/argent. Use the `gh` CLI to enumerate them.

Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across every review lens; every finding gets a concrete hard reproduction that proves it real. Then do a SECOND, independent verification pass over the PR to catch anything the first missed. Keep dispatching swarms until TWO consecutive passes come back completely clean.
Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across the review moves in my CLAUDE.md — claims vs code, nearest twin, non-happy paths, inputs, reachability both ways, and what outlives the call — plus the absence pass (a sibling that has it, prose that promises it, symmetry, and mutation); every finding gets a concrete hard reproduction that proves it real. Then do a SECOND, independent verification pass over the PR to catch anything the first missed. Keep dispatching swarms until TWO consecutive passes come back completely clean.

Fix every confirmed finding directly on the PR's branch, with the SAME reproduction re-run after each fix to prove it lands.

Hold to the bar in my CLAUDE.md throughout: prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work, and never report something fixed without re-running the repro to confirm it landed.
Hold to the bar in my CLAUDE.md throughout: run the review moves and the absence pass, prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work within the sizing limits there, and never report something fixed without re-running the repro to confirm it landed.

If a PR turns out perfectly clean — no issues, regressions or bad practices left — mark it ready for review and report its number to me. List every PR you cleared at the end.

Expand Down
8 changes: 4 additions & 4 deletions core/golden-prompts/review-single-unknown.txt
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@ Review PR #337 in software-mansion/argent. Use the `gh` CLI to fetch it.

Before doing anything else, fetch this PR and find out WHO AUTHORED IT: `gh pr view 337 --repo software-mansion/argent --json author,isDraft,headRefName`. Everything below depends on the answer — handle the PR as exactly ONE of the two cases that follow, never both.

Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across every review lens; every finding gets a concrete hard reproduction that proves it real. Then do a SECOND, independent verification pass over the PR to catch anything the first missed. Keep dispatching swarms until TWO consecutive passes come back completely clean.
Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across the review moves in my CLAUDE.md — claims vs code, nearest twin, non-happy paths, inputs, reachability both ways, and what outlives the call — plus the absence pass (a sibling that has it, prose that promises it, symmetry, and mutation); every finding gets a concrete hard reproduction that proves it real. Then do a SECOND, independent verification pass over the PR to catch anything the first missed. Keep dispatching swarms until TWO consecutive passes come back completely clean.

Hold to the bar in my CLAUDE.md throughout: prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work, and never report something fixed without re-running the repro to confirm it landed.
Hold to the bar in my CLAUDE.md throughout: run the review moves and the absence pass, prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work within the sizing limits there, and never report something fixed without re-running the repro to confirm it landed.

▸ CASE A — @testuser authored this PR (it's MINE). Treat it like my own work: fix what you find directly on its branch. Do everything in this case:

Expand All @@ -20,12 +20,12 @@ No AI attribution anywhere in git/GitHub — commits authored as me, no Co-Autho

These PRs are SOMEONE ELSE'S — not your code to change. UNDER NO CIRCUMSTANCES may you commit, push, or otherwise modify their branch: ABSOLUTELY DO NOT touch their branch in any way. Your one and only deliverable is the code review itself — every finding goes into the review, never into a commit or push on their branch.

Leave a formal GitHub review on each PR (POST a pull-request review, not a top-level comment), following the review-comment rules in my CLAUDE.md: one inline per-line comment per finding anchored to the exact line(s), describe the problem and its concrete impact only (never propose the fix), strip every internal severity/category marking from the text, and never leave an LGTM / "no issues" comment. NEVER POST A DUPLICATE FINDING: before writing a single comment, read EVERY comment and review thread already on the PR — mine, other reviewers', earlier review runs', resolved or not. If an existing comment already mentions a bug you found, do NOT leave a second comment about it under any circumstances — reply on that existing thread instead ("Still present as of <commit_hash>", with the PR's actual current head commit hash). One issue = one thread, ever.
Leave a formal GitHub review on each PR (POST a pull-request review, not a top-level comment), following the review-comment rules in my CLAUDE.md: one inline per-line comment per finding anchored to the exact line(s), describe the problem and its concrete impact only (never propose the fix), strip every internal severity/category marking from the text, and never leave an LGTM / "no issues" comment. NEVER POST A DUPLICATE FINDING: before writing a single comment, read EVERY comment and review thread already on the PR — mine, other reviewers', earlier review runs', resolved or not. If an existing comment already mentions a bug you found, do NOT leave a second comment about it under any circumstances — reply on that existing thread instead ("Still present as of <commit_hash>", with the PR's actual current head commit hash). One issue = one thread, ever. A limitation the PR description acknowledges is NOT a resolved finding: if the code still produces a wrong result, report it.

Do NOT mark this PR ready for review and do NOT change its draft/ready state in any way — it isn't yours to advance; only its author decides that.

Keep dispatching swarms until every PR you go through comes back clean.

Do NOT submit an APPROVE or a REQUEST-CHANGES verdict — the final approve / changes-requested call is mine; post every finding as an inline review comment (submit the review with the neutral COMMENT event, never APPROVE or REQUEST-CHANGES). The ONE deliberate exception to the no-LGTM rule: when a PR comes back PERFECTLY clean — no issues, regressions or bad practices left after the full sweep — leave a single friendly top-level comment (not an inline finding) noting you ran the full E2E sweep and it returned completely clean, and thanking them for contributing — for example: "Ran full E2E sweep across the review lenses. Returned perfectly clean. Thank you for contributing!". This is a SOFT approval: that comment ONLY — it must NEVER carry an APPROVE action or any other review verdict.
Do NOT submit an APPROVE or a REQUEST-CHANGES verdict — the final approve / changes-requested call is mine; post every finding as an inline review comment (submit the review with the neutral COMMENT event, never APPROVE or REQUEST-CHANGES). The ONE deliberate exception to the no-LGTM rule: when a PR comes back PERFECTLY clean — no issues, regressions or bad practices left after the full sweep — leave a single friendly top-level comment (not an inline finding) noting you ran the full E2E sweep and it returned completely clean, and thanking them for contributing. That comment must say what you actually ran and went through (the moves you covered, the reproductions you executed), never a bare impression like "looks correct" or "held up throughout". For example: "Ran the full sweep: claims vs code, nearest twin, non-happy paths, inputs, reachability, lifetime, plus mutation across the new branches and constants. Replayed the flow E2E on a booted sim. Returned clean. Thank you for contributing!". This is a SOFT approval: that comment ONLY — it must NEVER carry an APPROVE action or any other review verdict.

Diplomat attribution tag — a REQUIRED exception to the no-attribution rule, for GitHub commentary only: every comment, inline review comment, review body, and review-thread reply you post as part of this task must begin with the exact prefix `\[[Diplomat](https://github.com/latekvo/Diplomat)\]: ` (a literal `[`, then the word Diplomat as a Markdown link to https://github.com/latekvo/Diplomat, then a literal `]`, then a colon and a space), followed by the text you would otherwise have written — so it renders as "[Diplomat]: <your text>". This is the ONE sanctioned attribution; it applies to posted comment/review text ONLY and never changes commit messages, commit authorship, or the no-Co-Authored-By / no-"Generated with" git rules, which remain in force.
8 changes: 4 additions & 4 deletions core/golden-prompts/review-user-max.txt
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,14 @@ Go through each currently-open PR (draft or ready-for-review) authored by @someu

These PRs are SOMEONE ELSE'S — not your code to change. UNDER NO CIRCUMSTANCES may you commit, push, or otherwise modify their branch: ABSOLUTELY DO NOT touch their branch in any way. Your one and only deliverable is the code review itself — every finding goes into the review, never into a commit or push on their branch.

Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across every review lens; every finding gets a concrete hard reproduction that proves it real. Then do a SECOND, independent verification pass over the PR to catch anything the first missed. Keep dispatching swarms until TWO consecutive passes come back completely clean.
Maximum rigor. For each PR: run it END-TO-END through its real entry point and confirm observable behaviour — not just that it compiles. Dispatch swarms across the review moves in my CLAUDE.md — claims vs code, nearest twin, non-happy paths, inputs, reachability both ways, and what outlives the call — plus the absence pass (a sibling that has it, prose that promises it, symmetry, and mutation); every finding gets a concrete hard reproduction that proves it real. Then do a SECOND, independent verification pass over the PR to catch anything the first missed. Keep dispatching swarms until TWO consecutive passes come back completely clean.

Hold to the bar in my CLAUDE.md throughout: prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work, and never report something fixed without re-running the repro to confirm it landed.
Hold to the bar in my CLAUDE.md throughout: run the review moves and the absence pass, prove every issue beyond reasonable doubt with a concrete reproduction before you act on it, scale the swarm to the work within the sizing limits there, and never report something fixed without re-running the repro to confirm it landed.

Leave a formal GitHub review on each PR (POST a pull-request review, not a top-level comment), following the review-comment rules in my CLAUDE.md: one inline per-line comment per finding anchored to the exact line(s), describe the problem and its concrete impact only (never propose the fix), strip every internal severity/category marking from the text, and never leave an LGTM / "no issues" comment. NEVER POST A DUPLICATE FINDING: before writing a single comment, read EVERY comment and review thread already on the PR — mine, other reviewers', earlier review runs', resolved or not. If an existing comment already mentions a bug you found, do NOT leave a second comment about it under any circumstances — reply on that existing thread instead ("Still present as of <commit_hash>", with the PR's actual current head commit hash). One issue = one thread, ever.
Leave a formal GitHub review on each PR (POST a pull-request review, not a top-level comment), following the review-comment rules in my CLAUDE.md: one inline per-line comment per finding anchored to the exact line(s), describe the problem and its concrete impact only (never propose the fix), strip every internal severity/category marking from the text, and never leave an LGTM / "no issues" comment. NEVER POST A DUPLICATE FINDING: before writing a single comment, read EVERY comment and review thread already on the PR — mine, other reviewers', earlier review runs', resolved or not. If an existing comment already mentions a bug you found, do NOT leave a second comment about it under any circumstances — reply on that existing thread instead ("Still present as of <commit_hash>", with the PR's actual current head commit hash). One issue = one thread, ever. A limitation the PR description acknowledges is NOT a resolved finding: if the code still produces a wrong result, report it.

Keep dispatching swarms until every PR you go through comes back clean.

Do NOT submit an APPROVE or a REQUEST-CHANGES verdict — the final approve / changes-requested call is mine; post every finding as an inline review comment (submit the review with the neutral COMMENT event, never APPROVE or REQUEST-CHANGES). The ONE deliberate exception to the no-LGTM rule: when a PR comes back PERFECTLY clean — no issues, regressions or bad practices left after the full sweep — leave a single friendly top-level comment (not an inline finding) noting you ran the full E2E sweep and it returned completely clean, and thanking them for contributing — for example: "Ran full E2E sweep across the review lenses. Returned perfectly clean. Thank you for contributing!". This is a SOFT approval: that comment ONLY — it must NEVER carry an APPROVE action or any other review verdict.
Do NOT submit an APPROVE or a REQUEST-CHANGES verdict — the final approve / changes-requested call is mine; post every finding as an inline review comment (submit the review with the neutral COMMENT event, never APPROVE or REQUEST-CHANGES). The ONE deliberate exception to the no-LGTM rule: when a PR comes back PERFECTLY clean — no issues, regressions or bad practices left after the full sweep — leave a single friendly top-level comment (not an inline finding) noting you ran the full E2E sweep and it returned completely clean, and thanking them for contributing. That comment must say what you actually ran and went through (the moves you covered, the reproductions you executed), never a bare impression like "looks correct" or "held up throughout". For example: "Ran the full sweep: claims vs code, nearest twin, non-happy paths, inputs, reachability, lifetime, plus mutation across the new branches and constants. Replayed the flow E2E on a booted sim. Returned clean. Thank you for contributing!". This is a SOFT approval: that comment ONLY — it must NEVER carry an APPROVE action or any other review verdict.

Diplomat attribution tag — a REQUIRED exception to the no-attribution rule, for GitHub commentary only: every comment, inline review comment, review body, and review-thread reply you post as part of this task must begin with the exact prefix `\[[Diplomat](https://github.com/latekvo/Diplomat)\]: ` (a literal `[`, then the word Diplomat as a Markdown link to https://github.com/latekvo/Diplomat, then a literal `]`, then a colon and a space), followed by the text you would otherwise have written — so it renders as "[Diplomat]: <your text>". This is the ONE sanctioned attribution; it applies to posted comment/review text ONLY and never changes commit messages, commit authorship, or the no-Co-Authored-By / no-"Generated with" git rules, which remain in force.
Loading
Loading