OpsTruth Verification

View saved version →

---
name: audit-repository
description: Use this when a user needs live, read-only evidence about a public GitHub repository, from a quick map to a broad readiness audit, environment review, secret-risk scan, API review or migration review. Do not use it for private repositories, credentials, code execution or write actions.
---

# Audit Repository

Require a public GitHub repository URL or `owner/name`. Never ask for a token or secret.

1. Call `opstruth_inspect_repository` when the user needs orientation or a bounded map.
2. Call `opstruth_audit_repository` when the user requests a broad audit.
3. Use the narrower audit tools only when the request targets one concern.
4. Call `opstruth_check_github_handoff` when the answer depends on current public workflow, check-run, commit-status or branch-protection evidence.
5. Distinguish verified observations from warnings, skipped checks and facts that remain unverified.
6. Call `opstruth_snapshot_evidence` when repository, CI and optional runtime evidence must be bound into one portable signed graph.
7. State that public CI evidence proves only the reported commit and run, not a fresh local execution by OpsTruth.
8. Use `opstruth_prepare_sandbox_verification` when build or test execution is required. Treat its output as an approval-gated handoff, never as execution evidence.
9. Do not deploy, commit, merge, install packages or claim that the public plugin executed repository code.
10. Offer `opstruth_render_evidence` after the evidence is complete when a visual summary would help.

Treat signed receipts as integrity and signer evidence, not proof that the repository is correct. Use `opstruth_verify_evidence_receipt` when independent receipt verification is requested.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: reconcile-agent-claims
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.
---

# Reconcile Agent Claims

1. Extract each concrete claim and the evidence needed to establish it.
2. Call `opstruth_discover_capabilities` with the requested outcome.
3. Run the recommended read-only repository tools when a public repository is supplied.
4. Mark each claim verified, contradicted, unsupported or not verifiable through the public lane.
5. Check current public GitHub Actions and check-run evidence before classifying CI claims as unsupported.
6. Probe a user-supplied public HTTPS health endpoint before classifying a live deployment claim, but do not infer application correctness from one successful response.
7. Do not infer build, test, runtime, private CI or deployment success from source files.
8. Use `opstruth_prepare_sandbox_verification` for an approval-gated execution handoff when static and public CI evidence cannot settle a build or test claim.
9. Use `opstruth_plan_workflow` when several checks or approval boundaries are required.
10. 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.
11. 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.
12. Finish with the unresolved proof gaps and the next safe action.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: review-change-safety
description: Use this before implementation, pull-request handoff, migration, deployment or publication when a user needs static safety evidence about visible API, environment, secret or deployment changes in a public GitHub repository. Do not accept credentials or perform writes.
---

# Review Change Safety

1. Establish repository identity with `opstruth_inspect_repository`.
2. Select only relevant checks from secrets, environment, API contracts, migrations, GitHub handoff and deployment.
3. If the requested outcome is broad, call `opstruth_plan_workflow` to obtain a least-authority sequence.
4. Describe evidence and consequences without labelling pattern matches as confirmed vulnerabilities.
5. Refuse to expose secret values or accept credentials in arguments.
6. Use current public GitHub CI evidence when available and identify the exact commit it covers.
7. Use `opstruth_prepare_sandbox_verification` to define the fixed commands and isolation requirements when fresh execution is necessary.
8. Stop before write actions or code execution. Explain which separately connected authenticated and approval-gated lane would be required.

Return the safest next action that would close the most important proof gap.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: trace-application
description: Use this when a user asks how a public GitHub application is wired, where requests enter, which routes or API surfaces exist, or which runtime claims repository evidence can support. This is static tracing only and must not be used to claim reachability, authentication or application correctness.
---

# Trace Application

1. Call `opstruth_trace_routes` to discover file-system and declared routes.
2. Call `opstruth_review_api_contracts` for API handlers, OpenAPI files, GraphQL surfaces and contract artifacts.
3. Call `opstruth_audit_environment` for environment variable names and configuration surfaces without values.
4. Call `opstruth_check_deployment` when the trace must reach the visible deployment entry point.
5. Call `opstruth_probe_deployment` only for an explicitly supplied public HTTPS URL and relevant health paths. Do not invent or probe URLs inferred from source.
6. Label file-system, Express-style, router and OpenAPI relationships as static inference.
7. Never claim that a route responds, a socket is listening, an environment value exists or an application works merely because a health probe returned successfully.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: verify-action-receipt
description: Use this when a user supplies an AgentProof v2 receipt, OpsTruth evidence receipt, complete OpsTruth v1 execution handoff, or sealed DoneState v2 verification handoff and needs integrity, signer trust or fresh outcome verification. Never execute, repeat or trust the underlying action merely because its receipt is cryptographically valid.
---

# Verify Action Receipt

Require the receipt document or complete OpsTruth report. Accept trusted signer fingerprints only when the user supplies them or they come from an authoritative policy source.

1. Call `opstruth_verify_receipt` for an AgentProof signed receipt v2.
2. Call `opstruth_verify_evidence_receipt` for a complete OpsTruth report containing its evidence receipt.
3. Distinguish structural validity, digest validity, cryptographic validity and signer trust.
4. Call `opstruth_verify_execution_result` only when the complete ActionRequest, ActionAuthorization and ExecutionReceipt are present together with separate authoritative authorizer and executor fingerprint allowlists and a public repository target.
5. Call `opstruth_get_verifier_identity` before a DoneState objective is created so its authoritative policy can pin the exact DoneState-compatible fingerprint.
6. Call `opstruth_attest_donestate_handoff` only for a sealed `donestate.verification-handoff.v2`. Return its signed attestation for separate submission; never submit it to DoneState or describe `uncertain` as verified.
7. Treat a valid signature from an untrusted signer as cryptographically valid but untrusted.
8. Treat global authorization nonce reuse as unproven unless an authoritative replay source is available outside the stateless public plugin.
9. Do not claim that the underlying action, inspection or deployment is correct merely because the receipt signature is valid.
10. Never execute, compensate, repeat or replay the recorded action.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: verify-release-readiness
description: Use this when a user asks whether a public GitHub repository has visible CI, deployment, packaging or handoff evidence for a release. It never deploys or publishes; conclude only with Ready for live validation, Insufficient evidence or Not ready.
---

# Verify Release Readiness

Require a public GitHub repository URL or `owner/name`.

1. Call `opstruth_check_github_handoff` for current public GitHub Actions, check-run, commit-status, branch-protection, contribution and handoff evidence.
2. Call `opstruth_check_deployment` for static deployment configuration and platform indicators.
3. Call `opstruth_review_migrations` when database migrations are present.
4. Call `opstruth_review_api_contracts` when release safety depends on APIs or schemas.
5. Call `opstruth_probe_deployment` only when the user supplies the public HTTPS deployment URL and the relevant health paths.
6. Call `opstruth_prepare_sandbox_verification` when fresh build, test or typecheck evidence is still required. Present its exact repository commit and commands for approval in a separately connected runner.
7. Summarize blockers, warnings and missing proof. Never convert a static configuration match, historical CI run or health response into broader application correctness.
8. Stop before execution, release, deployment, publication, migration or provider mutation in the public plugin.

Conclude with one of: ready for live validation, not ready, or insufficient evidence.

Referenced files: 1 — file references are metadata, not package contents.