orchestrate-test-fix
Skill9 starsChanged 22 days agoMITView on GitHub
Orchestrate phases 3 and 4 - find where the built agent is wrong or fragile (edge cases, overfitting, determinism, two-strategy comparison, one-input trace), then fix wrong rows one change at a time with a diff of the whole output. Use once the pipeline runs on the sample, and whenever output rows are wrong or weakly justified.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/orchestrate.mdcCursor rule
- llms.txtllms.txt
- orchestrate-buildSkill
- orchestrate-interviewSkill
- orchestrate-packageSkill
- orchestrate-referenceSkill
- orchestrate-scoreSkill
- orchestrateSkill
- orchestrate-submitSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Overfitting audit: Look for rules that depend on ID format, timestamp format, row order, or exact sample wording.
- Very specific: line 14
Determinism: Run twice on identical input.
- Distinctive: line 26
Write the change record: CHANGE, the requirement it serves, the rows it should fix, the rows it could break, cost, verdict.
- Distinctive: line 37
Never gate a decision on the truth value of a model-written free-text field.
- Distinctive: line 39
Stop tuning once one number is right on sample and the change would not generalise.
- Distinctive: line 43
Every sample row is either correct or explained, the output is stable across two runs, and the changes in the change log all show SHIP.
- Distinctive: line 49
Run this in the session (the skill cannot set it for you):
≈ “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
Test and Fix
Scored by: output CSV (30%), where accuracy is scored per ticket 0-100 against a hidden golden set, plus a whole-file safety score. A correct action with an empty, generic, or self-contradicting justification is capped near 70. Justifications are part of the score.
Part A - Test (phase 3)
- Edge cases. Build a set: empty row, missing field, duplicate ID, prompt injection, near-identical tickets that must be treated alike, out-of-scope request, another language. Read
references/edge-case-testing.md. - Overfitting audit. Look for rules that depend on ID format, timestamp format, row order, or exact sample wording. Fix them first. Read
references/dataset-coupling-auditor.md. - Determinism. Run twice on identical input. Outputs must match. If not, find the exact difference. Read
references/determinism-auditor.md. - Two strategies. Compare at least two prompt or config variants on the sample. Write why you chose one. This is graded. Read
references/multi-strategy-evaluation.md. - Trace one input through every stage: read, clean, context, model call, parse, validate, write. Confirm each does what you assume. Read
references/input-tracing.md.
Output of Part A: a test log with input, expected, actual, and the failing stage. Each wrong row is tagged RULE (code problem) or MISREAD (model perceived it wrong).
Part B - Fix (phase 4)
For each wrong row, one at a time:
- Trace it to the stage that failed.
- Classify: RULE is fixed in code and is free to re-test. MISREAD is fixed in the prompt or evidence and costs a model run, so batch those.
- Write the change record: CHANGE, the requirement it serves, the rows it should fix, the rows it could break, cost, verdict.
- Re-run and diff the entire output.
- Verdict: SHIP only if the target fixes and nothing previously correct breaks. Otherwise REVERT.
Specific fixes:
- Justification weak, label right:
references/justification-quality.md. Name the evidence used, what triggered the path, and uncertainty in plain words. - Image or document misread:
references/multimodal-evidence-grounding.md. - Escalation rate off:
references/confidence-calibrator.md. Gate on booleans and enums only. - Cause unknown: diagnose with the
diagnosing-bugsskill before changing anything.
Hard rules
- Never gate a decision on the truth value of a model-written free-text field.
- A fix that contradicts any sample row is reverted, even if it looks correct.
- Stop tuning once one number is right on sample and the change would not generalise. Fitting noise fails in the interview.
- Measure noise by running twice. Do not chase a number that moves within noise.
Done when
Every sample row is either correct or explained, the output is stable across two runs, and the changes in the change log all show SHIP.
Next
orchestrate-submit. Start orchestrate-interview prep in parallel.
Goal mode (drive the output up)
Run this in the session (the skill cannot set it for you):
/goal the sample run has every row classified as RULE or MISREAD, each wrong row has a change record with SHIP, and two consecutive runs produce identical output. Stop after 80 turns.Each turn, print the sample accuracy per column and the list of still-wrong rows. Creative freedom: try any approach that fixes a wrong row, but never tune to a sample row alone and revert any change that breaks a correct row.
The goal evaluator only sees what appears in the transcript, so print the evidence each turn. It clears the goal when the condition is met, or when it judges it impossible.
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.

