[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BV0DKA882QCKRQXHTVB4Y1":3,"skill-same:01M6BV0DKA882QCKRQXHTVB4Y1":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":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":73},"01M6BV0DKA882QCKRQXHTVB4Y1","deploy-validate",null,"Validate a deploy after it lands — CI status, rollout health, error tracking, and monitoring\u002Falerting — correlating every finding against the deploy's start time to separate genuine regressions from pre-existing noise. Use when asked to validate a deploy, check post-deploy health, confirm a production rollout is healthy, or after a deploy finishes.","drn\u002Fdots","drn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F885841?v=4","01M6BTZJR7B1RVQRJKP0S70DQS","Darren Cheng","01M6BTZJWXCK41P3Z50BV8KWD9",23,"MIT","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fdeploy-validate\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"deploy","deploy validate","validate","check","when","Existing","true","error","post","healthy","time","error tracking","rollout","use","ci status","health","Production","start","ci","monitoring","alerting","status","2026-11-10 10:12:30",false,"---\nname: deploy-validate\ndescription: Validate a deploy after it lands — CI status, rollout health, error tracking, and monitoring\u002Falerting — correlating every finding against the deploy's start time to separate genuine regressions from pre-existing noise. Use when asked to validate a deploy, check post-deploy health, confirm a production rollout is healthy, or after a deploy finishes.\ndisable-model-invocation: true\n---\n\n# Post-Deploy Health Validation\n\nValidate that a deploy that has just landed is healthy: confirm it actually\nshipped what was intended, then check CI, rollout, error tracking, and\nmonitoring — correlating every finding's timing against the deploy's start so\npre-existing issues are not mistaken for regressions.\n\nRun this after the user confirms the deploy has finished (this skill does not\npoll or wait for a deploy in progress).\n\n## Arguments\n\n- `$ARGUMENTS` - Optional: the deployed branch\u002Ftag\u002Fref, and\u002For a deploy start\n  timestamp. If omitted, detect the deployed ref the same way `deploy-audit`\n  would and derive the start time from the deploy pipeline itself in Step 2.\n\n## Context\n\n- Remote: !`git remote get-url origin 2>\u002Fdev\u002Fnull | head -1`\n- Default branch: !`git branch -r 2>\u002Fdev\u002Fnull | grep -oE 'origin\u002F(main|master)' | head -1`\n- Current HEAD: !`git rev-parse --short HEAD 2>\u002Fdev\u002Fnull | head -1`\n- Latest tag: !`git describe --tags --abbrev=0 2>\u002Fdev\u002Fnull | head -1`\n\n## Instructions\n\nWork through the following steps in order — the timestamp correlation in\nStep 4 is what makes this validation trustworthy rather than a generic\nhealth-check dashboard.\n\n### Step 1: Confirm the deploy landed\n\nDetermine the deployed ref (from `$ARGUMENTS` or by asking, mirroring\n`deploy-audit`'s ref detection). Refs are treated as untrusted input for\nshell purposes: if a ref contains characters outside `[A-Za-z0-9._\u002F-]`, do\nnot interpolate it directly into a shell command — quote it and confirm with\nthe user first.\n\nFetch it and confirm it now points at the\ncommit\u002Ftag that was intended to ship — e.g. the deployed branch's SHA matches\nthe base branch's SHA at the time of the deploy, or a release tag was created\nat the expected commit.\n\nIf the deployed ref does not match what was expected, stop and report this\nfirst — nothing downstream matters if the wrong thing shipped.\n\n### Step 2: Find the deploy pipeline and its start time\n\nUse ToolSearch to find whatever CI\u002Fdeploy tooling is available in this\nproject (search terms like \"circleci\", \"github actions\", \"pipeline\",\n\"deploy\"). Find the pipeline\u002Fworkflow run that performed this deploy and\nrecord:\n\n- Its status (success\u002Ffailure\u002Fin-progress)\n- Its start timestamp — this is the anchor for every correlation in later\n  steps\n\nIf no CI tooling is discoverable, ask the user for the deploy start time\ndirectly rather than guessing.\n\n### Step 3: Check rollout health\n\nUse ToolSearch for whatever deployment\u002Forchestration platform the project\nuses (e.g. terms like \"ecs\", \"kubernetes\", \"k8s\", \"cloud run\", \"deployment\").\nFor each service touched by the deploy, check:\n\n- Running\u002Fhealthy instance count matches desired count, with none pending\n- The running image\u002Fversion tag matches the new release\n\nQuery narrowly — one service at a time — rather than enumerating an entire\ncluster in one call; a large cluster's full service list can exceed usable\noutput size. If a query risks returning a large amount of data, delegate the\nenumeration to a subagent\u002Ffork and have it return only the summary.\n\n### Step 4: Check error tracking, correlated by time\n\nUse ToolSearch for whatever error-tracking tool is available (e.g. terms like\n\"sentry\", \"error tracking\", \"exception\"). Query for issues first seen in a\nwindow starting shortly before the deploy and continuing to now.\n\nFor every issue found, compare its first-seen timestamp against the deploy\nstart timestamp from Step 2:\n\n- **First seen before deploy start** → pre-existing noise, not a regression,\n  regardless of how alarming the error looks. Do not report it as caused by\n  this deploy.\n- **First seen at or after deploy start** → candidate regression. Investigate\n  further (stack trace, affected endpoint\u002Fservice) and include it in the\n  report.\n\nThis timestamp correlation is the single most important step in this skill —\ndo not substitute keyword matching or severity alone for it.\n\n### Step 5: Check monitoring and alerting, cross-checked against aggregates\n\nUse ToolSearch for whatever monitoring\u002Falerting tool is available (e.g. terms\nlike \"datadog\", \"monitor\", \"alert\", \"metrics\"). Find anything in an alerting\nstate for the affected service(s) since the deploy.\n\nBefore reporting an alert as a confirmed regression, cross-check it against\nthe underlying aggregate metric (e.g. error rate, latency) for the same\nservice and time window. A monitor tripping does not always mean a real\nregression — percentile and anomaly-detection monitors can trip on a single\noutlier. Only report it as a likely regression if the aggregate metric itself\nshows a corresponding shift after the deploy start time; otherwise note the\ndiscrepancy.\n\n### Step 6: Re-verify flagged risks\n\nIf a prior `deploy-audit` pass flagged any new feature flags or config risks\nfor this deploy, re-check those specific items now that the deploy is live\n(e.g. confirm a flag is still at its intended default). Skip this step if no\nprior audit findings are available.\n\n### Step 7: Report\n\nSummarize:\n\n```\n## Deploy Validation Report\n\n**Deployed ref:** \u003Cref> (matches expected: yes\u002Fno)\n**Deploy pipeline:** \u003Cstatus>, started \u003Ctimestamp>\n\n### Rollout\n\u003Cper-service health>\n\n### Error Tracking\n- Pre-existing (filtered out): \u003Ccount>\n- Candidate regressions (first seen after deploy): \u003Clist with detail>\n\n### Monitoring\n- Alerts confirmed against aggregate metrics: \u003Clist>\n- Alerts noted but not corroborated by aggregates: \u003Clist>\n\n### Flags\n\u003Cre-verified risk items, if any>\n\n### Unverified categories\n\u003Cany category skipped because no tooling was discoverable>\n\n### Recommendation\n\u003Cpropose remediation only for genuine, deploy-caused findings; explicitly\nstate when the deploy looks healthy>\n```\n\nDo not propose remediation for anything classified as pre-existing noise.\n","# Post-Deploy Health Validation\n\nValidate that a deploy that has just landed is healthy: confirm it actually\nshipped what was intended, then check CI, rollout, error tracking, and\nmonitoring — correlating every finding's timing against the deploy's start so\npre-existing issues are not mistaken for regressions.\n\nRun this after the user confirms the deploy has finished (this skill does not\npoll or wait for a deploy in progress).\n\n## Arguments\n\n- `$ARGUMENTS` - Optional: the deployed branch\u002Ftag\u002Fref, and\u002For a deploy start\n  timestamp. If omitted, detect the deployed ref the same way `deploy-audit`\n  would and derive the start time from the deploy pipeline itself in Step 2.\n\n## Context\n\n- Remote: !`git remote get-url origin 2>\u002Fdev\u002Fnull | head -1`\n- Default branch: !`git branch -r 2>\u002Fdev\u002Fnull | grep -oE 'origin\u002F(main|master)' | head -1`\n- Current HEAD: !`git rev-parse --short HEAD 2>\u002Fdev\u002Fnull | head -1`\n- Latest tag: !`git describe --tags --abbrev=0 2>\u002Fdev\u002Fnull | head -1`\n\n## Instructions\n\nWork through the following steps in order — the timestamp correlation in\nStep 4 is what makes this validation trustworthy rather than a generic\nhealth-check dashboard.\n\n### Step 1: Confirm the deploy landed\n\nDetermine the deployed ref (from `$ARGUMENTS` or by asking, mirroring\n`deploy-audit`'s ref detection). Refs are treated as untrusted input for\nshell purposes: if a ref contains characters outside `[A-Za-z0-9._\u002F-]`, do\nnot interpolate it directly into a shell command — quote it and confirm with\nthe user first.\n\nFetch it and confirm it now points at the\ncommit\u002Ftag that was intended to ship — e.g. the deployed branch's SHA matches\nthe base branch's SHA at the time of the deploy, or a release tag was created\nat the expected commit.\n\nIf the deployed ref does not match what was expected, stop and report this\nfirst — nothing downstream matters if the wrong thing shipped.\n\n### Step 2: Find the deploy pipeline and its start time\n\nUse ToolSearch to find whatever CI\u002Fdeploy tooling is available in this\nproject (search terms like \"circleci\", \"github actions\", \"pipeline\",\n\"deploy\"). Find the pipeline\u002Fworkflow run that performed this deploy and\nrecord:\n\n- Its status (success\u002Ffailure\u002Fin-progress)\n- Its start timestamp — this is the anchor for every correlation in later\n  steps\n\nIf no CI tooling is discoverable, ask the user for the deploy start time\ndirectly rather than guessing.\n\n### Step 3: Check rollout health\n\nUse ToolSearch for whatever deployment\u002Forchestration platform the project\nuses (e.g. terms like \"ecs\", \"kubernetes\", \"k8s\", \"cloud run\", \"deployment\").\nFor each service touched by the deploy, check:\n\n- Running\u002Fhealthy instance count matches desired count, with none pending\n- The running image\u002Fversion tag matches the new release\n\nQuery narrowly — one service at a time — rather than enumerating an entire\ncluster in one call; a large cluster's full service list can exceed usable\noutput size. If a query risks returning a large amount of data, delegate the\nenumeration to a subagent\u002Ffork and have it return only the summary.\n\n### Step 4: Check error tracking, correlated by time\n\nUse ToolSearch for whatever error-tracking tool is available (e.g. terms like\n\"sentry\", \"error tracking\", \"exception\"). Query for issues first seen in a\nwindow starting shortly before the deploy and continuing to now.\n\nFor every issue found, compare its first-seen timestamp against the deploy\nstart timestamp from Step 2:\n\n- **First seen before deploy start** → pre-existing noise, not a regression,\n  regardless of how alarming the error looks. Do not report it as caused by\n  this deploy.\n- **First seen at or after deploy start** → candidate regression. Investigate\n  further (stack trace, affected endpoint\u002Fservice) and include it in the\n  report.\n\nThis timestamp correlation is the single most important step in this skill —\ndo not substitute keyword matching or severity alone for it.\n\n### Step 5: Check monitoring and alerting, cross-checked against aggregates\n\nUse ToolSearch for whatever monitoring\u002Falerting tool is available (e.g. terms\nlike \"datadog\", \"monitor\", \"alert\", \"metrics\"). Find anything in an alerting\nstate for the affected service(s) since the deploy.\n\nBefore reporting an alert as a confirmed regression, cross-check it against\nthe underlying aggregate metric (e.g. error rate, latency) for the same\nservice and time window. A monitor tripping does not always mean a real\nregression — percentile and anomaly-detection monitors can trip on a single\noutlier. Only report it as a likely regression if the aggregate metric itself\nshows a corresponding shift after the deploy start time; otherwise note the\ndiscrepancy.\n\n### Step 6: Re-verify flagged risks\n\nIf a prior `deploy-audit` pass flagged any new feature flags or config risks\nfor this deploy, re-check those specific items now that the deploy is live\n(e.g. confirm a flag is still at its intended default). Skip this step if no\nprior audit findings are available.\n\n### Step 7: Report\n\nSummarize:\n\n```\n## Deploy Validation Report\n\n**Deployed ref:** \u003Cref> (matches expected: yes\u002Fno)\n**Deploy pipeline:** \u003Cstatus>, started \u003Ctimestamp>\n\n### Rollout\n\u003Cper-service health>\n\n### Error Tracking\n- Pre-existing (filtered out): \u003Ccount>\n- Candidate regressions (first seen after deploy): \u003Clist with detail>\n\n### Monitoring\n- Alerts confirmed against aggregate metrics: \u003Clist>\n- Alerts noted but not corroborated by aggregates: \u003Clist>\n\n### Flags\n\u003Cre-verified risk items, if any>\n\n### Unverified categories\n\u003Cany category skipped because no tooling was discoverable>\n\n### Recommendation\n\u003Cpropose remediation only for genuine, deploy-caused findings; explicitly\nstate when the deploy looks healthy>\n```\n\nDo not propose remediation for anything classified as pre-existing noise.\n",{"name":5,"description":7,"disable-model-invocation":51},true,"master","427f62a9fc82624977516767979411f885161ac5","agents\u002Fskills\u002Fdeploy-validate",4,"https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots","https:\u002F\u002Fgithub.com\u002Fdrn","https:\u002F\u002Fdrn.dev","CTO & Co-Founder @thanx","2026-11-12 16:13:13",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":51},[63,66,69],{"tool":64,"command":65},"npx","npx skills add drn\u002Fdots --skill deploy-validate",{"tool":67,"command":68},"bunx","bunx skills add drn\u002Fdots --skill deploy-validate",{"tool":70,"command":71},"pnpm","pnpm dlx skills add drn\u002Fdots --skill deploy-validate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fdeploy-validate\u002FSKILL.md",[],[75,104,124,136,160,178],{"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":84,"publishedAt":46},"01M70KJSG2P5Y3N95MGSGKJ8VA","batch-pr-review","Review a batch of pull requests together, describe every change in plain language, and build a private Claude artifact that eases human review, with a severity-tagged and verified findings list. Use when asked to review several PRs, a stack of PRs, PRs listed in a Slack thread or message, or to summarize a batch of PRs for a reviewer.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fbatch-pr-review\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",[85,86,87,88,89,90,28,91,92,93,94,95,96,97,98,99,100,101,102,103],"batch pr review","batch","pr","pr review","review","reviewer","parse","scripts","human","artifact","message","write","read","stack","gh pr","Bash","change","pull requests","slack",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":113,"publishedAt":46},"01M6BV2G3ZAS76C40S3YBY6R61","plannotator-setup-goal","Create reviewed Codex goal setup packages for long-running \u002Fgoal work. Use when the user wants to turn an idea, backlog, project mission, or vague objective into durable goal files under a project goals slug folder, with Plannotator review gates for brief, narrative plan with acceptance criteria, verification, blockers, and the final \u002Fgoal prompt.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fplannotator-setup-goal\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[114,115,116,117,118,119,120,121,122,123,89],"plannotator setup goal","setup","verification","plan","plannotator review","brief","acceptance","create","packages","codex",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":46},"01M6BV26Y6GTDMQZYXFRWKEC08","plannotator-annotate","Open Plannotator's annotation UI for a markdown file, converted HTML file, URL, or folder and then respond to the returned annotations.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fplannotator-annotate\u002FSKILL.md",[],[131,132,133,134,135],"plannotator annotate","markdown","open","ui","file",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":46},"01M6BV44RGGTRRFGWMYCR3BQ1P","write-skill","Create or improve a Claude Code skill\u002Fslash command with best practices for structure, dynamic context, and safety. Use for creating new skills, improving existing ones, or learning skill authoring.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fwrite-skill\u002FSKILL.md",[142],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},[96,144,145,146,147,148,149,150,151,37,152,153,154,155,156,157,29,158,159,121],"write skill","with","authoring","code skill","code","for","structure","claude code skill","context","command","improve","learning","Safety","best practices","new","skill authoring",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":46},"01M6BV4390BFK30F1T51SAJPAV","wrapup","End-of-session checklist that detects loose ends — uncommitted changes, unmerged branches, learnings to capture, handoffs needed — and routes to the right skills. Use for session closeout, wrapping up, end of day, or \"anything else to capture\".","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Fwrapup\u002FSKILL.md",[],[162,167,168,169,149,170,171,172,173,174,37,175,176,177],"session closeout","up","changes","end of day","end","branches","learnings","checklist","session","closeout","capture",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":46},"01M6BV41ZZ051JX2B3CB5WARZM","tts","Read text aloud using text-to-speech. Use when the user says \"speak to me\", \"read to me\", \"read this aloud\", \"say this\", \"speak the summary\", or asks to hear something spoken.","https:\u002F\u002Fgithub.com\u002Fdrn\u002Fdots\u002Fblob\u002Fmaster\u002Fagents\u002Fskills\u002Ftts\u002FSKILL.md",[],[180,37,185,97,186,187,188,189,28,190,191,192],"user","speak","text","speech","say","text-to-speech","me","summary"]