ds-jury
Skill80 starsChanged 15 days agoMITView on GitHub
Gets independent reviews of a change from two or three different models or providers and loops on fixes until they agree. Use when the user says jury, panel review, second opinions, ask other models, or /ds-jury.
In this repository28 other files it gives its agents.
- ds-adoptSkill
- ds-best-of-nSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-catchupSkill
- ds-context-resetSkill
- ds-design-auditSkill
- ds-designSkill
- ds-explainSkill
- ds-helpSkill
- ds-ledgerSkill
- ds-lessonsSkill
- ds-modeSkill
- ds-plan-loopSkill
- ds-pr-commentsSkill
- ds-principlesSkill
- ds-prSkill
- ds-readySkill
- ds-review-loopSkill
- ds-reviveSkill
- ds-sharpenSkill
- ds-shipSkill
- ds-swarmSkill
- ds-tddSkill
- ds-unslopSkill
- ds-unstickSkill
- ds-verify-loopSkill
- ds-watch-prSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Write one brief for all jurors: repo path, base SHA, diff command, goal in one sentence, out-of-scope items and check results.
- Very specific: line 14
Ask each juror for: a verdict (APPROVE or CHANGES), a score out of 10 and findings as id severity file:line claim fix.
- Distinctive: line 15
Run the jurors in parallel.
- Distinctive: line 16
Check each finding against the code yourself.
- Distinctive: line 22
Every juror returns APPROVE with no open blocker or should finding.
- Distinctive: line 30
Never invent a score or verdict.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Get two or three independent reviewers to judge the same change, then fix until they agree.
Steps
- Get the work ready first. Answer open PR comments, fix known issues and run the relevant checks. Skip this only if the user wants to throw the code away.
- Pick the jurors. Use models the user named. Otherwise pick the strongest available model from two or three different providers, at high reasoning effort.
- Find a way to reach them in this harness: team workers or subagents with a model setting, a second agent CLI in the terminal (for example a Codex or Claude CLI), or an API call. If only one model is available, start two or three fresh-context subagents of that model, each with a different persona: correctness, security and edge cases, simplicity and scope.
- Write one brief for all jurors: repo path, base SHA, diff command, goal in one sentence, out-of-scope items and check results. Tell them to review only and change nothing.
- Ask each juror for: a verdict (APPROVE or CHANGES), a score out of 10 and findings as
id severity file:line claim fix. Severity is blocker, should or nit. - Run the jurors in parallel. Wait for all of them. A timeout or error is not approval.
- Check each finding against the code yourself. Fix the ones you agree with, with the smallest change. Write a one-line reason for each one you reject.
- Re-run checks. Start a new round with the same brief, your answers and the new diff.
- Report the result. If there is a PR, edit its description and add a table: juror, model, score per round. Write
no scorewhen a juror gave none. If there is no PR, put the table in your final reply.
Stop when
- Every juror returns APPROVE with no open blocker or should finding.
- Three rounds are done. Report the open disagreements, with both sides in two lines each. The user decides.
- A round returns only nits. Stop without another round.
Rules
- Jurors are read-only. They do not edit, push, comment or start their own subagents.
- Say which jurors are the same model as each other. Do not claim a provider you did not reach.
- Never invent a score or verdict.
- Guard the scope. Decline new features and list them as follow-ups.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.