[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JYW2ZPBWKEXRQB97V6CJT1":3,"skill-same:01M6JYW2ZPBWKEXRQB97V6CJT1":89},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6JYW2ZPBWKEXRQB97V6CJT1","proof-verify",null,"Plan-based verification - freeze acceptance criteria before building, then verify after with an independent fresh-context agent (the builder must not verify their own work). For multi-stage work, seal accepted inputs with commit\u002Ftree, contract, input\u002Foutput digests, and a fresh verdict so downstream stages do not reopen them. Use when - \"verify against plan\", \"proof check\", \"independent review\", \"check the implementation\", or confirming a feature built from a plan meets spec. Do NOT use for quick one-off checks with no plan, or for letting the builder self-verify.","AnastasiyaW\u002Fcodex-claude-code-config","AnastasiyaW","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F92753226?v=4","01M6JYPD9X5RRF8G7AH91NYD3R","Anastasiia Butova","01M6JYPDFBGM5EV8G8BABQ3GDY",214,"MIT","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fproof-verify\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"proof verify","verify","proof","self","when","for","tree","quick","input","fresh","feature","context agent","review","do","builder","context","work","plan","verification","acceptance","commit","2026-11-10 10:12:30",false,"---\nname: proof-verify\ndescription: Plan-based verification - freeze acceptance criteria before building, then verify after with an independent fresh-context agent (the builder must not verify their own work). For multi-stage work, seal accepted inputs with commit\u002Ftree, contract, input\u002Foutput digests, and a fresh verdict so downstream stages do not reopen them. Use when - \"verify against plan\", \"proof check\", \"independent review\", \"check the implementation\", or confirming a feature built from a plan meets spec. Do NOT use for quick one-off checks with no plan, or for letting the builder self-verify.\n---\n\n# Proof Verify\n\nPlan-based verification: freeze acceptance criteria BEFORE building, verify AFTER with independent agents.\n\n## When to Use\n\n- After completing a feature\u002Ffix that was built from a plan\n- When you need independent confirmation that work meets spec\n- When the builder should NOT verify their own work\n- Trigger phrases: \"verify against plan\", \"check the implementation\", \"proof check\", \"independent review\"\n\n## The Pattern\n\n```\nPHASE 1: PLAN (before any code)\n  Create .proof\u002FPLAN.md with numbered acceptance criteria\n  Each AC: testable, specific, has a verification command or check\n  Plan is FROZEN - no changes during build\n\nPHASE 2: BUILD (normal work)\n  Implement against the plan\n  Mark progress in .proof\u002FPROGRESS.md\n  Builder does NOT self-verify\n\nPHASE 3: VERIFY (after build, independent agent)\n  Fresh agent reads PLAN.md (never saw the build process)\n  Walks through each AC, runs verification commands\n  Writes .proof\u002FVERDICT.md with PASS\u002FFAIL per criterion\n  If any FAIL → .proof\u002FPROBLEMS.md with specific fixes\n\nPHASE 4: FIX (if needed)\n  Builder reads PROBLEMS.md, makes minimal fixes\n  Back to PHASE 3 (re-verify)\n  Loop until all PASS\n```\n\n## Stage Ledger - only when proof feeds another stage\n\nFor a release, integration, migration, hardware, signer, or other multi-stage\ntask, a green check is not enough. The next stage needs a stable input, not a\nsummary that the previous stage once looked good.\n\n1. Freeze the stage contract and its scope before building it.\n2. Run the focused proof and obtain the fresh verdict as usual.\n3. Write the stage to `.proof\u002Fstage-ledger.json` as `VERIFIED` or `SEALED`.\n   A sealed stage records its source commit\u002Ftree, contract digest, named input and\n   output digests, fresh verdict digest, and invalidation keys.\n4. A downstream stage names the sealed parent and exact output digest it consumes.\n   It must not consume a merely `VERIFIED` or `BLOCKED` stage.\n5. If an external dependency is missing, record `BLOCKED` with the exact missing\n   prerequisite. Do not invalidate the sealed upstream code.\n6. If code, contract, or an input digest changes, add a `SUPERSEDED` successor and\n   re-run proof for that successor; do not overwrite the old receipt.\n\nValidate the ledger deterministically:\n\nResolve `\u003Cproof-verify-skill-dir>` to the directory containing the loaded\n`proof-verify` `SKILL.md`; do not assume that a project checkout has a\n`skills\u002Fdevelopment\u002F` copy:\n\n```text\npython \u003Cproof-verify-skill-dir>\u002Fscripts\u002Fvalidate_stage_ledger.py \\\n  .proof\u002Fstage-ledger.json\n```\n\nThe ledger is not a signing ceremony for every edit. Use it only when an accepted\nresult crosses a real project boundary. Full format, status semantics, and examples:\n`references\u002Fproven-stage-contracts.md`.\n\n## Phase 1: Create Plan\n\nCreate `.proof\u002FPLAN.md` in the project root:\n\n```markdown\n# Verification Plan\n\n**Created:** YYYY-MM-DD HH:MM\n**Task:** [one-line description]\n**Builder:** [session ID or \"current\"]\n**Status:** FROZEN\n\n## Acceptance Criteria\n\n### AC1: [short name]\n**Description:** [what must be true]\n**Verify:** [exact command or check to run]\n**Expected:** [what success looks like]\n\n### AC2: [short name]\n**Description:** [what must be true]\n**Verify:** [exact command or check to run]\n**Expected:** [what success looks like]\n\n### AC3: [short name]\n...\n\n## Out of Scope\n- [explicitly what this plan does NOT cover]\n\n## Constraints\n- [time, resource, or technical constraints]\n```\n\nRules for good ACs:\n- **Testable** - there is a command or check that produces PASS\u002FFAIL\n- **Specific** - \"function returns correct value\" not \"code works\"\n- **Independent** - each AC can be verified without the others\n- **Sufficient** - use one criterion when one observable contract is all that\n  changed; split criteria only when their behavior, owner, or verification\n  command is meaningfully independent\n- **Frozen** - once written, do not modify during build\n\n## Phase 2: Build\n\nNormal implementation. The only additions:\n\n1. Create `.proof\u002FPROGRESS.md` as you work:\n\n```markdown\n# Build Progress\n\n### AC1: [name]\n- [x] Implemented in `src\u002Ffoo.py:42`\n- Files changed: `src\u002Ffoo.py`, `tests\u002Ftest_foo.py`\n\n### AC2: [name]\n- [x] Implemented in `src\u002Fbar.py:18`\n- Files changed: `src\u002Fbar.py`\n- Note: chose approach B because [reason]\n```\n\n2. After build is complete, write `.proof\u002FEVIDENCE.md`:\n\n```markdown\n# Evidence\n\n### AC1: [name]\n**Command:** `pytest tests\u002Ftest_foo.py -v`\n**Output:**\n\\```\ntests\u002Ftest_foo.py::test_returns_correct PASSED\ntests\u002Ftest_foo.py::test_handles_edge PASSED\n\\```\n**Result:** PASS\n\n### AC2: [name]\n**Command:** `grep -c \"TODO\" src\u002Fbar.py`\n**Output:** `0`\n**Result:** PASS\n```\n\nBuilder collects evidence but does NOT write the verdict. That is the verifier's job.\n\n## Phase 3: Verify (Independent Agent)\n\nThis is the critical phase. The verifier MUST be:\n- A **fresh agent** (new session or subagent) that never saw the build\n- Given ONLY: `PLAN.md` + access to the codebase\n- NOT given: `PROGRESS.md`, `EVIDENCE.md`, or any build context\n\n### Verifier prompt template\n\n```\nYou are an independent verifier. Your job is to check whether\nthe implementation meets the acceptance criteria in .proof\u002FPLAN.md.\n\nRules:\n1. Read .proof\u002FPLAN.md first. This is your ONLY specification.\n2. For each AC, run the verification command yourself.\n3. Do NOT read .proof\u002FPROGRESS.md or .proof\u002FEVIDENCE.md\n   (those are the builder's claims - you verify independently).\n4. Write your verdict to .proof\u002FVERDICT.md in this format:\n\n# Verification Verdict\n\n**Verifier:** [your session ID]\n**Date:** YYYY-MM-DD HH:MM\n**Plan hash:** [first 8 chars of md5 of PLAN.md]\n\n## Results\n\n### AC1: [name]\n**Status:** PASS | FAIL\n**Evidence:** [what you saw when you ran the check]\n**Notes:** [any observations]\n\n### AC2: [name]\n...\n\n## Summary\n- Total: N criteria\n- Passed: X\n- Failed: Y\n- **Overall:** PASS | FAIL\n\n5. If any AC fails, also create .proof\u002FPROBLEMS.md:\n\n# Problems\n\n### AC2: [name]\n**Expected:** [from PLAN.md]\n**Actual:** [what you found]\n**Suggested fix:** [smallest change that would fix it]\n**Affected files:** [list]\n\n6. Do NOT fix anything. You are read-only. Report only.\n```\n\n### How to spawn the verifier\n\n**Option A: Subagent (same session)**\n```\nAgent({\n  description: \"Independent verification against plan\",\n  prompt: \"[verifier prompt above]\",\n  mode: \"plan\"  \u002F\u002F read-only first\n})\n```\n\n**Option B: Fresh session (stronger isolation)**\nWrite handoff with instruction: \"Start by reading .proof\u002FPLAN.md and running verification.\"\n\n**Option C: Multiple verifiers (highest confidence)**\nSpawn 2-3 verifiers independently. If they disagree on any AC, that AC needs investigation.\n\n## Phase 4: Fix Loop\n\nIf VERDICT.md shows any FAIL:\n\n1. Builder reads `PROBLEMS.md`\n2. Makes **minimal** fixes (not refactoring, not \"while I'm here\")\n3. Updates `EVIDENCE.md` with new evidence for failed ACs\n4. Verifier runs again (Phase 3)\n5. Loop until all PASS\n\nIf repeated failures stop distinguishing causal hypotheses, re-triage the\naffected owner and evidence. Do not weaken or rewrite an acceptance criterion\nmerely to turn the current implementation green.\n\n## File Structure\n\n```\n.proof\u002F\n  PLAN.md        # frozen acceptance criteria (Phase 1)\n  PROGRESS.md    # builder's notes (Phase 2)\n  EVIDENCE.md    # builder's evidence (Phase 2)\n  VERDICT.md     # verifier's verdict (Phase 3)\n  PROBLEMS.md    # verifier's findings (Phase 3, if failures)\n  stage-ledger.json # only for multi-stage work; accepted inputs and blockers\n```\n\n## Gotchas\n\n- **Builder reads VERDICT, not the reverse.** Verifier never sees builder's evidence. This prevents confirmation bias.\n- **\"PASS with concerns\" is FAIL.** Either it passes or it doesn't. No soft passes.\n- **Plan hash in verdict.** If someone edited PLAN.md mid-build, the hash won't match. Catch.\n- **A later blocker is not retroactive failure.** A missing VM, signer, or account\n  blocks its own stage. It does not turn a sealed source or artifact into a failed one.\n- **Do not reuse stale proof.** A changed contract, source tree, or recorded input\n  requires a successor stage and a fresh verdict.\n- **Duration is not a verdict.** Give a long-running check a bounded timeout\n  appropriate to its environment. Prefer a smaller check only when it proves\n  the same contract; do not discard a valid runtime boundary merely because it\n  takes longer than a fixed threshold.\n- **Don't verify style.** ACs should be functional (\"function returns X\"), not stylistic (\"code is clean\"). Style is for code review, not proof loop.\n\n## Troubleshooting\n\n| Symptom | Cause | Fix |\n|---|---|---|\n| Verifier passes everything | ACs too vague | Rewrite with specific commands |\n| Repeated failures no longer distinguish causal hypotheses | Current owner, evidence, or remedy is no longer discriminating | Re-triage the affected owner and evidence; preserve the frozen acceptance contract unless an explicitly authorized successor contract is required |\n| Verifier disagrees with builder's evidence | Different env or stale state | Both run from clean state |\n| Builder keeps editing PLAN.md | Not frozen | Hash check catches this |\n| A new audit says an old stage is \"missing\" | It mixed an unavailable next prerequisite with already-proven scope | Check `.proof\u002Fstage-ledger.json`; record the external `BLOCKED` stage separately |\n| Downstream proof cannot identify its input | The prior result was a chat claim, not a sealed receipt | Seal the prior stage with commit\u002Ftree, digests, and fresh verdict before proceeding |\n\n## Sources\n\n- [Proof Loop (Principle 02)](..\u002F..\u002F..\u002Fprinciples\u002F02-proof-loop.md) - the theoretical foundation\n- `references\u002Fproven-stage-contracts.md` - immutable stage promotion, provenance, and local ledger contract\n- [OpenClaw-RL](https:\u002F\u002Farxiv.org\u002Fabs\u002F2603.10165) - spec freeze → build → fresh verify\n- [Agent-R](https:\u002F\u002Farxiv.org\u002Fabs\u002F2501.11425) - failed-then-fixed trajectories\n- oh-my-claudecode Ralph - PRD-driven persistence (practical inspiration)\n","# Proof Verify\n\nPlan-based verification: freeze acceptance criteria BEFORE building, verify AFTER with independent agents.\n\n## When to Use\n\n- After completing a feature\u002Ffix that was built from a plan\n- When you need independent confirmation that work meets spec\n- When the builder should NOT verify their own work\n- Trigger phrases: \"verify against plan\", \"check the implementation\", \"proof check\", \"independent review\"\n\n## The Pattern\n\n```\nPHASE 1: PLAN (before any code)\n  Create .proof\u002FPLAN.md with numbered acceptance criteria\n  Each AC: testable, specific, has a verification command or check\n  Plan is FROZEN - no changes during build\n\nPHASE 2: BUILD (normal work)\n  Implement against the plan\n  Mark progress in .proof\u002FPROGRESS.md\n  Builder does NOT self-verify\n\nPHASE 3: VERIFY (after build, independent agent)\n  Fresh agent reads PLAN.md (never saw the build process)\n  Walks through each AC, runs verification commands\n  Writes .proof\u002FVERDICT.md with PASS\u002FFAIL per criterion\n  If any FAIL → .proof\u002FPROBLEMS.md with specific fixes\n\nPHASE 4: FIX (if needed)\n  Builder reads PROBLEMS.md, makes minimal fixes\n  Back to PHASE 3 (re-verify)\n  Loop until all PASS\n```\n\n## Stage Ledger - only when proof feeds another stage\n\nFor a release, integration, migration, hardware, signer, or other multi-stage\ntask, a green check is not enough. The next stage needs a stable input, not a\nsummary that the previous stage once looked good.\n\n1. Freeze the stage contract and its scope before building it.\n2. Run the focused proof and obtain the fresh verdict as usual.\n3. Write the stage to `.proof\u002Fstage-ledger.json` as `VERIFIED` or `SEALED`.\n   A sealed stage records its source commit\u002Ftree, contract digest, named input and\n   output digests, fresh verdict digest, and invalidation keys.\n4. A downstream stage names the sealed parent and exact output digest it consumes.\n   It must not consume a merely `VERIFIED` or `BLOCKED` stage.\n5. If an external dependency is missing, record `BLOCKED` with the exact missing\n   prerequisite. Do not invalidate the sealed upstream code.\n6. If code, contract, or an input digest changes, add a `SUPERSEDED` successor and\n   re-run proof for that successor; do not overwrite the old receipt.\n\nValidate the ledger deterministically:\n\nResolve `\u003Cproof-verify-skill-dir>` to the directory containing the loaded\n`proof-verify` `SKILL.md`; do not assume that a project checkout has a\n`skills\u002Fdevelopment\u002F` copy:\n\n```text\npython \u003Cproof-verify-skill-dir>\u002Fscripts\u002Fvalidate_stage_ledger.py \\\n  .proof\u002Fstage-ledger.json\n```\n\nThe ledger is not a signing ceremony for every edit. Use it only when an accepted\nresult crosses a real project boundary. Full format, status semantics, and examples:\n`references\u002Fproven-stage-contracts.md`.\n\n## Phase 1: Create Plan\n\nCreate `.proof\u002FPLAN.md` in the project root:\n\n```markdown\n# Verification Plan\n\n**Created:** YYYY-MM-DD HH:MM\n**Task:** [one-line description]\n**Builder:** [session ID or \"current\"]\n**Status:** FROZEN\n\n## Acceptance Criteria\n\n### AC1: [short name]\n**Description:** [what must be true]\n**Verify:** [exact command or check to run]\n**Expected:** [what success looks like]\n\n### AC2: [short name]\n**Description:** [what must be true]\n**Verify:** [exact command or check to run]\n**Expected:** [what success looks like]\n\n### AC3: [short name]\n...\n\n## Out of Scope\n- [explicitly what this plan does NOT cover]\n\n## Constraints\n- [time, resource, or technical constraints]\n```\n\nRules for good ACs:\n- **Testable** - there is a command or check that produces PASS\u002FFAIL\n- **Specific** - \"function returns correct value\" not \"code works\"\n- **Independent** - each AC can be verified without the others\n- **Sufficient** - use one criterion when one observable contract is all that\n  changed; split criteria only when their behavior, owner, or verification\n  command is meaningfully independent\n- **Frozen** - once written, do not modify during build\n\n## Phase 2: Build\n\nNormal implementation. The only additions:\n\n1. Create `.proof\u002FPROGRESS.md` as you work:\n\n```markdown\n# Build Progress\n\n### AC1: [name]\n- [x] Implemented in `src\u002Ffoo.py:42`\n- Files changed: `src\u002Ffoo.py`, `tests\u002Ftest_foo.py`\n\n### AC2: [name]\n- [x] Implemented in `src\u002Fbar.py:18`\n- Files changed: `src\u002Fbar.py`\n- Note: chose approach B because [reason]\n```\n\n2. After build is complete, write `.proof\u002FEVIDENCE.md`:\n\n```markdown\n# Evidence\n\n### AC1: [name]\n**Command:** `pytest tests\u002Ftest_foo.py -v`\n**Output:**\n\\```\ntests\u002Ftest_foo.py::test_returns_correct PASSED\ntests\u002Ftest_foo.py::test_handles_edge PASSED\n\\```\n**Result:** PASS\n\n### AC2: [name]\n**Command:** `grep -c \"TODO\" src\u002Fbar.py`\n**Output:** `0`\n**Result:** PASS\n```\n\nBuilder collects evidence but does NOT write the verdict. That is the verifier's job.\n\n## Phase 3: Verify (Independent Agent)\n\nThis is the critical phase. The verifier MUST be:\n- A **fresh agent** (new session or subagent) that never saw the build\n- Given ONLY: `PLAN.md` + access to the codebase\n- NOT given: `PROGRESS.md`, `EVIDENCE.md`, or any build context\n\n### Verifier prompt template\n\n```\nYou are an independent verifier. Your job is to check whether\nthe implementation meets the acceptance criteria in .proof\u002FPLAN.md.\n\nRules:\n1. Read .proof\u002FPLAN.md first. This is your ONLY specification.\n2. For each AC, run the verification command yourself.\n3. Do NOT read .proof\u002FPROGRESS.md or .proof\u002FEVIDENCE.md\n   (those are the builder's claims - you verify independently).\n4. Write your verdict to .proof\u002FVERDICT.md in this format:\n\n# Verification Verdict\n\n**Verifier:** [your session ID]\n**Date:** YYYY-MM-DD HH:MM\n**Plan hash:** [first 8 chars of md5 of PLAN.md]\n\n## Results\n\n### AC1: [name]\n**Status:** PASS | FAIL\n**Evidence:** [what you saw when you ran the check]\n**Notes:** [any observations]\n\n### AC2: [name]\n...\n\n## Summary\n- Total: N criteria\n- Passed: X\n- Failed: Y\n- **Overall:** PASS | FAIL\n\n5. If any AC fails, also create .proof\u002FPROBLEMS.md:\n\n# Problems\n\n### AC2: [name]\n**Expected:** [from PLAN.md]\n**Actual:** [what you found]\n**Suggested fix:** [smallest change that would fix it]\n**Affected files:** [list]\n\n6. Do NOT fix anything. You are read-only. Report only.\n```\n\n### How to spawn the verifier\n\n**Option A: Subagent (same session)**\n```\nAgent({\n  description: \"Independent verification against plan\",\n  prompt: \"[verifier prompt above]\",\n  mode: \"plan\"  \u002F\u002F read-only first\n})\n```\n\n**Option B: Fresh session (stronger isolation)**\nWrite handoff with instruction: \"Start by reading .proof\u002FPLAN.md and running verification.\"\n\n**Option C: Multiple verifiers (highest confidence)**\nSpawn 2-3 verifiers independently. If they disagree on any AC, that AC needs investigation.\n\n## Phase 4: Fix Loop\n\nIf VERDICT.md shows any FAIL:\n\n1. Builder reads `PROBLEMS.md`\n2. Makes **minimal** fixes (not refactoring, not \"while I'm here\")\n3. Updates `EVIDENCE.md` with new evidence for failed ACs\n4. Verifier runs again (Phase 3)\n5. Loop until all PASS\n\nIf repeated failures stop distinguishing causal hypotheses, re-triage the\naffected owner and evidence. Do not weaken or rewrite an acceptance criterion\nmerely to turn the current implementation green.\n\n## File Structure\n\n```\n.proof\u002F\n  PLAN.md        # frozen acceptance criteria (Phase 1)\n  PROGRESS.md    # builder's notes (Phase 2)\n  EVIDENCE.md    # builder's evidence (Phase 2)\n  VERDICT.md     # verifier's verdict (Phase 3)\n  PROBLEMS.md    # verifier's findings (Phase 3, if failures)\n  stage-ledger.json # only for multi-stage work; accepted inputs and blockers\n```\n\n## Gotchas\n\n- **Builder reads VERDICT, not the reverse.** Verifier never sees builder's evidence. This prevents confirmation bias.\n- **\"PASS with concerns\" is FAIL.** Either it passes or it doesn't. No soft passes.\n- **Plan hash in verdict.** If someone edited PLAN.md mid-build, the hash won't match. Catch.\n- **A later blocker is not retroactive failure.** A missing VM, signer, or account\n  blocks its own stage. It does not turn a sealed source or artifact into a failed one.\n- **Do not reuse stale proof.** A changed contract, source tree, or recorded input\n  requires a successor stage and a fresh verdict.\n- **Duration is not a verdict.** Give a long-running check a bounded timeout\n  appropriate to its environment. Prefer a smaller check only when it proves\n  the same contract; do not discard a valid runtime boundary merely because it\n  takes longer than a fixed threshold.\n- **Don't verify style.** ACs should be functional (\"function returns X\"), not stylistic (\"code is clean\"). Style is for code review, not proof loop.\n\n## Troubleshooting\n\n| Symptom | Cause | Fix |\n|---|---|---|\n| Verifier passes everything | ACs too vague | Rewrite with specific commands |\n| Repeated failures no longer distinguish causal hypotheses | Current owner, evidence, or remedy is no longer discriminating | Re-triage the affected owner and evidence; preserve the frozen acceptance contract unless an explicitly authorized successor contract is required |\n| Verifier disagrees with builder's evidence | Different env or stale state | Both run from clean state |\n| Builder keeps editing PLAN.md | Not frozen | Hash check catches this |\n| A new audit says an old stage is \"missing\" | It mixed an unavailable next prerequisite with already-proven scope | Check `.proof\u002Fstage-ledger.json`; record the external `BLOCKED` stage separately |\n| Downstream proof cannot identify its input | The prior result was a chat claim, not a sealed receipt | Seal the prior stage with commit\u002Ftree, digests, and fresh verdict before proceeding |\n\n## Sources\n\n- [Proof Loop (Principle 02)](..\u002F..\u002F..\u002Fprinciples\u002F02-proof-loop.md) - the theoretical foundation\n- `references\u002Fproven-stage-contracts.md` - immutable stage promotion, provenance, and local ledger contract\n- [OpenClaw-RL](https:\u002F\u002Farxiv.org\u002Fabs\u002F2603.10165) - spec freeze → build → fresh verify\n- [Agent-R](https:\u002F\u002Farxiv.org\u002Fabs\u002F2501.11425) - failed-then-fixed trajectories\n- oh-my-claudecode Ralph - PRD-driven persistence (practical inspiration)\n",{"name":5,"description":7},"main","ac20f93f36e574610dbc51743bb21e7765142e95","skills\u002Fdevelopment\u002Fproof-verify",32,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config","https:\u002F\u002Fgithub.com\u002FAnastasiyaW","https:\u002F\u002Fhappyin.work","ComfyUI specialist · turnkey image-processing pipelines · diffusion models, computer vision · Belgrade","2026-11-14 01:35:49",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill proof-verify",{"tool":65,"command":66},"bunx","bunx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill proof-verify",{"tool":68,"command":69},"pnpm","pnpm dlx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill proof-verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fproof-verify\u002FSKILL.md",true,[73,79,83],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fkb-aware-verification.md","REFERENCE","参考文档",2951,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fproof-verify\u002Freferences\u002Fkb-aware-verification.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fproven-stage-contracts.md",5663,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fproof-verify\u002Freferences\u002Fproven-stage-contracts.md",{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"scripts\u002Fvalidate_stage_ledger.py","SCRIPT","脚本",6530,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopment\u002Fproof-verify\u002Fscripts\u002Fvalidate_stage_ledger.py",[90,99,114,139,166,184],{"skillNo":91,"name":92,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":96,"publishedAt":45},"01M6JZ2SNGKFN8NK3HZBMVGQP1","owner-voice","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fowner-voice\u002FSKILL.md",[95],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[97,98],"owner voice","voice",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":45},"01M6JZ2N0C2WFCAK6T8N3RMBVS","humanize-russian","Редактировать русский текст для ясности и естественного звучания, сохраняя факты,\nтермины, источники и жанр. Использовать когда: убрать канцелярит, сделать текст\nживее, отредактировать русский черновик или статью перед публикацией.\nНе определяет авторство и не обещает обход детекторов. Для английского —\nhumanize-english; для структуры и доказательств — article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-russian\u002FSKILL.md",[105],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[107,108,109,110,36,111,112,113],"russian","humanize","humanize russian","english","structure","article","2026",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":45},"01M6JZ2GN264R6GKBQ5QVZE0ZS","humanize-english","Edit English drafts for clear, natural language while preserving facts, uncertainty,\ntechnical meaning, citations and genre. Use when: humanize this text, remove AI-style\nfiller, improve English prose, or edit an English article before publication.\nNot an authorship detector or a promise to bypass one. For Russian use\nhumanize-russian; for thesis\u002Fevidence and structure use article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-english\u002FSKILL.md",[],[108,110,121,122,107,123,124,125,126,111,127,128,129,36,130,113,28,29,131,132,133,134,135,136,112,137,138],"humanize english","technical","evidence","use","remove","edit","text","improve","Citations","Publication","facts","natural language","drafts","meaning","uncertainty","style","thesis","promise",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":45},"01M6JZ2BM31D5Y609DQJJJM6MM","caveman","Ultra-compressed reply mode. Cuts output tokens ~65-75% by answering in terse \"caveman\" style while keeping full technical accuracy, and shapes what survives: action first, state restated every turn, concrete time estimates, visible wins. Intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says \"caveman\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", or Russian \"пещерный режим\", \"говори как пещерный\", \"кратко\", \"меньше токенов\", \"экономь токены\" — or invokes \u002Fcaveman. Preserves the user's language (Russian in → Russian caveman out). Off only: \"stop caveman\" \u002F \"normal mode\" \u002F \"обычный режим\". Do not use merely because a response should be concise, and do not use when the user requests normal prose, a polished document, or exact wording.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fcaveman\u002FSKILL.md",[],[141,136,28,146,147,148,149,150,151,152,153,154,155,156,157,158,37,107,159,160,161,162,124,122,163,164,165],"normal","terse","accuracy","ultra","mode","document","requests","concise","output","intensity","tokens","full","time","action","default","stop","only","first","brief","state",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":181,"publishedAt":45},"01M6JZ25Y5GJXFKXNR6TRQX237","article-structure-review","Проверить структуру технической статьи после черновика: задача читателя, жанр,\nопора значимых утверждений на доказательства и честные ограничения.\nUse after the first draft, before publication. Исправлять структуру, когда это\nвходит в запрос; не создавать обязательный конвейер из других навыков.\nДля локальной языковой редактуры — humanize-english или humanize-russian.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Farticle-structure-review\u002FSKILL.md",[172,175,176],{"categoryNo":173,"categoryName":174,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":177,"categoryName":178,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[182,112,111,36,183,108,107,124,163,110,130,113],"article structure review","draft",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":193,"publishedAt":45},"01M6JZ1XN7WQQCWCHHMTTD8K28","video-post-production","Video post-production rules: audio mastering, color, captions, platform export. Use when: 'add music', 'add voiceover', 'export for tiktok', 'add captions', 'color grade', 'audio levels', 'master audio', 'export settings', 'platform requirements'. Covers FFmpeg patterns, audio chain, subtitle standards, and platform-specific export configs. Do NOT use to generate or animate the video frames\u002Fscenes in code (use remotion-production-guide), to write the script (use video-narrative-arc), or to evaluate script quality (use script-evaluator); this is the finishing stage applied to an already-rendered video.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fvideo-production\u002Fvideo-post-production\u002FSKILL.md",[190],{"categoryNo":191,"categoryName":192,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[194,195,196,197,198,28,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213],"video post production","post","Production","Video","patterns","post-production","narrative","add","chain","tiktok","voiceover","master","export","write","music","Captions","Audio","Remotion","code","generate"]