From bounded-adjudication
Make agent judgment reliable by building enforcement hooks with a closed rubric. Use when the user wants to stop their agent from repeating mistakes, set up code review that runs on every write, create review rules the agent can't ignore or invent, or formalize standards for code, content, or creative work into enforceable gates.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bounded-adjudication:bounded-adjudicationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill guides the user through building bounded adjudication infrastructure for their project — software, content, creative, or any domain where an agent makes judgment calls. The output is a gate rubric (the closed evidence vocabulary) and, for projects using agent hooks, a hooks configuration that enforces it on every write.
This skill guides the user through building bounded adjudication infrastructure for their project — software, content, creative, or any domain where an agent makes judgment calls. The output is a gate rubric (the closed evidence vocabulary) and, for projects using agent hooks, a hooks configuration that enforces it on every write.
You are a collaborative instrument. You make the user's understanding precise. You do not do the work autonomously. You ask targeted questions, form hypotheses for the user to confirm or correct, and accumulate understanding in a worksheet.
On every invocation:
.claude/bounded-adjudication-worksheet.md in the user's project.[CONFIRMED].[CONFIRMED].Ask questions. Listen. When the user describes a module, boundary, or pattern, you may examine it in the codebase to form a specific hypothesis. Present the hypothesis for confirmation. Do not scan the codebase unprompted. Do not treat code reading as a substitute for the conversation.
When working on a software project, consult structural discovery for what signals to listen for and what they mean. When working on creative, editorial, or intentional work, consult intentional discovery. Most projects use both strategies on different dimensions. A design system is structural. The brand voice it expresses is intentional.
Translate concepts into the user's context. "Evidence shape" means nothing until you show them one from their own project. "A repository class that imports from the HTTP layer" is an evidence shape. "Don't violate separation of concerns" is not.
Later work sometimes reveals that an earlier section was wrong. Working through evidence shapes may reveal a gate was actually two gates combined. An approved mechanism analysis may reveal that an invariant is only usually wrong, not always wrong.
When you observe this, name the conflict explicitly. Propose reopening the affected section. Mark it [REOPENED] and work it again with the user. Do not reopen without the user's agreement. Do not second-guess confirmed sections without a specific named conflict.
Create this file at .claude/bounded-adjudication-worksheet.md on first invocation:
# Bounded Adjudication Worksheet
## Project Context [NOT STARTED]
**Project name:**
**What it produces:** (software, content, design, documentation, or a mix)
**Primary medium and tools:** (language/framework, writing tools, design system, etc.)
**Key commitments:** (architectural, editorial, stylistic, regulatory — what rules has the team or author set)
**Where does truth live:** (a spec, a schema, a style guide, a story bible, a brand book, a regulatory standard — the authoritative source other work derives from)
---
## 1. Structural Invariants [NOT STARTED]
Shapes that are always wrong regardless of context. Not usually wrong. Always wrong.
| # | Invariant shape | Why it is always wrong |
|---|----------------|----------------------|
---
## 2. Axes of Judgment [NOT STARTED]
Each gate asks one question about one independent dimension of the work.
| # | Gate name | Question |
|---|----------|----------|
---
## 3. Evidence Shapes [NOT STARTED]
For each gate, the concrete observable shapes that constitute allowed and disallowed work.
### Gate: [name]
**Allowed shapes:**
-
**Disallowed shapes:**
-
---
## 4. Approved Mechanisms [NOT STARTED]
For each gate, the sanctioned ways to achieve goals that would otherwise appear suspicious.
### Gate: [name]
**Mechanisms:**
-
---
## 5. Genuine Ambiguities [NOT STARTED]
Where evidence matching fails to resolve classification.
| # | Ambiguity | Owner |
|---|-----------|-------|
---
## 6. Authority Topology [NOT STARTED]
What is the declared truth against which work is measured?
**Authority root:**
**Ownership map:**
---
## Quality Gate [NOT RUN]
- [ ] Every invariant is a concrete shape, not a principle
- [ ] Every gate asks exactly one question
- [ ] No gate overlaps with another gate
- [ ] All gates together cover the work's dimensions
- [ ] Every evidence shape is observable in an edit
- [ ] Every approved mechanism is specific enough to match against
- [ ] Every ambiguity names an owner
- [ ] Authority topology is consistent with the gates
---
## Generation [NOT RUN]
Understand what the project produces before asking about invariants. Ask the user:
Adapt your language to the domain. For software: "It looks like your domain models live here and your vendor integrations live here. Is that the ownership boundary?" For content: "It sounds like the style guide governs voice and the story bible governs continuity. Are those separate concerns?" For design: "The component library defines allowed compositions. Is that the authority, or does the brand book override it?"
These are fast-fail patterns. The pre-check fires them before reasoning is spent. Every invariant must be a shape that is always wrong. Test each candidate: can you name a legitimate case where this shape is correct? If yes, it is not an invariant. It may be a disallowed evidence shape for a gate instead.
In software, invariants are structural: bare primitives as field types, functions returning dicts, technology-named classes. In content, invariants are formal: second person in a third-person narrative, passive voice in a brand that requires active, a heading style that violates the style guide. In design, invariants are compositional: a component nesting pattern that breaks the design system, a color outside the palette. The test is the same regardless of domain: is this always wrong, or only usually wrong?
Each gate is one question about one dimension. Test independence: could gate A pass while gate B fails, and vice versa? If not, they are the same gate or one subsumes the other. Test exhaustiveness: is there a dimension of work quality that no gate covers? If yes, a gate is missing.
For each gate, enumerate what allowed and disallowed work looks like as concrete observable shapes. Not principles. Not aspirations. Shapes an adjudicator can match against an edit.
Test each shape: could a reviewer unambiguously determine whether an edit matches this shape? If the shape requires subjective interpretation, it is too abstract. Sharpen it or split it.
For each gate, what are all the ways a suspicious-looking edit can be correct? This closes the solution space. The adjudicator can only pass a suspicious edit by citing one of these.
Test completeness: for each disallowed shape, is there a legitimate way to achieve the same goal? If yes, that way must be an approved mechanism. Test soundness: is every approved mechanism actually correct? An approved mechanism that is itself broken institutionalizes a defect.
Where does evidence matching fail? Where are there legitimate classification disputes? Name each ambiguity and name who or what resolves it. The escalation authority can be a human role, a document, a design decision that hasn't been made yet, or a future conversation.
A system with no ambiguities is lying about its certainty. Push the user to find the edges.
What is the declared truth? Everything in the rubric is measured against something. Name it. If multiple authority sources exist, map which gate adjudicates against which authority.
Test consistency: does every gate's evidence reference the authority topology? If a gate's allowed/disallowed shapes don't relate to the declared truth, either the gate or the topology is wrong.
Before generating artifacts, review the complete worksheet against these criteria:
If any criterion fails, name the failure, propose reopening the affected section, and work it again with the user. Do not generate artifacts until all criteria pass. Mark the quality gate [PASSED] with notes on what was checked.
Generate a hooks configuration to merge into the user's .claude/settings.json. If the file already exists, merge the hooks into the existing structure. Do not overwrite other settings.
Structure:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "prompt",
"prompt": "Pre-edit invariant check. DENY if the proposed edit matches any fast-fail pattern below. Otherwise PASS.\n\nFast-fail patterns:\n[numbered list of confirmed invariants from worksheet]\n\nReturn PASS or DENY. On DENY, cite the pattern number and the exact shape that triggered it."
}
]
}
],
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "agent",
"prompt": "Post-edit gate adjudication. For each gate, consult the rubric at `.claude/rules/gate-rubrics.md`. For each gate:\n\n1. Answer the gate's Question against the edit.\n2. Classify the edit against Allowed and Disallowed evidence shapes.\n3. If the edit matches an Approved Mechanism, the gate PASSES unless a specific Disallowed shape also applies.\n4. FAIL only when you can cite a specific Disallowed shape.\n5. If classification is ambiguous, ESCALATE to the named authority.\n\nGates: [list of gate names from worksheet]\n\nFor each gate return PASS, FAIL, or ESCALATE. On FAIL cite the gate, the disallowed shape, and the approved mechanism alternative if one exists. Overall FAIL if any gate is FAIL."
}
]
}
]
}
}
Generate .claude/rules/gate-rubrics.md with this structure:
---
paths:
- "**/*"
---
# Gate Rubrics
## Reading Order
1. Classify mode: [project-specific classification guidance from authority topology]
2. For each gate, answer the stated Question against the edit.
3. Classify against Allowed and Disallowed evidence.
4. If the edit matches an Approved Mechanism, the gate passes unless a specific Disallowed shape also applies.
5. If classification is ambiguous, emit the gate's Escalation Trigger.
## [Gate Name] Gate
**Question**: [from worksheet]
**Allowed evidence**:
[from worksheet]
**Disallowed evidence**:
[from worksheet]
**Approved mechanisms**:
[from worksheet, inline if small catalog]
**Escalation trigger**: [from worksheet ambiguities]
If a gate's approved mechanism catalog is substantial (more than five mechanisms), generate a separate file at .claude/rules/[gate-name]-mechanisms.md and reference it from the rubric.
Mark the Generation section [COMPLETE] when artifacts are written. Tell the user what was generated and where.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub kylejtobin/bounded-adjudication --plugin bounded-adjudication