Worked examples
These examples show the shape of good behavior, not guaranteed outputs. The exact evidence and actions depend on the repository, tools, permissions, and domain context available to the host agent.
1. A recurring production symptom
Prompt
The checkout intermittently shows success but no order appears. Find the real cause,
fix it, and prove it is resolved. Do not deploy without asking.
Why the skill applies
The symptom crosses several layers, the cause is uncertain, and production deployment is outside the supplied authority.
Evidence-first path
- Frame the outcome as durable order creation with an accurate customer state—not merely hiding the error.
- Map the request ID across client, API, payment callback, queue, and database evidence.
- Compare hypotheses such as a duplicate callback, transaction rollback, idempotency mismatch, and delayed read replica.
- Choose the smallest test whose predicted result differs across those explanations.
- Implement the supported local fix only after preserving failure evidence.
- Verify unit behavior, integration behavior, retry semantics, and a full local checkout path.
- Report local proof separately from the unperformed production deployment.
Honest handoff
Proved: local reproduction no longer loses the order under the tested retry sequence.
Evidence: focused regression, integration trace, and end-to-end local flow.
Not assessed: production traffic behavior and deployment health.
Next authorized action: review the patch, then approve a staged deployment and monitoring window.
The agent must not say “production issue resolved” before the production evidence exists.
2. A database migration proposal
Prompt
Move this service to the new schema with zero downtime. Challenge the plan before changing code.
Why the skill applies
“Zero downtime” is a broad claim, ordering matters, and data changes can be difficult to reverse.
Evidence-first path
- Convert “zero downtime” into observable acceptance conditions and an allowed maintenance budget.
- Inventory readers, writers, background jobs, data volume, version skew, and rollback constraints.
- Test whether expand–migrate–contract is sufficient before proposing additional infrastructure.
- Keep schema expansion, dual compatibility, backfill, cutover, and contraction sequential.
- Parallelize independent load analysis, rollback review, and data-integrity checks.
- Require operational evidence before claiming the migration has completed without interruption.
What not to do
- Treat a schema migration command succeeding on a sample database as proof of zero downtime.
- Contract the old schema before all deployed readers are compatible.
- add a streaming platform merely because it is a familiar migration pattern.
3. Conflicting business metrics
Prompt
Finance and Product report different monthly active customer counts.
Determine which number we should use for the renewal decision.
Why the skill applies
The task is a decision and definition problem before it is a query problem.
Evidence-first path
- Define the decision, population, cutoff, unit of analysis, and meaning of “active customer.”
- Preserve each source query and identify differences in grain, timezone, late data, exclusions, and entity resolution.
- Classify both inspected policy and current table contents as confirmed facts with different provenance, time, and scope; keep the metric owner’s policy choice as a user decision.
- Create reconciliation categories instead of forcing one number to match the other.
- Choose the metric only after linking its definition to the renewal decision.
- State whether historical months were recomputed and which periods remain affected by late arrivals.
Possible outcome shape
The result may be a reconciled definition and an unresolved policy choice, not a newly computed number. If only the metric owner can decide whether trial accounts count, the agent should expose that authority boundary rather than inventing it.
4. Automating a release process
Prompt
Our release checklist is manual and error-prone. Automate it completely.
Why the skill applies
“Completely” is ambiguous, automation can publish externally, and more automation is not automatically better.
Evidence-first path
- Observe the current process and classify failures by frequency and consequence.
- Distinguish deterministic checks from approvals that require human authority.
- Establish a minimal baseline: validation and package creation without publication.
- Add automatic release creation only if the authorization and rollback model are explicit.
- Test failure behavior, reruns, version conflicts, permissions, and partial publication.
- Prove the documented flow from a clean checkout while keeping real publication behind approval.
Complexity gate
If a single CI workflow with protected environments covers the measured failure modes, do not introduce a custom orchestrator. If cross-repository coordination demonstrably requires durable state, record that evidence before expanding the architecture.
5. A task that should not trigger the full method
Prompt
Rename this local variable from timeoutMs to requestTimeoutMs.
Unless the rename spans a public API or hidden compatibility boundary, the useful response is a focused edit and proportional verification. A full hypothesis ledger would add cost without improving the decision.
Reusable prompt patterns
Investigate before committing
Use $evidence-first-problem-solving. Separate observations from assumptions,
compare the plausible explanations, and recommend a direction only after a test can distinguish them.
Execute after the gate
The direction and local-edit authority are approved. Implement the smallest complete solution,
preserve unrelated work, and reopen the decision only if material contradictory evidence appears.
Audit a completion claim
Audit this result claim by claim. For each claim, identify the required proof,
inspect the strongest available evidence, and mark it proved, partially proved,
not proved, or not assessed. Report any blockers separately.
Coordinate independent work
Map the dependency graph. Keep coupled implementation sequential,
parallelize only independent investigation and review, and define merge evidence for each workstream.