Contributor Reference

Engineering Discipline — Behavioral Drills

Live quality drills for contributors testing whether engineering skills actually produce correct agent behavior. Not for end users. Requires a running Aperio instance and the ability to judge code quality, methodology, and red flags. Paste each trigger prompt in a fresh chat and evaluate the agent's response.

How this differs from Skill Matching: The Skill Matching page tests whether the right skill name fires for a prompt (Layer 1 — deterministic matcher). These drills test whether the loaded skill actually changes agent behavior (Layer 2 — live LLM judgment call). A skill can match correctly and still produce bad behavior. These drills catch that gap.

The Drills

debugging-and-error-recovery

Trigger promptThis test crashes with TypeError: cannot read 'id' of undefined — debug it and find the root cause.

It reproduces the error first, reads the stack trace, names one hypothesis, makes a minimal fix, then re-runs to verify — and ends by stating the root cause + showing the passing output.

Changing code at random and re-running; trying the same fix twice; saying "it should work now" without re-running.

test-driven-development

Trigger promptImplement a slugify(str) function using TDD.

Writes a failing test first, shows it RED, writes minimal code, shows it GREEN, only then refactors.

Writing the implementation first; a test that passes on the very first run (never saw RED); a tautological assertion.

security-and-hardening

Trigger promptAdd a /search?q= route that queries the users table by name.

Parameterized query (no string concatenation), input validation on q, a note on rate-limiting / authorization, no secrets in code.

Building the SQL with string interpolation of q; "the frontend validates it"; deferring all of it to "later".

code-review-and-quality

Trigger promptPaste a small diff and ask: "review this before I merge."

Walks design → correctness → tests → complexity → naming → security; separates blocking from nit; gives an explicit approval / request-changes verdict.

"Looks good, approve" with no specifics; bike shedding style while missing a broken edge case; silently rewriting instead of commenting.

code-simplification

Trigger promptPaste a deeply-nested function and ask: "simplify this without changing behavior."

Checks why the code exists (Chesterton's Fence), confirms tests cover it, simplifies in small steps, keeps behavior identical, tests still green.

Deleting code it can't explain; changing behavior under the banner of "simplifying"; shorter-but-denser result.

reasoning-planning (augmentation)

Trigger promptBuild a feature that exports user data as CSV.

Spec gate: Surfaces ASSUMPTIONS I'M MAKING: and a brief spec (objective / interface / testing / boundaries) with testable success criteria before planning the how.

Execution: Executes one slice at a time, verifies each before the next, and pauses on a failing step instead of bulldozing.

Jumping straight to a big code dump; vague success criteria ("make it work"); stacking changes on an unverified step.

Quick-Reference Checklist

After changing any of these skills

  1. Re-run node skills/autotune/score.mjs — exam must stay 23/23.
  2. If you changed keywords, re-do the relevant Layer-1 probe rows from the Skill Matching page (Tests 6–10).
  3. Log the result: node skills/autotune/score.mjs --log keep --desc "what changed".

Collision guards that must stay green

Prompt gistMust still resolve to
"review this Go code for naming conventions…"coding-standards (not code-review)
"run a Playwright browser test…"webapp-testing (not TDD)
"complex multi-step task… plan first"reasoning-planning
Note: holdout 0.5 and the hard failures for pptx/canvas/docx-adv/prompt-opt/memory/wiki/mcp are pre-existing known-hard cases, unrelated to these skills. Don't chase them here.