[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M734CSB2M3WRPQX6544MS9YY":3,"skill-same:01M734CSB2M3WRPQX6544MS9YY":45},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M734CSB2M3WRPQX6544MS9YY","final-verify",null,"Enforces fresh verification evidence before any completion, fix, or passing claim, and before commits or PR creation. Use when an agent is about to report success, hand off work, or commit code. Do not use for early planning, brainstorming, or tasks that have not yet reached a concrete verification step.","itseffi\u002Fproductize","itseffi","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F15998472?v=4","01M734C5RJ7CKRTPB3FX84VZV7","Effi","01M734C5S6B7FW62ZNWYBZ9GG7",3,"MIT","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Ffinal-verify\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: final-verify\ndescription: Enforces fresh verification evidence before any completion, fix, or passing claim, and before commits or PR creation. Use when an agent is about to report success, hand off work, or commit code. Do not use for early planning, brainstorming, or tasks that have not yet reached a concrete verification step.\n---\n\n# Verification Before Completion\n\n## Overview\n\nClaiming work is complete without verification is dishonesty, not efficiency.\n\n**Core principle:** Evidence before claims, always.\n\n**Violating the letter of this rule is violating the spirit of this rule.**\n\n## The Iron Law\n\n```\nNO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE\n```\n\nIf the verification command has not been run in the current message, the result cannot be claimed.\n\n## The Gate Function\n\n```\nBEFORE claiming any status or expressing satisfaction:\n\n1. IDENTIFY: What command proves this claim?\n2. RUN: Execute the FULL command (fresh, complete)\n3. READ: Full output, check exit code, count failures\n4. VERIFY: Does output confirm the claim?\n   - If NO: State actual status with evidence\n   - If YES: State claim WITH evidence\n5. ONLY THEN: Make the claim\n\nSkip any step = lying, not verifying\n```\n\n## Scope of Verification\n\nMatch the verification scope to the claim scope:\n\n- **Narrow claim** (e.g., \"this test passes\"): Run the specific test.\n- **Broad claim** (e.g., \"task complete\", \"ready to commit\"): Run the **full verification pipeline** — formatting, linting, all tests, and build. If the project defines a single gate command (e.g., `make verify`), run that.\n\nA narrow verification does not support a broad claim. Running `make test` alone does not justify \"task complete.\" Running the linter alone does not justify \"ready to commit.\" The verification scope must be equal to or broader than the claim scope.\n\n**If in doubt, run the full pipeline.** Over-verification wastes minutes. Under-verification wastes hours.\n\n**Passing pipeline != meeting requirements.** A green build proves the code compiles, lints, and passes existing tests. It does not prove the implementation matches the requirements. For \"task complete\" or \"requirements met\" claims, also verify the deliverables against the original specification — line by line, not by assumption.\n\n## Common Failures\n\n| Claim                 | Requires                        | Not Sufficient                 |\n| --------------------- | ------------------------------- | ------------------------------ |\n| Tests pass            | Test command output: 0 failures | Previous run, \"should pass\"    |\n| Linter clean          | Linter output: 0 errors         | Partial check, extrapolation   |\n| Build succeeds        | Build command: exit 0           | Linter passing, logs look good |\n| Bug fixed             | Test original symptom: passes   | Code changed, assumed fixed    |\n| Regression test works | Red-green cycle verified        | Test passes once               |\n| Agent completed       | VCS diff shows changes          | Agent reports \"success\"        |\n| Requirements met      | Line-by-line checklist          | Tests passing                  |\n\n## Red Flags\n\n- Using \"should\", \"probably\", or \"seems to\"\n- Expressing satisfaction before verification\n- About to commit, push, or open a PR without verification\n- Trusting another agent's success report\n- Relying on partial verification\n- Thinking \"just this once\"\n- Any wording that implies success without current evidence\n\n## Rationalization Prevention\n\n| Excuse                                  | Reality                |\n| --------------------------------------- | ---------------------- |\n| \"Should work now\"                       | Run the verification   |\n| \"I'm confident\"                         | Confidence ≠ evidence  |\n| \"Just this once\"                        | No exceptions          |\n| \"Linter passed\"                         | Linter ≠ compiler      |\n| \"Agent said success\"                    | Verify independently   |\n| \"I'm tired\"                             | Exhaustion ≠ excuse    |\n| \"Partial check is enough\"               | Partial proves nothing |\n| \"Different words so rule doesn't apply\" | Spirit over letter     |\n\n## When To Apply\n\nApply this skill before:\n\n- any success or completion claim\n- any expression of satisfaction with the implementation state\n- any commit or PR creation\n- any handoff that implies correctness\n- moving to the next task based on completion\n\n## Pre-Commit and Pre-PR Gate\n\nCommits and PRs are permanent artifacts. They require the highest verification standard.\n\n**Before `git commit`:**\n1. Run the full verification pipeline (e.g., `make verify`). Not a subset. The full pipeline.\n2. Confirm zero errors, zero warnings, zero test failures in the output.\n3. Produce a Verification Report (see template below) with verdict PASS.\n4. Only then run `git commit`.\n\n**Before creating a PR:**\n1. All of the above, plus:\n2. Verify the diff matches the intended changes (`git diff` review).\n3. Confirm no unrelated files are staged.\n\nIf the full pipeline has not passed in this session after the last code change, the commit or PR must not proceed.\n\n## Verification Report Template\n\nVerification is not complete until the agent **cites actual command output** in their response. \"I ran it and it passed\" is not evidence. If the verification output is not shown, the verification did not happen.\n\nEvery verification must be reported using this structure. Do not deviate.\n\n```\nVERIFICATION REPORT\n-------------------\nClaim: [What is being claimed — e.g., \"tests pass\", \"build succeeds\", \"task complete\"]\nCommand: [Exact command run — e.g., `make verify`]\nExecuted: [Timestamp or \"just now, after all changes\"]\nExit code: [0 or non-zero]\nOutput summary: [Key lines from output — pass count, error count, build result]\nWarnings: [Any warnings, or \"none\"]\nErrors: [Any errors, or \"none\"]\nVerdict: PASS or FAIL\n```\n\nIf the verdict is FAIL, do not use completion language. State what failed and what remains.\n\nIf the verdict is PASS, the claim may proceed — but only the specific claim supported by the evidence. \"Tests pass\" does not mean \"build succeeds.\"\n\n## When Verification Fails\n\nVerification failure is not a dead end. It is information. Follow this protocol:\n\n1. **Read the failure.** Identify the exact error: which command failed, which test, which lint rule, which build error. Quote the relevant output lines.\n2. **Diagnose the root cause.** Do not guess. Read the error message. Trace it to the source. If multiple things failed, address them one at a time starting with the first failure.\n3. **Fix the root cause.** Apply the minimal change that addresses the actual error. Do not apply workarounds, suppress warnings, or skip checks.\n4. **Re-verify from scratch.** Run the full verification command again. Do not assume the fix worked. Do not run only the previously-failing subset.\n5. **Report with evidence.** Use the Verification Report Template. If it passes now, the claim may proceed. If it fails again, return to step 1.\n\n**Never:**\n- Claim partial success (\"3 of 4 checks pass, close enough\")\n- Skip re-verification after a fix (\"I fixed the error, so it should pass now\")\n- Blame the tooling (\"the linter is wrong\") without evidence of a false positive\n- Move on to the next task while verification is still failing\n\nIf the correct verification command is unclear, identify it before making any completion claim. If only partial verification is available, state that limitation explicitly and avoid completion language.\n","# Verification Before Completion\n\n## Overview\n\nClaiming work is complete without verification is dishonesty, not efficiency.\n\n**Core principle:** Evidence before claims, always.\n\n**Violating the letter of this rule is violating the spirit of this rule.**\n\n## The Iron Law\n\n```\nNO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE\n```\n\nIf the verification command has not been run in the current message, the result cannot be claimed.\n\n## The Gate Function\n\n```\nBEFORE claiming any status or expressing satisfaction:\n\n1. IDENTIFY: What command proves this claim?\n2. RUN: Execute the FULL command (fresh, complete)\n3. READ: Full output, check exit code, count failures\n4. VERIFY: Does output confirm the claim?\n   - If NO: State actual status with evidence\n   - If YES: State claim WITH evidence\n5. ONLY THEN: Make the claim\n\nSkip any step = lying, not verifying\n```\n\n## Scope of Verification\n\nMatch the verification scope to the claim scope:\n\n- **Narrow claim** (e.g., \"this test passes\"): Run the specific test.\n- **Broad claim** (e.g., \"task complete\", \"ready to commit\"): Run the **full verification pipeline** — formatting, linting, all tests, and build. If the project defines a single gate command (e.g., `make verify`), run that.\n\nA narrow verification does not support a broad claim. Running `make test` alone does not justify \"task complete.\" Running the linter alone does not justify \"ready to commit.\" The verification scope must be equal to or broader than the claim scope.\n\n**If in doubt, run the full pipeline.** Over-verification wastes minutes. Under-verification wastes hours.\n\n**Passing pipeline != meeting requirements.** A green build proves the code compiles, lints, and passes existing tests. It does not prove the implementation matches the requirements. For \"task complete\" or \"requirements met\" claims, also verify the deliverables against the original specification — line by line, not by assumption.\n\n## Common Failures\n\n| Claim                 | Requires                        | Not Sufficient                 |\n| --------------------- | ------------------------------- | ------------------------------ |\n| Tests pass            | Test command output: 0 failures | Previous run, \"should pass\"    |\n| Linter clean          | Linter output: 0 errors         | Partial check, extrapolation   |\n| Build succeeds        | Build command: exit 0           | Linter passing, logs look good |\n| Bug fixed             | Test original symptom: passes   | Code changed, assumed fixed    |\n| Regression test works | Red-green cycle verified        | Test passes once               |\n| Agent completed       | VCS diff shows changes          | Agent reports \"success\"        |\n| Requirements met      | Line-by-line checklist          | Tests passing                  |\n\n## Red Flags\n\n- Using \"should\", \"probably\", or \"seems to\"\n- Expressing satisfaction before verification\n- About to commit, push, or open a PR without verification\n- Trusting another agent's success report\n- Relying on partial verification\n- Thinking \"just this once\"\n- Any wording that implies success without current evidence\n\n## Rationalization Prevention\n\n| Excuse                                  | Reality                |\n| --------------------------------------- | ---------------------- |\n| \"Should work now\"                       | Run the verification   |\n| \"I'm confident\"                         | Confidence ≠ evidence  |\n| \"Just this once\"                        | No exceptions          |\n| \"Linter passed\"                         | Linter ≠ compiler      |\n| \"Agent said success\"                    | Verify independently   |\n| \"I'm tired\"                             | Exhaustion ≠ excuse    |\n| \"Partial check is enough\"               | Partial proves nothing |\n| \"Different words so rule doesn't apply\" | Spirit over letter     |\n\n## When To Apply\n\nApply this skill before:\n\n- any success or completion claim\n- any expression of satisfaction with the implementation state\n- any commit or PR creation\n- any handoff that implies correctness\n- moving to the next task based on completion\n\n## Pre-Commit and Pre-PR Gate\n\nCommits and PRs are permanent artifacts. They require the highest verification standard.\n\n**Before `git commit`:**\n1. Run the full verification pipeline (e.g., `make verify`). Not a subset. The full pipeline.\n2. Confirm zero errors, zero warnings, zero test failures in the output.\n3. Produce a Verification Report (see template below) with verdict PASS.\n4. Only then run `git commit`.\n\n**Before creating a PR:**\n1. All of the above, plus:\n2. Verify the diff matches the intended changes (`git diff` review).\n3. Confirm no unrelated files are staged.\n\nIf the full pipeline has not passed in this session after the last code change, the commit or PR must not proceed.\n\n## Verification Report Template\n\nVerification is not complete until the agent **cites actual command output** in their response. \"I ran it and it passed\" is not evidence. If the verification output is not shown, the verification did not happen.\n\nEvery verification must be reported using this structure. Do not deviate.\n\n```\nVERIFICATION REPORT\n-------------------\nClaim: [What is being claimed — e.g., \"tests pass\", \"build succeeds\", \"task complete\"]\nCommand: [Exact command run — e.g., `make verify`]\nExecuted: [Timestamp or \"just now, after all changes\"]\nExit code: [0 or non-zero]\nOutput summary: [Key lines from output — pass count, error count, build result]\nWarnings: [Any warnings, or \"none\"]\nErrors: [Any errors, or \"none\"]\nVerdict: PASS or FAIL\n```\n\nIf the verdict is FAIL, do not use completion language. State what failed and what remains.\n\nIf the verdict is PASS, the claim may proceed — but only the specific claim supported by the evidence. \"Tests pass\" does not mean \"build succeeds.\"\n\n## When Verification Fails\n\nVerification failure is not a dead end. It is information. Follow this protocol:\n\n1. **Read the failure.** Identify the exact error: which command failed, which test, which lint rule, which build error. Quote the relevant output lines.\n2. **Diagnose the root cause.** Do not guess. Read the error message. Trace it to the source. If multiple things failed, address them one at a time starting with the first failure.\n3. **Fix the root cause.** Apply the minimal change that addresses the actual error. Do not apply workarounds, suppress warnings, or skip checks.\n4. **Re-verify from scratch.** Run the full verification command again. Do not assume the fix worked. Do not run only the previously-failing subset.\n5. **Report with evidence.** Use the Verification Report Template. If it passes now, the claim may proceed. If it fails again, return to step 1.\n\n**Never:**\n- Claim partial success (\"3 of 4 checks pass, close enough\")\n- Skip re-verification after a fix (\"I fixed the error, so it should pass now\")\n- Blame the tooling (\"the linter is wrong\") without evidence of a false positive\n- Move on to the next task while verification is still failing\n\nIf the correct verification command is unclear, identify it before making any completion claim. If only partial verification is available, state that limitation explicitly and avoid completion language.\n",{"name":5,"description":7},"main","f177680a573a242a81bd0a776f9681f620e6d74c","skills\u002Ffinal-verify",0,"https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize","https:\u002F\u002Fgithub.com\u002Fitseffi","2026-08-07 20:07:32",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add itseffi\u002Fproductize --skill final-verify",{"tool":37,"command":38},"bunx","bunx skills add itseffi\u002Fproductize --skill final-verify",{"tool":40,"command":41},"pnpm","pnpm dlx skills add itseffi\u002Fproductize --skill final-verify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Ffinal-verify\u002FSKILL.md",true,[],[46,53,60,67,74,81],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7357QB5M87V95F82E73V2TF","workflow-memory","Maintains workflow-scoped task memory for Productize runs using .productize\u002Ftasks\u002F\u003Cname>\u002Fmemory\u002F files. Use when a task prompt provides workflow memory paths and requires the agent to read, update, compact, and promote durable context across PRD task executions. Do not use for PR review remediation, global user preferences, or programmatic event-log summarization.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-memory\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7357K97HSYEHAQTW5ZKM4CE","review-round","Performs a comprehensive code review of a PRD implementation and generates a review round directory with issue files compatible with fix-reviews. Use when reviewing implemented PRD tasks, creating a manual review round without an external provider, or performing a quality audit of code changes. Do not use for fetching reviews from external providers, fixing existing review issues, executing PRD tasks, or editing source code.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Freview-round\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7357F2NZE5NSYM2SJXEGBFZ","productize","Productize root skill for building, shipping, operating, and growing AI products inside a coding harness. Routes work across thesis framing, discovery, research, positioning, finance, decision making, requirements, design, metrics, AI-builder execution, code implementation, verification, stakeholder narratives, growth, launch, operation, and learning workflows. Use when the user wants to build a product from zero, improve an existing product, or needs product work that spans multiple lifecycle stages before code, launch, operation, or growth execution.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":19},"01M7357B48F8MK86EQF135FJQ6","productize-wwas","Why-What-Acceptance. Use when writing backlog items in Why-What-Acceptance format, breaking features into independent valuable work, or adding strategic context to delivery items.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize-wwas\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M735783CDA9MQ0SPR9X6QZSE","productize-writing-plans","Create comprehensive implementation plans with bite-sized tasks. Use when you have requirements before touching code.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize-writing-plans\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M735750V5Q6WRBX1ZFGNRMEB","productize-write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea into a structured document, scoping goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into phases.","https:\u002F\u002Fgithub.com\u002Fitseffi\u002Fproductize\u002Fblob\u002Fmain\u002Fskills\u002Fproductize-write-spec\u002FSKILL.md",[],[]]