agentleFS
Sign inStart free
AndyTechnologiesAndyTechnologies/my-own-skills/skills/judgment-day/SKILL.md

judgment-day

Skill0 starsChanged 39 days agoApache-2.0View on GitHub

Trigger: judgment day, dual review, adversarial review, juzgar. Run explicit blind dual review with at most two scoped fix/re-judgment rounds.

3 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Never launch review-refuter.

    line 19
  2. Very specific:

    Only the parent orchestrator merges/persists findings, launches the fix actor (jd-fix-agent), and launches scoped re-judgment.

    line 20
  3. Very specific:

    Ask before round-one correction.

    line 42
  4. Very specific:

    Run both judges again (jd-judge-a, jd-judge-b) only over the frozen ledger plus immutable fix delta.

    line 43

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Activation Contract

Load only when the user explicitly requests Judgment Day or equivalent dual/adversarial review for a concrete target. Judgment Day is a standalone developer tool: judges run whenever asked, on any runtime, and need no review transaction, runtime identity, or delivery-receipt machinery to start. It replaces ordinary 4R as the adversarial method for that target; never run both.

Hard Rules

  • Resolve matching project skills before starting and pass the same paths to both judges (jd-judge-a, jd-judge-b) and the fix actor (jd-fix-agent).
  • Build one complete immutable target, then launch two blind read-only judges in parallel with identical scope and criteria.
  • Each judge returns one neutral findings result and terminates. Wait for both; never accept a partial judgment.
  • Never launch review-refuter; two-judge agreement is the corroboration mechanism.
  • Only the parent orchestrator merges/persists findings, launches the fix actor (jd-fix-agent), and launches scoped re-judgment.
  • Fix only severe findings confirmed by both judges. WARNING/SUGGESTION rows remain info.
  • Permit at most two fix rounds and two scoped re-judgments. Re-judgment sees only the frozen ledger plus fix delta and may record fix-caused defects.
  • The only terminal verdicts are APPROVED | ESCALATED; never reset or extend an exhausted round budget.
  • A judgment issues no receipt and carries no delivery authority: it satisfies no commit, push, PR, or release gate. When the caller explicitly wants ordinary negotiated review for the same target, run it as its own step; neither outcome authorizes delivery, which remains under ordinary repository policy.

Decision Gates

ConditionAction
Target unclearAsk one scope question and stop.
Both judges confirm severe findingAsk before round-one correction; then use the bounded fix actor.
One judge reports itRecord suspect; do not auto-fix.
Judges contradictEscalate for explicit human decision.
Scoped re-judgment fails before round twoParent may launch the final bounded fix round.
Any issue remains after round twoEscalate and stop.

Execution Steps

  1. Build the complete immutable target and freeze the scope both judges will inspect.
  2. Launch both read-only judges in parallel (jd-judge-a, jd-judge-b) against the same immutable target.
  3. Merge findings into the frozen ledger and persist it through the selected artifact store.
  4. Ask before round-one correction; run the fix actor (jd-fix-agent) only for confirmed severe IDs.
  5. Run both judges again (jd-judge-a, jd-judge-b) only over the frozen ledger plus immutable fix delta.
  6. Repeat once at most, then run independent final verification and return the terminal verdict.

Output Contract

Return target identity, round, confirmed/suspect/contradiction/INFO counts, correction work units, scoped re-judgment result, artifact references, skill resolution, and exactly one final JUDGMENT: APPROVED ✅ or JUDGMENT: ESCALATED ⚠️.

References

  • references/prompts-and-formats.md — compact judge/fix prompts and verdict shape.
  • ../_shared/review-ledger-contract.md — optional ordinary negotiated-review context: consult it only when the caller explicitly requests that lifecycle; never required to run judges and never delivery authorization.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free