Update to OpsTruth

{
  "description": "Use this when a user asks whether an AI or agent really finished a public-repository task, whether claims drift from live evidence, or which lowest-authority verification capability should run next. Do not treat static files, signatures or one health response as proof of execution or correctness.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 432
    }
  ],
  "name": "reconcile-agent-claims",
  "skill_md_contents": "---\nname: reconcile-agent-claims\ndescription: Use this when a user asks whether an AI or agent really finished a public-repository task, whether claims drift from live evidence, or which lowest-authority verification capability should run next. Do not treat static files, signatures or one health response as proof of execution or correctness.\n---\n\n# Reconcile Agent Claims\n\n1. Extract each concrete claim and the evidence needed to establish it.\n2. Call `opstruth_discover_capabilities` with the requested outcome.\n3. Run the recommended read-only repository tools when a public repository is supplied.\n4. Mark each claim verified, contradicted, unsupported or not verifiable through the public lane.\n5. Check current public GitHub Actions and check-run evidence before classifying CI claims as unsupported.\n6. Probe a user-supplied public HTTPS health endpoint before classifying a live deployment claim, but do not infer application correctness from one successful response.\n7. Do not infer build, test, runtime, private CI or deployment success from source files.\n8. Use `opstruth_prepare_sandbox_verification` for an approval-gated execution handoff when static and public CI evidence cannot settle a build or test claim.\n9. Use `opstruth_plan_workflow` when several checks or approval boundaries are required.\n10. Use `opstruth_snapshot_evidence` when all observations must be bound to one exact subject. Use `opstruth_compare_snapshots` only for two caller-held Evidence Graph v1 snapshots of the same immutable repository identity.\n11. If a complete ActionRequest, ActionAuthorization and ExecutionReceipt chain is supplied with separate authoritative authorizer and executor fingerprint allowlists, call `opstruth_verify_execution_result` for fresh independent verification. Never infer success from the receipt state.\n12. Finish with the unresolved proof gaps and the next safe action.\n"
}