agentleFS
NITISH-R-GNITISH-R-G/hackerrank-orchestrate-skills/skills/orchestrate-test-fix/SKILL.md

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.

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
  1. Very specific:

    Overfitting audit: Look for rules that depend on ID format, timestamp format, row order, or exact sample wording.

    line 13
  2. Very specific:

    Determinism: Run twice on identical input.

    line 14
  3. Distinctive:

    Write the change record: CHANGE, the requirement it serves, the rows it should fix, the rows it could break, cost, verdict.

    line 26
  4. Distinctive:

    Never gate a decision on the truth value of a model-written free-text field.

    line 37
  5. Distinctive:

    Stop tuning once one number is right on sample and the change would not generalise.

    line 39
  6. Distinctive:

    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.

    line 43
  7. Distinctive:

    Run this in the session (the skill cannot set it for you):

    line 49

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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)

  1. 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.
  2. 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.
  3. Determinism. Run twice on identical input. Outputs must match. If not, find the exact difference. Read references/determinism-auditor.md.
  4. 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.
  5. 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:

  1. Trace it to the stage that failed.
  2. 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.
  3. Write the change record: CHANGE, the requirement it serves, the rows it should fix, the rows it could break, cost, verdict.
  4. Re-run and diff the entire output.
  5. 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-bugs skill 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.