[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7B3DP2RJS5MX9E2TW02XP7W":3,"skill-same:01M7B3DP2RJS5MX9E2TW02XP7W":74},{"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":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M7B3DP2RJS5MX9E2TW02XP7W","production-release-verification",null,"Verify immutable production releases.","merllinsbeard\u002Fmerlin-CTO","merllinsbeard","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F144795773?v=4","01M7B3C01C1PCBWFGB5T7YXSF8","merlin","01M7B3C023BBYDEPAPWBAGW9A7",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fdevops\u002Fproduction-release-verification\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: production-release-verification\ndescription: Verify immutable production releases.\nversion: 0.1.0\nauthor: Hermes Agent\nlicense: MIT\nplatforms: [linux, macos]\nmetadata:\n  hermes:\n    tags: [release, production, immutable-artifacts, canary, verification]\n    related_skills: [principle-prove-it-works, unlazy, github-issue-to-pr]\n---\n\n# Production release verification\n\nUse this skill when a change must move from merged source to a production artifact and a verified user-visible result. It exists to prevent the most common false finish: treating a green build, a merged PR, or a successful deploy command as proof that production serves the intended behavior.\n\n## The release state machine\n\nKeep these states separate in every report and issue thread:\n\n- **merged** — source revision is in the protected integration branch.\n- **released** — an immutable artifact was built, signed or attested, and its digest was verified.\n- **deployed** — production is running that exact artifact; read back the running revision.\n- **live-accepted** — the required user scenario passed against the running deployment.\n\nA later state implies the earlier ones only when the same immutable revision and artifact identity are carried through. Never collapse the four labels into “done”.\n\n## Procedure\n\n1. **Freeze identity.** Record the source revision, image digest or artifact ID, manifest path, and release receipt path. Use the same identity for every later command.\n2. **Run the complete candidate gate.** Include unit and integration tests, browser tests, typecheck\u002Flint, security scans, container\u002Ftopology checks, recovery, and rollback proof where the repository defines them. Record exact counts and exit status in durable evidence.\n3. **Repair findings at the root.** If a gate exposes a real defect, fix the class of defect, merge the fix, and rebuild. The old artifact is invalid even if its source is now corrected.\n4. **Publish evidence.** Sign or attest the release evidence and verify the signature. Create a private receipt that names the exact artifact and all acceptance gates.\n5. **Deploy the exact manifest.** Run the repository’s native deploy facade with explicit manifest, predeploy verdict, receipt, and environment. Then read back running image\u002Frevision, service health, and the deployment record.\n6. **Canary sequentially.** Keep gated capabilities disabled by default. Enable one capability, run its detached production canary and inspect logs\u002Fmetrics; restore or continue only after it passes. Repeat for the next capability, then run the combined acceptance scenario.\n7. **Verify the real user path.** Exercise the exact scenario named by the issue, not only health checks or API status. Confirm persistence\u002Freload, ownership, cleanup, accounting, and failure behavior when they are part of the contract.\n8. **Close the loop.** Comment the issue with revision, digest, evidence, and the highest verified state. Close it only when the acceptance criteria are live-accepted. If deployment stopped at an earlier state, say so plainly and leave the issue open.\n\n## Registry and receipt preconditions\n\nBefore a release build pushes to a registry, validate the active credential’s package-write permission and authenticate the container client explicitly. A denied push is a release precondition failure, not a reason to claim that a local build is an immutable release. Keep credentials out of logs and durable summaries.\n\n## Evidence standard\n\nPrefer deterministic scripts and repository-native release gates over prose. A valid handoff names:\n\n- immutable source revision;\n- artifact\u002Fimage digest;\n- signed evidence and verification result;\n- exact test counts and skipped suites;\n- running production revision after deploy;\n- canary and live-acceptance results;\n- rollback outcome or explicit remaining gate.\n\nFor a compact reusable checklist and receipt fields, see [`references\u002Frelease-proof-checklist.md`](references\u002Frelease-proof-checklist.md).\n\n## Pitfalls\n\n- Calling a signed candidate “deployed” before reading the running revision.\n- Calling a deployed service “accepted” because healthcheck and CI are green.\n- Reusing an artifact built before the final root-cause fix.\n- Enabling multiple risky capabilities together before individual canaries pass.\n- Closing the issue at merge or release when the user contract requires live production verification.\n- Reporting exact counts from memory instead of the test runner’s output.\n\n## Verification\n\nThe skill is applied correctly when the final report contains the four state labels, one immutable identity, direct evidence for each claimed transition, and an explicit next gate for any state not reached.\n","# Production release verification\n\nUse this skill when a change must move from merged source to a production artifact and a verified user-visible result. It exists to prevent the most common false finish: treating a green build, a merged PR, or a successful deploy command as proof that production serves the intended behavior.\n\n## The release state machine\n\nKeep these states separate in every report and issue thread:\n\n- **merged** — source revision is in the protected integration branch.\n- **released** — an immutable artifact was built, signed or attested, and its digest was verified.\n- **deployed** — production is running that exact artifact; read back the running revision.\n- **live-accepted** — the required user scenario passed against the running deployment.\n\nA later state implies the earlier ones only when the same immutable revision and artifact identity are carried through. Never collapse the four labels into “done”.\n\n## Procedure\n\n1. **Freeze identity.** Record the source revision, image digest or artifact ID, manifest path, and release receipt path. Use the same identity for every later command.\n2. **Run the complete candidate gate.** Include unit and integration tests, browser tests, typecheck\u002Flint, security scans, container\u002Ftopology checks, recovery, and rollback proof where the repository defines them. Record exact counts and exit status in durable evidence.\n3. **Repair findings at the root.** If a gate exposes a real defect, fix the class of defect, merge the fix, and rebuild. The old artifact is invalid even if its source is now corrected.\n4. **Publish evidence.** Sign or attest the release evidence and verify the signature. Create a private receipt that names the exact artifact and all acceptance gates.\n5. **Deploy the exact manifest.** Run the repository’s native deploy facade with explicit manifest, predeploy verdict, receipt, and environment. Then read back running image\u002Frevision, service health, and the deployment record.\n6. **Canary sequentially.** Keep gated capabilities disabled by default. Enable one capability, run its detached production canary and inspect logs\u002Fmetrics; restore or continue only after it passes. Repeat for the next capability, then run the combined acceptance scenario.\n7. **Verify the real user path.** Exercise the exact scenario named by the issue, not only health checks or API status. Confirm persistence\u002Freload, ownership, cleanup, accounting, and failure behavior when they are part of the contract.\n8. **Close the loop.** Comment the issue with revision, digest, evidence, and the highest verified state. Close it only when the acceptance criteria are live-accepted. If deployment stopped at an earlier state, say so plainly and leave the issue open.\n\n## Registry and receipt preconditions\n\nBefore a release build pushes to a registry, validate the active credential’s package-write permission and authenticate the container client explicitly. A denied push is a release precondition failure, not a reason to claim that a local build is an immutable release. Keep credentials out of logs and durable summaries.\n\n## Evidence standard\n\nPrefer deterministic scripts and repository-native release gates over prose. A valid handoff names:\n\n- immutable source revision;\n- artifact\u002Fimage digest;\n- signed evidence and verification result;\n- exact test counts and skipped suites;\n- running production revision after deploy;\n- canary and live-acceptance results;\n- rollback outcome or explicit remaining gate.\n\nFor a compact reusable checklist and receipt fields, see [`references\u002Frelease-proof-checklist.md`](references\u002Frelease-proof-checklist.md).\n\n## Pitfalls\n\n- Calling a signed candidate “deployed” before reading the running revision.\n- Calling a deployed service “accepted” because healthcheck and CI are green.\n- Reusing an artifact built before the final root-cause fix.\n- Enabling multiple risky capabilities together before individual canaries pass.\n- Closing the issue at merge or release when the user contract requires live production verification.\n- Reporting exact counts from memory instead of the test runner’s output.\n\n## Verification\n\nThe skill is applied correctly when the final report contains the four state labels, one immutable identity, direct evidence for each claimed transition, and an explicit next gate for any state not reached.\n",{"name":5,"author":24,"license":15,"version":25,"metadata":26,"platforms":38,"description":7},"Hermes Agent","0.1.0",{"hermes":27},{"tags":28,"related_skills":34},[29,30,31,32,33],"release","production","immutable-artifacts","canary","verification",[35,36,37],"principle-prove-it-works","unlazy","github-issue-to-pr",[39,40],"linux","macos","main","116bb09f1369e85cd8a54fec4135e218dca4a061","skills\u002Fdevops\u002Fproduction-release-verification",0,"https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Freleases\u002Flatest","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard","ai","2026-08-25 21:36:43",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add merllinsbeard\u002Fmerlin-CTO --skill production-release-verification",{"tool":56,"command":57},"bunx","bunx skills add merllinsbeard\u002Fmerlin-CTO --skill production-release-verification",{"tool":59,"command":60},"pnpm","pnpm dlx skills add merllinsbeard\u002Fmerlin-CTO --skill production-release-verification","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fdevops\u002Fproduction-release-verification\u002FSKILL.md",true,[64,70],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Frelease-proof-checklist.md","REFERENCE","参考文档",1400,"https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fdevops\u002Fproduction-release-verification\u002Freferences\u002Frelease-proof-checklist.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fsequential-canary-human-acceptance.md",1110,"https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fdevops\u002Fproduction-release-verification\u002Freferences\u002Fsequential-canary-human-acceptance.md",[75,82,89,96,103,110],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7B3SK15WA8JW4G6RBKZR3ME","writing-for-agents","Use for delegate_task, Kanban, and all agent-facing text.","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M7B3SD78DTTXFVXGDPRK7249","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fwhy\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"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":95,"publishedAt":19},"01M7B3S8ENS1XQ7YV3N5GV1PCF","vue-best-practices","Use for Vue 3, .vue files, Vue Router, or Pinia. Skip when the repo has no Vue.","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fweb-development\u002Fvue-best-practices\u002FSKILL.md",[],[],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":19},"01M7B3S2DPXMQN0EFFE8FTF03R","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fweb-development\u002Fvercel-react-best-practices\u002FSKILL.md",[],[],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":19},"01M7B3S06K4AGG5X59TCX900R6","tailwind-v4","Use when writing or reviewing Tailwind CSS v4 classes or migrating v3 syntax.","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fweb-development\u002Ftailwind-v4\u002FSKILL.md",[],[],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":19},"01M7B3RXNDDCPJ7K5303BXXDTV","react-best-practices","Mastra React subset only. Generic React or Next uses vercel-react-best-practices.","https:\u002F\u002Fgithub.com\u002Fmerllinsbeard\u002Fmerlin-CTO\u002Fblob\u002Fmain\u002Fskills\u002Fweb-development\u002Freact-best-practices\u002FSKILL.md",[],[]]