本文へ移動
cccskills
無料GitHub で公開

verify-before-claim

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

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skillsスター 141(GitHub 141 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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>

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

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.

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skills1412026年9月19日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skills1412026年9月19日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skills1412026年9月19日 更新

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.

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skills1412026年9月19日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skills1412026年9月19日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

Mark393295827/third-brain-v7-skills1412026年9月19日 更新

Mark393295827 のスキルをすべて見る

このスキルの問題を報告する