aiw-ground-truthlisted

Establishes where trusted inputs and expected outputs come from during coding tasks, so the agent's tests, fixtures, and assumed-correct values have authority not invented by the agent. Use this skill before generating a test fixture, constructing expected output, mocking an external system, reusing earlier fixtures, deleting code, or assuming what 'correct' means, and at the start of every task to classify the work into one or more of the nine modalities (New, Feature, Fix, Refactor, Improve, Investigate, Migrate, Configure, Delete). It owns the trust hierarchy for ground-truth sources, the canonical modality decision procedure shared across the workflow, modality-specific oracle rules, the sourcing protocol when real ground truth is missing, storage and provenance for ground-truth artifacts, and the boundary distinguishing ground truth from test setup. It breaks the closed loop where the agent writes the code, fixtures, and tests and reads its own results with no external check.
philippe-ths/ai-coding-workflow · ★ 0 · AI & Automation · score 66

Install: claude install-skill philippe-ths/ai-coding-workflow

# Ground Truth Read this file again whenever the task's modality is unclear, when the agent is about to invent example data, or when reusing fixtures from earlier in the session. ## Why This Skill Exists In AI-assisted coding the same actor writes the code, generates the test fixtures, runs the tests, and reads the results. Four roles, one actor, no external check. When everything passes, that fact alone proves nothing — the loop is self-referential. This skill keeps the loop broken by anchoring the agent's checks to inputs and expected outputs whose authority does not come from the agent. A test cannot be more trustworthy than its oracle. If the oracle was invented by the same process that produced the code under test, a passing test is evidence only that the agent is internally consistent — not that the system is correct. ## Trust Hierarchy Classify every input and expected output the work will rely on. Highest trust first: 1. **Real production data or captured runs from real usage.** Captured from real users during real execution. 2. **Real artifacts from the upstream tool or system that produces the inputs.** Files, payloads, or events generated by the actual upstream producer, not a model of it. 3. **Snapshots of previous known-good runs of the system itself.** A captured output from a prior version known to behave correctly, used to detect drift. 4. **Hand-constructed minimal examples confirmed by the user.** Small inputs and expected outputs the user has reviewe