verify-technical

Imported from warwick-bit/llm-accuracy (plugins/llm-accuracy/skills/verify-technical/SKILL.md). Install upstream with npx skills add warwick-bit/llm-accuracy --skill verify-technical. Copyright stays with the author.

Verify technical work

Use the tools and repository instructions available in the current workspace. This workflow supplies no provider access and never authorizes a destructive probe, deployment or external message.

1. Define the claim. State the symptom, affected process/environment/version, expected result and the observation that would establish success. Separate repair, local verification, deployment and production verification.
2. Reproduce or inspect. Run the narrowest safe reproduction, or inspect current evidence if reproduction is unavailable. Record the command/check, result and scope in the conversation. An unavailable reproduction is a gap.
3. Compare causes. Keep two or three plausible explanations. For each, identify a discriminating observation. Test the strongest supported causes; stop broadening when the evidence is sufficient for the requested scope.
4. Change the owning layer. Inspect applicable instructions and consumers first. Make the smallest justified change. Do not change unrelated settings to make the reproduction disappear.
5. Repeat the original check. Use the same input and affected environment after the change. Where possible, demonstrate fail-before/pass-after. A new test that never exercised the failure does not establish that it is fixed.
6. Check the boundary. Run relevant regression checks and required repo gates. A local pass does not establish CI, deployment or another machine's state. Verify those separately only when they are in the requested scope.
7. Reconcile corrections. When new evidence changes the diagnosis, revisit dependent recommendations. If the user disputes a claim, recheck the evidence before agreeing or defending it. Do not replace one unsupported cause with another.

Do not require new tool calls to repeat still-valid, directly checked evidence. Keep failed, partial and unavailable checks visible. File excerpts and sampled rows establish only the portion observed, including when no warning is emitted.

Before drafting, check every material assertion, including intermediate bridges: could a plausible alternative explain the observation while that assertion is false? If the evidence cannot distinguish it, keep it as a hypothesis or leave it unresolved. Focus on alternatives that affect the requested conclusion; do not hedge a directly supported narrow fact because of merely imaginable doubts.

For example, unspecified passing tests establish a test pass, not that the incident was exercised or fixed locally. An older build does not establish that a particular patch is absent; inspect its contents or deployment identity. If a bridge is removed, restate the verdict on surviving evidence or downgrade it too. A correct verdict does not excuse an unsupported reason.

Lead with the supported conclusion and uncertainty. Preserve that same scope in short status labels, summaries and follow-ups. End substantive diagnoses or verification claims with:

• Checked: actual checks, outcomes and scope; explicitly say none if none ran.
• Gap: unresolved causes, unavailable checks or untested environments.
• Next: the smallest useful check or action, or none within the agreed scope.

This is an advisory workflow and model-written summary, not an independent accuracy certificate. Use claim-fidelity for a detailed claim-by-claim audit.