The health-controller-stub-detector Skill — Catching Stubs Before They Block Compliance
How Datarim surfaces hard-coded stub literals in health and status controllers at implementation time — before they mislead acceptance tests and block the compliance gate.
A health endpoint returning HTTP 200 with a status field of pending-integration can pass an automated smoke test. The test sees 200, the field is present, and no assertion fails. But the field is a placeholder, not a live probe — the downstream service is not wired up yet, and the endpoint is lying about the system's state. The health-controller-stub-detector skill catches this class of defect at implementation time, before it reaches quality assurance.
The skill is invoked by /dr-do Step 7 when a task touches any file matching patterns like *health*controller*, *health*service*, *liveness*, *readiness*, or *status*indicator*, and equivalent role-named files in any stack.
The detector
The check runs a grep against the diff's added lines — not the full file — looking for six literal patterns: pending-integration, not-implemented, not_implemented, unimplemented, "stub", and any team-specific placeholder conventions the operator extends the set with. Pre-existing stub literals in untouched lines generate a non-blocking advisory only; the blocking gate applies only to new additions in the current diff.
Three dispositions for each match
When the detector finds a stub literal in new added lines, the operator must choose one of three explicit dispositions before the task advances. The first is to implement the live probe now: replace the literal with a real downstream health check and remove the placeholder. The second is to defer explicitly: move the placeholder to a clearly-labelled deferred section of the controller, add an inline comment naming the tracking ticket, and open a backlog item with a standardised naming pattern. The third is to document the item as out of scope on this task and reference the follow-up task ID.
Leaving a stub literal without any of these three dispositions recorded is not an acceptable outcome. That is the path to the silent contract gap the skill was designed to close.
The incident that motivated the skill
A multi-modal request flow landed end-to-end in a downstream service. The upstream health controller's indicator for that service remained a hard-coded pending-integration literal — a deferred health-reporter integration that was not part of the current task. An acceptance criterion that probed the /health endpoint treated the literal as proof of wire-up. The check passed. The contract gap surfaced only at the compliance gate, late in the pipeline, and blocked the verdict cycle until the operator reconciled the wording.
Catching the pattern at /dr-do rather than at /dr-compliance eliminates the extra pipeline cycle that reconciliation requires.
Connection to expectations
The skill cross-references the expectations-checklist contract: wish items should not cite a /health literal as proof of service wire-up. A health endpoint returning a stub status is evidence of deferral, not of integration. When a wish is written to treat that endpoint as authoritative, the stub detector and the expectations validator will produce contradictory verdicts — the stub says "not wired", the wish says "check the endpoint". The fix is to align the wish criterion with the actual implementation state.
Read more about the Datarim pipeline in what Datarim is, or see how the expectations-checklist skill governs what counts as verified evidence at quality assurance time.