task-orchestrator: Skill for Claude Code

Test Authoring Framework

This skill defines how test authorship is separated from implementation. It exists because an agent that writes both the code and its tests has no adversary in the loop — the tests confirm what was built, not what was intended. The trend record backing this trait names the recurring cost directly: vacuous positive assertions with || isEmpty() escapes, a test oracle computed from the implementation's own formula, assumeTrue wrapped around three real production bugs so they never turned the suite red, and coverage claimed in notes that didn't exist in the test tree. review-quality already names the bias — "the agent that wrote the tests has an inherent bias toward believing they're correct" — this skill is the structural fix upstream of review: an independent authorship step, gated at the point where an oracle can still be frozen before implementation exists to copy from.

Everything below applies whether the test author is a separate dispatch or, in a degraded mode, the same agent operating at a different, declared point in time. The separation is the point — follow it exactly even when it feels redundant with work you can already see.

When docs_read get (rootId, kind rule, slug test-author) succeeds, the served text is authoritative for §3–§10; this skill is the fallback and the Claude-specific addendum.

1. When This Applies — The Two Seats

The trait needs-test-author puts two seats on an item, occupied at different phases:

• The plan author, at queue phase, fills test-plan — scenarios, oracle sources, and probes, frozen before any implementation exists. This is the structural lever: an oracle written before code exists cannot be derived from that code, no matter who writes it later.
• The test author, at work phase, fills test-manifest — the actual test files, written after implementation has landed so they compile against the real signatures, but without reading the implementation's reasoning or its own tests.