markusdowne/detectability-contract
Creates boundary-point validation contracts, defines invariant-based success criteria, and sets up automated verification probes so reliability workflows trigger on objective evidence rather than intuition. Use when designing robust handoff, memory-persistence, or tool-call reliability workflows; when you need to verify handoffs work, check memory persistence, validate tool calls succeeded, or convert vague reliability goals into concrete, testable checks at each boundary point with explicit failure-class mapping (operational vs. critical); or when you want to test your workflow end-to-end, make sure it works, or verify your automation runs correctly using read-back probes and escalation triggers rather than agent confidence. Includes explicit untrusted-content/prompt-injection guardrails for third-party inputs.
96
Quality
90%
Does it follow best practices?
Impact
98%
1.25xAverage score across 9 eval scenarios
task.mdevals/scenario-5/
Automated Deployment Pipeline Contract
Problem/Feature Description
A DevOps team is building an automated deployment pipeline for a microservice. The pipeline has four stages that execute in sequence: (1) build the Docker image and push it to a registry, (2) update the deployment manifest and commit it to the GitOps repo, (3) wait for the deployment to roll out in the cluster, and (4) run a smoke test against the live endpoint and write a final deployment report. Each stage passes state to the next via files in a shared working directory.
Past outages occurred when the smoke test stage ran against a pod that was still rolling out (stale state from the deployment stage), or when the final report was written before the smoke test actually ran. The team wants a comprehensive detectability contract that covers all major handoff points in this pipeline, so every boundary has explicit evidence requirements and escalation rules.
Output Specification
Produce the following files:
contract.md— A comprehensive contract document with a boundary table covering all four stage transitions in this pipeline: (a) build→registry handoff, (b) manifest→GitOps repo state write, (c) cluster deployment resume/readiness check, (d) smoke test→final report handoff. All required columns must be filled in for every row.
The contract should be thorough enough that a new engineer could implement automated checks from it without asking clarifying questions.