agentleFS
muratsilahtaroglumuratsilahtaroglu/claude-code-starter-kit/.claude/skills/keel-pilot/SKILL.md

keel-pilot

Skill9 starsChanged 51 days agoMITView on GitHub

Staged bulk-run gate — before any mass-output job (labeling, generation, migration) enforce, in order, declare thresholds → smoke sample → gold-set validation → progressive ramp with halt conditions → acceptance sample. No full run on an unvalidated pipeline.

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. Distinctive:

    Use when a task will produce many outputs whose quality cannot be eyeballed one by one — mass labeling/classification, bulk generation, …

    line 8
  2. Very specific:

    Write into the task (TASKS.md done-when: or a short pilot plan next to the runner):

    line 18
  3. Distinctive:

    Run the pipeline end-to-end on 10–50 representative items, edge cases included.

    line 29
  4. Distinctive:

    Run on the gold set; compare per class (aggregate accuracy hides minority-class failure — median GPT-4 accuracy across 27 real tasks was …

    line 34
  5. Distinctive:

    Write to a staging location (Write-Audit-Publish) — never directly to the final table/dir.

    line 47
  6. Very specific:

    All green → publish staging → final.

    line 55
  7. Distinctive:

    If the same bulk pipeline recurs, promote a project-specific PreToolUse gate (block the bulk entrypoint unless a fresh pilot report exists) …

    line 62

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

/keel-pilot — never run a big batch blind

Use when a task will produce many outputs whose quality cannot be eyeballed one by one — mass labeling/classification, bulk generation, large migrations/transforms (heuristic: >100 items, or any unattended run). The failure this kills: pipelines verified "sometimes, by mood" — quality problems discovered after 5,000 items, or never. The sequence below is the published norm, not an invention (Anthropic best-practices fan-out, Pangakis et al. 2023, SRE canarying, Write-Audit-Publish); evidence trail with sources: research/*/findings.md (2026-07-16).

Five gates, in order. A gate must PASS before the next opens — report each as pass/fail.

Gate 0 — DECLARE (before anything runs)

Write into the task (TASKS.md done-when: or a short pilot plan next to the runner):

  • acceptance metrics — e.g. per-class precision/recall vs a gold set; schema-validity %;
  • halt thresholds for the full run — e.g. >5% schema-invalid, or error rate >2× the pilot's, in any rolling 100-item window → HALT;
  • sample plan — smoke size (10–50) · gold set (250+ human-labeled items when label quality is load-bearing; smaller only with the user's explicit OK) · honeypot rate (5–10%) · acceptance sample by the rule of three (0 errors in 60 ⇒ <5% true error rate, in 300 ⇒ <1%, at 95%). Thresholds chosen AFTER seeing outputs are not thresholds. Defaults above are the literature's — adjust per project, with the user.

Gate 1 — SMOKE (10–50 items)

Run the pipeline end-to-end on 10–50 representative items, edge cases included. Human eyeball + mechanical schema check (fields present, types right, label ∈ allowed set). Any surprise → fix, re-smoke. Never skip to Gate 3 because "the code looks right".

Gate 2 — VALIDATE (against ground truth)

Run on the gold set; compare per class (aggregate accuracy hides minority-class failure — median GPT-4 accuracy across 27 real tasks was 0.850 while a third of tasks had precision or recall below 0.5). Agreement bar: Krippendorff α ≥ 0.800 to rely on labels; 0.667–0.800 supports only tentative conclusions. Below bar → revise prompt/config and re-run THIS gate. Record the passing numbers in reports/ (dated) — they are the baseline the circuit breaker compares against.

Gate 3 — RAMP (staged full run)

  • Scale ~1% → ~10% → 100%, checking the declared metrics at each step before widening.
  • Seed honeypots (gold items, 5–10%) into the live stream; score them as results arrive.
  • Schema-validate every record as it is produced (cheap script, not an LLM).
  • Circuit breaker: the declared halt thresholds are enforced by the runner script — a breach HALTS the run (dbt error_if semantics), it does not merely warn.
  • Checkpoint by stable id so a halted run resumes without redoing finished work.
  • Write to a staging location (Write-Audit-Publish) — never directly to the final table/dir.

Gate 4 — ACCEPT (before publishing)

  • Draw the acceptance sample (60 or 300 per the rule of three) and check it. For judgment calls, spawn the verifier subagent to adversarially refute a random subset — the agent that produced the batch does not grade it. If the grader is itself an LLM: swap positions / use several diverse votes (position and self-preference bias are documented).
  • Route low-consistency or non-unanimous items to the user (human review) rather than guessing.
  • All green → publish staging → final. Write the one-liner (counts, error bound, gate results) into HANDOVER (a), and add the pipeline's must-run check as a LESSONS.md [test] line.

Scope honesty

  • The gate sequence is ritual (this skill); the runner mechanics (schema validator, breaker, checkpointing, honeypot scoring) are a small per-project script under src/, written at Gate 0 if missing — prose cannot enforce a breaker, the script does.
  • If the same bulk pipeline recurs, promote a project-specific PreToolUse gate (block the bulk entrypoint unless a fresh pilot report exists) — the §2.9 promotion rule applied to enforcement.
  • Re-runs after a prompt/model/config change start again at Gate 2 ("LLM hacking": config choices alone flip conclusions). A pilot passed months ago is not a current pilot.

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.