Skip to content

chore: strengthen review discipline #43

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
satyaborg merged 1 commit into from
Jun 5, 2026
Merged

chore: strengthen review discipline #43

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
21 changes: 21 additions & 0 deletions skills/devloop-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,21 @@ the spec gate and still fail review because it makes the codebase worse.
5. Read prior reviews so you do not repeat resolved findings.
6. Inspect tests and verification evidence instead of trusting summary text.

Treat review output, agent summaries, and test summaries as advisory. Verify
each candidate finding by reading the real code path and adjacent ownership
boundaries before accepting it as blocking. When a finding depends on framework,
dependency, shell, platform, or API behavior, verify that contract from docs,
types, source, or executable evidence.

Reject speculative risks, unrealistic edge cases, style-only nits, broad
rewrites, and fixes that would complicate the codebase without improving a spec
or engineering gate.

When a real finding exposes a bug class or repeated pattern, inspect the current
diff and touched ownership boundary for sibling instances. Report the scoped
bug class when practical, but stop at clear ownership boundaries and leave
unrelated follow-up territory out of the devloop pass.

## Spec Gate

Check every acceptance criterion independently:
Expand All @@ -39,6 +54,8 @@ Check every acceptance criterion independently:
- Did the change drift beyond the spec?
- Did the implementation make an undocumented tradeoff or default choice?
- Did behavior change without a targeted regression test?
- If this pass fixes a prior review finding, was verification rerun after the
fix instead of reused from before the code changed?

Reject when a criterion fails, evidence is vague, scope drift is meaningful, or
missing tests leave changed behavior underverified.
Expand All @@ -62,6 +79,10 @@ Run an adversarial engineering review after the spec pass:
- Operational safety: updates are atomic enough, independent work is not
serialized into brittle orchestration, and failure modes are recoverable.

Report security findings only when the change creates a concrete, actionable
risk or removes an important safety check. Do not block legitimate functionality
for generic security posture advice.

Be ambitious about structural simplification. Look for a code-judo move that
would make the implementation smaller or more inevitable without changing
behavior. Prefer deleting complexity over rearranging it.
Expand Down