JudgmentKit

Activity-first judgment for AI agents

Judgment before generation.

JudgmentKit stops implementation mechanics from becoming UX. Use it before accepting AI-generated product work, so the next interface starts from the activity, decision, evidence, and handoff instead of from schemas, prompts, or tool traces.

Examples Evals
Prompt
A support operations manager is reviewing refund escalation cases. The request says to build from the refund_case data model, database fields, JSON schema, prompt template, tool call results, resource id, API endpoint status, and CRUD. The activity is deciding whether an escalation should be approved, sent to policy review, or returned for missing evidence. The outcome is a clear handoff with the next action and reason.
activity evidence implementation detail
Judgment

Identify the support lead, refund review activity, bounded decision, evidence boundary, and diagnostic terms that should stay out of the primary surface.

Handoff

Generate a workflow brief for reviewing evidence, choosing an outcome, and leaving a receipt for the next owner.

State ready for generation

How agents use it

Review the activity

Name the participant, objective, decision, outcome, vocabulary, and disclosure boundary before screen structure.

Check the workflow

Review a proposed UI workflow for grounding, action support, completion clarity, and leakage before implementation.

Hand off cleanly

Pass only a ready handoff to the next generation step, with diagnostics kept separate from the product surface.

System map

JudgmentKit sits before generation and stays in the loop across iterations. It is the judgment layer around LLM UI generation, not the final renderer.

Scroll the page normally. Drag to pan the map; use controls or pinch/ctrl-wheel to zoom.

JudgmentKit system design map A static fallback node and edge diagram showing source context, the MCP boundary, JudgmentKit kernel, optional LLM provider seam, UI rendering outside JudgmentKit, Material UI adapter, blocked path, and iteration with updated context returning to source and activity review. MCP boundary Agent / Client / MCP Codex or agent client Calls tools; owns the turn. Source brief + product context Brief, product facts, current draft findings. MCP server Access and transport only. MCP is not the LLM. tools/list + tools/call JudgmentKit kernel Deterministic review, guardrails, handoff analyze_implementation_brief Extract activity evidence, source gaps, implementation terms, disclosure risks. create_activity_model_review Name activity, participant, objective, decision, outcome, vocabulary. review_activity_model_candidate Review model or agent candidates before trusting them. review_ui_workflow_candidate Check grounding, action support, handoff clarity, leakage containment. recommend_ui_workflow_profiles Optional guidance such as operator-review-ui; not styling. create_ui_generation_handoff Gate: only ready workflow reviews become generation handoffs. Blocked path Resolve targeted questions or leakage before UI generation. LLM / provider seam Optional model assistance Provider adapter OpenAI, local model, or injected caller. Candidate proposal Activity/workflow JSON. Reviewed before use. Outside JudgmentKit UI rendering from reviewed handoff LLM / agent UI pass Generate from reviewed handoff, not raw brief. Renderer choice after reviewed handoff JudgmentKit does not enforce Material UI or any design system. Material UI adapter @mui/material components applied after judgment. without design system Still use the handoff; choose simple UI primitives. UI draft Reviewed by human or agent for next iteration. Iteration loop Draft findings become updated context Review findings updated context MCP tool call needs source context request candidate proposed JSON returns for review reviewed handoff with design system without design system review draft updated context returns to source/activity review

MCP boundary: agents call JudgmentKit tools through MCP; MCP is access and transport, not the LLM.

JudgmentKit kernel: deterministic review, candidate review, disclosure rules, targeted questions, and the handoff gate decide whether UI generation is ready.

LLM / provider seam: a model may propose activity or workflow candidates, but JudgmentKit reviews those candidates before trusting them.

Surface type: recommend_surface_types classifies activity purpose before workflow or frontend implementation guidance.

UI generation: the LLM or agent generates the interface outside JudgmentKit from the reviewed handoff.

Implementation contract: create_ui_implementation_contract supplies approved primitives, required states, static checks, and browser QA expectations before final handoff. review_ui_implementation_candidate checks generated UI against that contract.

Frontend adapter: create_frontend_generation_context combines a ready handoff, selected surface type, project frontend context, and verification expectations. create_frontend_implementation_skill_context turns that ready context into portable implementation instructions without exposing raw skill files. Design-system compliance is not a substitute for activity fit.

Iteration: draft review produces updated context that re-enters source/activity review rather than becoming only a longer prompt.

Blocked path: if activity, workflow, or handoff is not ready, resolve targeted questions or leakage details before generating UI.

Install for Codex, Claude Code, or Cursor

The installer configures a hosted Streamable HTTP MCP server named judgmentkit and verifies the current tool catalog before finishing.

curl -fsSL https://judgmentkit.ai/install | bash curl -fsSL https://judgmentkit.ai/install | bash -s -- --client claude curl -fsSL https://judgmentkit.ai/install | bash -s -- --client cursor

Codex is the default when no client is provided. Hosted installs do not clone the repo or require npm.