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.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add muratsilahtaroglu/claude-code-starter-kit --skill keel-pilot --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Keel Pilot?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/muratsilahtaroglu-keel-pilot)More formats (shields.io, HTML) on the badges page.
---
name: keel-pilot
description: 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.
---
# /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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!