# Judge Simulator

> Stress-test a hackathon demo or submission with hypothetical rubric-based judges, evidence gaps and likely questions; use before rehearsal or submission, not as real user validation.

- Skill: `shreyp087/judge-simulator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add shreyp087/judge-simulator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shreyp087/judge-simulator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Shreyp087 (https://skillmd.com/u/shreyp087)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shreyp087/judge-simulator

---


# Judge Simulator

Find what a time-constrained reviewer cannot understand or verify from the actual submission.
This is hypothetical critique. It does not predict a real panel's vote or validate demand.

## Workflow

1. Obtain the event rubric, hard requirements and the materials judges will actually receive. If the rubric is unavailable, label a provisional review frame and keep event compliance unknown.
2. Inspect only those materials for the first pass. Do not silently use private implementation context to fill gaps the audience cannot see.
3. Choose a few independent review lenses that fit the rubric, such as technical execution, user experience or impact. Do not impersonate named judges or invent their private preferences.
4. For each lens, restate the project's purpose and mechanism, identify the strongest evidence, list unsupported claims and ask the most consequential unanswered question.
5. If useful and available, delegate independent critiques with the same rubric and artifacts. Keep their instructions neutral rather than revealing a desired conclusion.
6. Compare disagreements. Resolve factual disputes by inspecting the artifact or running an authorized check; retain subjective disagreement instead of averaging it away.
7. Rank a short repair list by rubric relevance, severity and time to fix. Re-review changed evidence only when fixes justify it.

## Outputs

Write `artifacts/judge-review.md` or use the project's existing review artifact:

- Scope: materials inspected, event rubric source, access limitations and review date.
- Hard-gate findings, separate from qualitative or numeric scores.
- One accurate sentence stating what a new reviewer thinks the project does.
- Criterion → evidence → gap → smallest useful fix.
- Likely questions with truthful draft answers and evidence pointers.
- Remaining disputes, untested behavior and the top repairs before submission.

Optional numeric scores must be labeled subjective simulated scores. Use official weights only when given. Do not translate them into a chance of winning.

## Failure constraints

- A simulated positive review is not user research, a benchmark or organizer approval.
- A missing artifact is a missing artifact, not a presumed failure of the unseen implementation.
- A polished claim without evidence remains unsupported; rhetorical confidence should not raise its score.
- Do not hallucinate having run a demo, watched a video or tested a link. State the accessible evidence.
- Do not add features simply to satisfy an imagined reviewer when the actual rubric and user scope do not support them.
- Do not make public comments, contact judges or submit the project unless authorized.

Done when the team knows the largest comprehension and proof gaps, with concrete fixes that fit the remaining time.