mcpField
M
maintain-formal-verification-skill

maintain-formal-verification-skill

github.com/yeachan-heoその他40.7k8 回インストール今日更新
リポジトリ

maintain-formal-verification-skill について

Maintain Formal Verification Skillは、既存の形式検証プロジェクト用スキルを、対象コードに同期するためのスキルです。引用と前提を確認し、必要に応じてモデルを更新して検証器を再実行し、性質を弱めずに結果を記録します。

主な機能

  1. 01コードの引用と前提を監査
  2. 02モデルのずれを検出
  3. 03コードに合わせて手順と前提を更新
  4. 04検証ツールを再実行
  5. 05ledgerを通じて結果を記録

活用シーン

  1. 01プロトコルや不変条件の変更後にモデルを更新
  2. 02リファクタリング後にコード引用を確認
  3. 03最近のコードに対して以前の成功結果を再検証
  4. 04モデルの再生成が必要か判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill maintain-formal-verification-skill

インストール後、Claude Code で/maintain-formal-verification-skillを入力して読み込まれたか確認します。

README(原文)English

プロジェクトの README より

この README の日本語訳はまだありません。以下は英語の原文です。日本語の紹介はページ上部をご覧ください。

Maintain Formal Verification Skill

A formal spec that cites lines that no longer exist is stale, and a stale spec's green is worthless. This skill re-syncs an existing verify-formal-* project skill (created by create-formal-verification-skill) to the code it models.

When to use

  • the modeled protocol, arithmetic, or invariant changed shape
  • cited file:line anchors drifted after refactors
  • before trusting a green run that predates recent changes to the covered code

Workflow

  1. Inventory the model's bindings: every cited file:line, every named function, every assumption on the skill's assumption list.
  2. Re-check each binding against current code: does the cited line still contain the modeled step? Does the assumption still hold (pid reuse, atomicity, integer width, timing)? A binding that no longer matches is drift; record it, do not silently absorb it.
  3. Update the model where drift is real: move citations, adjust steps to the new protocol shape, and rewrite the assumption list to match reality. The property itself does not weaken — if the new code violates the property, that is a finding to report, not a model edit.
  4. Rerun the tool (TLC/apalache, lake build, cargo kani) and capture real output.
  5. Update the project skill in place: new citations, new assumption list, same run command — and record the resync through the ledger's locked writer (appendLedgerEntry and defaultLedgerPath from the installed package's dist/features/verification-ledger/index.js; babysit's ledger step demonstrates the exact invocation — never append raw rows): formally-verified with the rerun command as evidence only when the rerun is green; a counterexample during resync records verifier-failed with the counterexample as evidence and is reported before any model change.

Rules

  • A counterexample found during resync is reported before any model change; verify whether the code shares the flaw.
  • Never mark a resync done with an unrerun tool; the rerun is the resync.
  • If more than half the bindings drifted, say so — the model may have been modeling an implementation that no longer exists, and regeneration via create-formal-verification-skill is the honest path.

コメント