Skip to content
cccskills
FreePublished on GitHub

verify-before-claim

Use when an agent is about to claim completion, correctness, safety, publication, deployment, or any consequential external fact.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141 stars(GitHub 141 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md5.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Verify Before Claim

<skill_contract> <input>One falsifiable claim, its artifact or system, risk, expected result, permissions, and available checks.</input> <output>A scoped claim decision with fresh evidence, residual risk, approval, and rollback status.</output> <done>The cheapest direct check after the final material change supports the exact allowed wording.</done> <non_goals>Producing the artifact, inferring success from effort, or widening a claim beyond checked evidence.</non_goals>

No evidence, no claim. Match the check to the exact claim, use fresh evidence, and keep execution authority separate from approval authority for consequential actions.

Usage Template

Provide: proposed claim, artifact or system, risk level, available checks, expected result, permissions, and rollback path.

Workflow

<intake>
  1. Rewrite the proposed statement as one falsifiable claim.
  2. Classify risk: low, material, or consequential.
  3. Select the cheapest check that directly tests the claim.
  4. Record expected signal, time boundary, and acceptable evidence.
</intake>

<unknowns_gate>

If the artifact, expected behavior, or verification method is missing, return NEEDS_INPUT. If only indirect evidence exists, return INSUFFICIENT_EVIDENCE or narrow the claim; never fill the gap with confidence language.

</unknowns_gate>

<execute>

Run the selected check after the final material change. Examples: targeted test, lint, build, link check, read-after-write, diff inspection, source comparison, dashboard query, or deployment health check. Capture command/query, timestamp, scope, exit status, and key output.

Treat runtime termination as control evidence, not task evidence. A normalized complete signal still needs the acceptance check; a tool request needs a host execution receipt; truncation needs a checkpoint; refusal/error/unknown cannot support completion. A claimed NO_OP needs a fresh eligibility query, an output-count check, and proof that no prohibited side effect occurred.

For material or consequential claims, obtain independent verification from a separate check, reviewer, or evidence source. Require human approval before irreversible publication, deployment, spending, deletion, credential use, or policy change. Confirm the rollback path before execution.

For Graph claims, verify static contract integrity, every required node and join receipt, terminal acceptance, budgets, permission/compensation state, and checkpoint identity. Passing nodes do not prove the end-to-end graph.

</execute> <evaluate>

Compare observed versus expected result. Decide supported, partially_supported, unsupported, or blocked. Check scope: passing one test cannot prove the full suite; a successful write cannot prove link integrity. State residual risk and evidence age.

</evaluate>

<retry_policy>

max_attempts: 2. Retry only after diagnosing the failure and changing input, tool, scope, or strategy. Stop on repeated signature or NO_PROGRESS; never rerun an unchanged check to manufacture confidence.

</retry_policy>

<state_contract>

Persist {run_id, status, attempt, budget, evidence, unknowns, last_error, next_action} plus claim, risk, check specification, expected/observed results, approval receipt, and rollback readiness. Append verification events so evidence age remains visible.

</state_contract>

Failure Protocol

  • NEEDS_INPUT: the claim or expected result is ambiguous; ask one discriminating probe.
  • INSUFFICIENT_EVIDENCE: no direct check supports the requested scope; narrow or withhold the claim.
  • BLOCKED_PERMISSION: approval or access is absent; do not perform the action.
  • VERIFY_FAILED: observed evidence contradicts the claim; report failure and recovery.
  • NO_PROGRESS: the same verification signature fails twice; stop and escalate.
  • BUDGET_STOP: verification budget is exhausted; preserve evidence and do not claim completion. max_attempts: 2.

Output Contract

Return status, result (claim decision and allowed wording), evidence (fresh receipts), unknowns (including residual risk), and next_action (repair, approval, rollback, or stop).

Edge Cases

  • Tests passed before a final edit: evidence is stale; rerun the relevant checks after the edit.
  • A scheduled agent reports success but its normalized termination was truncation: withhold completion and verify from the checkpoint.
  • A maintenance agent emits nothing: call it a verified NO_OP only when the eligibility and side-effect checks both pass.
  • Every Graph node is green but the reduce join lacks one declared input: withhold graph completion and return VERIFY_FAILED.
  • An authoritative page is unavailable: report INSUFFICIENT_EVIDENCE; do not substitute an uncited recollection for the external fact.

Success Metrics

  • Every material completion claim has a fresh, scope-matched receipt.
  • Consequential actions have independent verification, approval, and rollback readiness.
  • Failed checks change the claim or execution state immediately.

Quality Gates

  • Claim, expected result, and check scope match.
  • Evidence was produced after the last material change.
  • Termination and no-op claims have direct host/runtime receipts.
  • Partial checks lead to partial wording.
  • Approval and rollback controls match risk.

</skill_contract>

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when work has genuinely independent streams or distinct builder, evaluator, domain, and integration roles that require bounded multi-agent command scaled from 5 to 100+ agents.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when designing or refactoring a model-native engineering workflow with bounded autonomy, probes, custom evaluation, durable state, and verified write-back.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when property-service operations need an AI plus ontology plus DMAIC design for work orders, dispatch, quotes, evidence, CTQ metrics, and control dashboards.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when a personal or team operating system needs a bounded redesign using Four-C, closed-loop controls, 70/30 allocation, 3B creativity, experiments, and prediction-error learning.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when a goal must be converted into a repeatable behavior, cue, SOP, review cadence, and identity-aligned reinforcement.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

Use when source material must be transformed into a compact, evidence-aware model for learning, decisions, or an Obsidian concept note.

The English summary is being prepared. Showing the original description.

Mark393295827/third-brain-v7-skills141Updated Sep 19, 2026

See all skills by Mark393295827

Report a problem with this skill