dr-improve
Skill4 starsChanged 7 months agoMITView on GitHub
Self-improvement loop for research quality. Evaluates completed research tasks against binary eval criteria, identifies failure patterns, mutates the researcher subagent instructions, re-runs a sample of failed tasks, and keeps the improved version if score goes up.
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 8 are distinctive, and 15 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
15
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Check for a bare number argument → set sample_size (default: 5)
- Very specific: line 18
Check for --criteria flag → set add_criteria = true
- Very specific: line 19
Check for --cycles N → set cycle_count = N (default: 1)
- Very specific: line 23
Read .research/evals.md. Each criterion is binary: PASS or FAIL per entry.
- Very specific: line 25
If --criteria flag is passed, ask the user to add new criteria before proceeding.
- Very specific: line 29
Read all files in data/. For each entry in each file:
- Distinctive: line 30
Run every eval criterion → PASS or FAIL
- Very specific: line 34
If sidecar files exist → include adversary_survival_rate as a key metric alongside overall pass rate
- Very specific: line 35
If NO sidecar files exist (zero *.adversary.json files) → skip all adversary criteria automatically.
- Distinctive: line 36
If a sidecar file contains malformed JSON → skip that file, log a warning, continue processing others
- Very specific: line 91
Read current .claude/agents/dr-researcher.md (project-local) or fall back to the installed agents/dr-researcher.md
- Very specific: line 100
After identifying failure patterns, also extract "attack patterns" from sidecar files (data/*.adversary.json):
- Distinctive: line 106
Cap at 5 total Known Vulnerabilities: If the researcher already has 5, replace the oldest (topmost) vulnerability with the newest one.
- Distinctive: line 107
If no sidecar files exist, skip this sub-step entirely.
- Very specific: line 109
Write the updated researcher to .claude/agents/dr-researcher.md
- Very specific: line 116
If not enough [!] tasks, pick tasks whose entries had the lowest eval scores
- Distinctive: line 120
Run using the updated researcher (same process as /dr-run Step 5)
- Distinctive: line 121
Verify output (same process as /dr-run Step 6)
- Very specific: line 126
Run the same eval criteria from Step 2 on the full dataset (including the re-run entries).
- Very specific: line 164
If --cycles flag was passed and cycles remain, automatically go back to Step 2.
- Very specific: line 168
If evals.md is missing, tell the user to run /dr-new first.
- Very specific: line 169
If no data files exist, tell the user to run /dr-run first to generate data before improving.
- Distinctive: line 170
If the researcher file doesn't exist, create one from the default template.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
You are running a self-improvement loop on the research process. The researcher subagent's instructions are the "trainable parameter." Eval pass rate is the metric.
Accepts arguments:
/dr-improve— single improvement cycle, default sample size 5/dr-improve 10— set sample size to 10/dr-improve --criteria— add new eval criteria before improving/dr-improve --cycles 3— run 3 improvement cycles/dr-improve 10 --criteria --cycles 3— combine: sample 10, add criteria, 3 cycles
Argument Parsing
- Check for a bare number argument → set sample_size (default: 5)
- Check for
--criteriaflag → set add_criteria = true - Check for
--cycles N→ set cycle_count = N (default: 1)
STEP 1: Load Eval Criteria
Read .research/evals.md. Each criterion is binary: PASS or FAIL per entry. Parse them into a checklist.
If --criteria flag is passed, ask the user to add new criteria before proceeding. Append to evals.md.
STEP 2: Score Current Performance
Read all files in data/. For each entry in each file:
- Run every eval criterion → PASS or FAIL
- Record results per entry and per criterion
Adversary-aware scoring: Also read any sidecar files (data/*.adversary.json). Merge sidecar verdicts with data entries by matching task_id and field_name.
- If sidecar files exist → include
adversary_survival_rateas a key metric alongside overall pass rate - If NO sidecar files exist (zero
*.adversary.jsonfiles) → skip all adversary criteria automatically. The data IS the state — no config flag needed. - If a sidecar file contains malformed JSON → skip that file, log a warning, continue processing others
Calculate:
- Overall pass rate (entries where ALL criteria pass / total entries)
- Per-criterion pass rate
- Total entries evaluated
- Adversary survival rate (if sidecar files exist):
(confirmed + weakened) / (confirmed + weakened + refuted)
Save results to .research/eval-history/baseline.json (first run) or .research/eval-history/iteration-{N}.json (subsequent runs).
Format:
{
"timestamp": "ISO date",
"iteration": 0,
"overall_pass_rate": 0.68,
"total_entries": 45,
"per_criterion": {
"has_all_required_fields": 0.85,
"has_source_url": 0.92,
"valid_status": 0.98,
"claims_sourced": 0.62,
"own_website_in_sources": 0.55
},
"entries_evaluated": 45,
"entries_passing": 31
}STEP 3: Analyze Failures
Spawn the dr-evaluator subagent with:
Analyze these eval results:
- Overall pass rate: {rate}
- Per-criterion rates: {rates}
- Total entries: {count}
- Adversary survival rate: {rate or "N/A — no sidecar files"}
Read the data files in data/ and the eval criteria in .research/evals.md.
Also read any sidecar files (data/*.adversary.json) and merge verdicts with data entries.
Answer:
1. Which criteria fail most frequently?
2. Are failures clustered by category, type, or data source?
3. What do passing entries do differently from failing entries?
4. What specific changes to the researcher's instructions would fix the top 3 failure patterns?
5. Which claims were refuted or weakened by the adversary? What patterns emerge?
Return structured JSON with top_failure_patterns and suggested_improvements.STEP 4: Mutate Researcher
- Read current
.claude/agents/dr-researcher.md(project-local) or fall back to the installedagents/dr-researcher.md - Save a backup copy to
.research/eval-history/researcher-v{N}.md - Apply surgical changes targeting the top 3 failure patterns identified in Step 3
- Changes must be concrete instructions, not vague advice:
- BAD: "Be more thorough when searching"
- GOOD: "Always search for '{entity name} funding' and '{entity name} crunchbase' as separate queries. Extract the funding amount from the first result that contains a dollar figure."
- Change 1-3 instructions per cycle. Do not rewrite the entire file.
- Inject Known Vulnerabilities (if sidecar files exist):
After identifying failure patterns, also extract "attack patterns" from sidecar files (
data/*.adversary.json):- An attack pattern = a
field_name+extraction_methodcombination that wasrefutedorweakened2+ times across batches - Scan all sidecar verdicts, group by
field_name, count refuted+weakened per field - Take the top 3 attack patterns (by refuted+weakened count)
- Inject them as "Known vulnerabilities" bullet points in the researcher's
## Data Rulessection, right after the existing rules - Format each as:
- **Known vulnerability:** {field} claims using {method} are frequently contested. {specific mitigation advice based on the adversary's counter-evidence}. - Cap at 5 total Known Vulnerabilities. If the researcher already has 5, replace the oldest (topmost) vulnerability with the newest one. Oldest = the one that has been there the longest (first in the list).
- If no sidecar files exist, skip this sub-step entirely.
- An attack pattern = a
- Write the updated researcher to
.claude/agents/dr-researcher.md
STEP 5: Re-run Sample
- Determine sample size (default 5, or from argument)
- Select tasks to re-run:
- First, pick tasks marked
[!](failed) in todo.md - If not enough
[!]tasks, pick tasks whose entries had the lowest eval scores
- First, pick tasks marked
- For each selected task:
- Reset the task from
[!]or[x]to[ ]in todo.md - Back up the existing data entry
- Run using the updated researcher (same process as /dr-run Step 5)
- Verify output (same process as /dr-run Step 6)
- Mark
[x]or[!]in todo.md
- Reset the task from
STEP 6: Score Again
Run the same eval criteria from Step 2 on the full dataset (including the re-run entries). Save to .research/eval-history/iteration-{N}.json.
STEP 7: Keep or Revert
Compare new overall pass rate to previous:
New score > old score → KEEP
Improvement: {old}% → {new}% (+{delta}%)
Changes kept:
- {change 1}
- {change 2}
Researcher version: v{N}New score <= old score → REVERT
No improvement: {old}% → {new}%
Reverting researcher to v{N-1}.
Changes discarded:
- {change 1}
- {change 2}Restore the backup researcher from .research/eval-history/researcher-v{N-1}.md.
Log to .research/CHANGELOG.md:
[timestamp] | IMPROVE | {old}% → {new}% | kept/reverted | {summary of changes}STEP 8: Suggest Next Action
Based on the current pass rate:
- < 70%: "Pass rate is below 70%. Recommend running
/dr-improveagain to target remaining failure patterns." - 70-85%: "Pass rate is in the acceptable range. Continue research with
/dr-runor improve further with/dr-improve." - > 85%: "Pass rate is strong. Ready for
/dr-reportto synthesize findings, or continue with/dr-run."
If --cycles flag was passed and cycles remain, automatically go back to Step 2.
Error Handling
- If evals.md is missing, tell the user to run
/dr-newfirst. - If no data files exist, tell the user to run
/dr-runfirst to generate data before improving. - If the researcher file doesn't exist, create one from the default template.
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
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.

