do-and-judge

Name: do-and-judge
Author: NeoLabHQ

858installs132forks

How to install do-and-judge?

neolabhq/context-engineering-kit/do-and-judge

$npx -y skills add NeoLabHQ/context-engineering-kit --skill do-and-judge

Installs into the current project.

Summary

Execute a task with sub-agent implementation and LLM-as-a-judge verification with automatic retry loop

Files · 1

View on GitHub

SKILL.md

1	# do-and-judge
2
3	## Task
4	Execute a single task by dispatching an implementation sub-agent, verifying with an independent judge, and iterating with feedback until passing or max retries exceeded.
5
6	## Context
7	This command implements a single-task execution pattern with meta-judge → LLM-as-a-judge verification. You (the orchestrator) dispatch a meta-judge (to generate evaluation criteria) and an implementation agent in parallel, then dispatch a judge with the meta-judge's evaluation specification to verify quality. If verification fails, you launch new implementation agent with judge feedback and iterate until passing (score ≥4) or max retries (2) exceeded.
8
9	Key benefits:
10
11	- Fresh context - Implementation agent works with clean context window
12	- Structured evaluation - Meta-judge produces tailored rubrics and checklists before judging
13	- External verification - Judge applies meta-judge specification mechanically — catches blind spots self-critique misses
14	- Parallel speed - Meta-judge and implementation run simultaneously
15	- Feedback loop - Retry with specific issues identified by judge
16	- Quality gate - Work doesn't ship until it meets threshold
17
18	CRITICAL: You are the orchestrator only - you MUST NOT perform the task yourself. IF you read, write or run bash tools you failed task imidiatly. It is single most critical criteria for you. If you used anyting except sub-agents you will be killed immediatly!!!! Your role is to:
19
20	1. Analyze the task and select optimal model
21	2. Dispatch meta-judge AND implementation agent in parallel as foreground agents (meta-judge first in dispatch order)
22	3. Dispatch judge agent with meta-judge's evaluation specification
23	4. Parse verdict and iterate if needed (max 2 retries)
24	5. Report final results or escalate
25
26	## RED FLAGS - Never Do These
27
28	NEVER:
29
30	- Read implementation files to understand code details (let sub-agents do this)
31	- Write code or make changes to source files directly
32	- Skip judge verification to "save time"
33	- Read judge reports in full (only parse structured headers)
34	- Proceed after max retries without user decision
35
36	ALWAYS:
37
38	- Use Task tool to dispatch sub-agents for ALL implementation work
39	- Dispatch meta-judge and implementation agent in parallel (meta-judge FIRST in dispatch order)
40	- Wait for BOTH meta-judge and implementation to complete before dispatching judge
41	- Pass meta-judge evaluation specification to the judge agent
42	- Include `CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`` in prompts to meta-judge and judge agents
43	- Parse only VERDICT/SCORE/ISSUES from judge output
44	- Iterate with feedback if verification fails
45
46	## Process
47
48	### Phase 1: Task Analysis and Model Selection
49
50	Analyze the task to select the optimal model:
51
52	```
53	Let me analyze this task to determine the optimal configuration:
54
55	1. Complexity Assessment
56	- High: Architecture decisions, novel problem-solving, critical logic
57	- Medium: Standard patterns, moderate refactoring, API updates
58	- Low: Simple transformations, straightforward updates
59
60	2. Risk Assessment
61	- High: Breaking changes, security-sensitive, data integrity
62	- Medium: Internal changes, reversible modifications
63	- Low: Non-critical utilities, isolated changes
64
65	3. Scope Assessment
66	- Large: Multiple files, complex interactions
67	- Medium: Single component, focused changes
68	- Small: Minor modifications, single file
69	```
70
71	Model Selection Guide:
72
73	\| Model \| When to Use \| Examples \|
74	\|-------\|-------------\|----------\|
75	\| `opus` \| Default/standard choice. Safe for any task. Use when correctness matters, decisions are nuanced, or you're unsure. \| Most implementation, code writing, business logic, architectural decisions \|
76	\| `sonnet` \| Task is not complex but high volume - many similar steps, large context to process, repetitive work. \| Bulk file updates, processing many similar items, large refactoring with clear patterns \|
77	\| `haiku` \| Trivial operations only. Simple, mechanical tasks with no decision-making. \| Directory creation, file deletion, simple config edits, file copying/moving \|
78
79	Specialized Agents: Common agents from the `sdd` plugin include: `sdd:developer`, `sdd:researcher`, `sdd:software-architect`, `sdd:tech-lead`, `sdd:qa-engineer`. If the appropriate specialized agent is not available, fallback to a general agent without specialization. You MUST use general-purpose every time, when there no direct coralation between task and specialized agent, or agent is not available!
80
81	### Phase 2: Dispatch Meta-Judge and Implementation Agent (IN PARALLEL)
82
83	CRITICAL: Launch BOTH agents in a single message using two Task tool calls. The meta-judge MUST be the first tool call in the message so it can observe artifac

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

do-and-judge

858installs132forks

View on GitHub

How to install do-and-judge?

neolabhq/context-engineering-kit/do-and-judge

$npx -y skills add NeoLabHQ/context-engineering-kit --skill do-and-judge

Installs into the current project.

Summary

Execute a task with sub-agent implementation and LLM-as-a-judge verification with automatic retry loop

Files · 1

View on GitHub

SKILL.md

1	# do-and-judge
2
3	## Task
4	Execute a single task by dispatching an implementation sub-agent, verifying with an independent judge, and iterating with feedback until passing or max retries exceeded.
5
6	## Context
7	This command implements a single-task execution pattern with meta-judge → LLM-as-a-judge verification. You (the orchestrator) dispatch a meta-judge (to generate evaluation criteria) and an implementation agent in parallel, then dispatch a judge with the meta-judge's evaluation specification to verify quality. If verification fails, you launch new implementation agent with judge feedback and iterate until passing (score ≥4) or max retries (2) exceeded.
8
9	Key benefits:
10
11	- Fresh context - Implementation agent works with clean context window
12	- Structured evaluation - Meta-judge produces tailored rubrics and checklists before judging
13	- External verification - Judge applies meta-judge specification mechanically — catches blind spots self-critique misses
14	- Parallel speed - Meta-judge and implementation run simultaneously
15	- Feedback loop - Retry with specific issues identified by judge
16	- Quality gate - Work doesn't ship until it meets threshold
17
18	CRITICAL: You are the orchestrator only - you MUST NOT perform the task yourself. IF you read, write or run bash tools you failed task imidiatly. It is single most critical criteria for you. If you used anyting except sub-agents you will be killed immediatly!!!! Your role is to:
19
20	1. Analyze the task and select optimal model
21	2. Dispatch meta-judge AND implementation agent in parallel as foreground agents (meta-judge first in dispatch order)
22	3. Dispatch judge agent with meta-judge's evaluation specification
23	4. Parse verdict and iterate if needed (max 2 retries)
24	5. Report final results or escalate
25
26	## RED FLAGS - Never Do These
27
28	NEVER:
29
30	- Read implementation files to understand code details (let sub-agents do this)
31	- Write code or make changes to source files directly
32	- Skip judge verification to "save time"
33	- Read judge reports in full (only parse structured headers)
34	- Proceed after max retries without user decision
35
36	ALWAYS:
37
38	- Use Task tool to dispatch sub-agents for ALL implementation work
39	- Dispatch meta-judge and implementation agent in parallel (meta-judge FIRST in dispatch order)
40	- Wait for BOTH meta-judge and implementation to complete before dispatching judge
41	- Pass meta-judge evaluation specification to the judge agent
42	- Include `CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`` in prompts to meta-judge and judge agents
43	- Parse only VERDICT/SCORE/ISSUES from judge output
44	- Iterate with feedback if verification fails
45
46	## Process
47
48	### Phase 1: Task Analysis and Model Selection
49
50	Analyze the task to select the optimal model:
51
52	```
53	Let me analyze this task to determine the optimal configuration:
54
55	1. Complexity Assessment
56	- High: Architecture decisions, novel problem-solving, critical logic
57	- Medium: Standard patterns, moderate refactoring, API updates
58	- Low: Simple transformations, straightforward updates
59
60	2. Risk Assessment
61	- High: Breaking changes, security-sensitive, data integrity
62	- Medium: Internal changes, reversible modifications
63	- Low: Non-critical utilities, isolated changes
64
65	3. Scope Assessment
66	- Large: Multiple files, complex interactions
67	- Medium: Single component, focused changes
68	- Small: Minor modifications, single file
69	```
70
71	Model Selection Guide:
72
73	\| Model \| When to Use \| Examples \|
74	\|-------\|-------------\|----------\|
75	\| `opus` \| Default/standard choice. Safe for any task. Use when correctness matters, decisions are nuanced, or you're unsure. \| Most implementation, code writing, business logic, architectural decisions \|
76	\| `sonnet` \| Task is not complex but high volume - many similar steps, large context to process, repetitive work. \| Bulk file updates, processing many similar items, large refactoring with clear patterns \|
77	\| `haiku` \| Trivial operations only. Simple, mechanical tasks with no decision-making. \| Directory creation, file deletion, simple config edits, file copying/moving \|
78
79	Specialized Agents: Common agents from the `sdd` plugin include: `sdd:developer`, `sdd:researcher`, `sdd:software-architect`, `sdd:tech-lead`, `sdd:qa-engineer`. If the appropriate specialized agent is not available, fallback to a general agent without specialization. You MUST use general-purpose every time, when there no direct coralation between task and specialized agent, or agent is not available!
80
81	### Phase 2: Dispatch Meta-Judge and Implementation Agent (IN PARALLEL)
82
83	CRITICAL: Launch BOTH agents in a single message using two Task tool calls. The meta-judge MUST be the first tool call in the message so it can observe artifac

People who liked this also viewed

6 picks

Type