{"id":18915,"plugin_id":"plugins_6a8d4dc60bf081918a06094873890eb4","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:15:02.360Z","digest":"b4b157b41a7153ee83bfe9ac35058242bc5a6a62197b81f4607d36a16afdee00","against":null,"payload":{"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"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}