[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D100F2CQKNFHP67GS1R81P":3,"skill-same:01M6D100F2CQKNFHP67GS1R81P":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6D100F2CQKNFHP67GS1R81P","github-pr-merge",null,"Review and squash-merge open GitHub PRs one by one via `gh`, user deciding each. Use when user wants to review, triage, or merge open PRs, including PRs `self-improve` opened. Args `[\u003Cpr#>] [-R \u003Cowner\u002Frepo>]`.","JinsYin\u002Fskills","JinsYin","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F12714609?v=4","01M6D0YYKCF1MT47KYYZSXWE30","01M6D0YYQ1F5AG45M6ATPECCAW",1,"MIT","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fgithub-pr-merge\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"github","merge","pr","pr merge","github pr merge","github pr","when","review","prs","via","self","use","user","repo","gh","squash","improve","open","triage","2026-11-10 10:12:30",false,"---\nname: shipping-and-launch\ndescription: Prepares production launches. Use when preparing to deploy to production.\n  Use when you need a pre-launch checklist, when setting up monitoring, when planning\n  a staged rollout, or when you need a rollback strategy.\n---\n\n# Shipping and Launch\n\n## Overview\n\nShip with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.\n\n## When to Use\n\n- Deploying a feature to production for the first time\n- Releasing a significant change to users\n- Migrating data or infrastructure\n- Opening a beta or early access program\n- Any deployment that carries risk (all of them)\n\n## The Pre-Launch Checklist\n\n### Code Quality\n\n- [ ] All tests pass (unit, integration, e2e)\n- [ ] Build succeeds; every warning is investigated and either resolved or explicitly accepted by the user\n- [ ] Lint and type checking pass\n- [ ] Code reviewed and approved\n- [ ] No TODO comments that should be resolved before launch\n- [ ] No `console.log` debugging statements in production code\n- [ ] Error handling covers expected failure modes\n\n### Security\n\n- [ ] No secrets in code or version control\n- [ ] `npm audit` shows no critical or high vulnerabilities\n- [ ] Input validation on all user-facing endpoints\n- [ ] Authentication and authorization checks in place\n- [ ] Security headers configured (CSP, HSTS, etc.)\n- [ ] Rate limiting on authentication endpoints\n- [ ] CORS configured to specific origins (not wildcard)\n\n### Performance\n\n- [ ] Core Web Vitals within \"Good\" thresholds\n- [ ] No N+1 queries in critical paths\n- [ ] Images optimized (compression, responsive sizes, lazy loading)\n- [ ] Bundle size within budget\n- [ ] Database queries have appropriate indexes\n- [ ] Caching configured for static assets and repeated queries\n\n### Accessibility\n\n- [ ] Keyboard navigation works for all interactive elements\n- [ ] Screen reader can convey page content and structure\n- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text)\n- [ ] Focus management correct for modals and dynamic content\n- [ ] Error messages are descriptive and associated with form fields\n- [ ] Every accessibility warning from axe-core or Lighthouse is investigated and resolved or explicitly accepted\n\n### Infrastructure\n\n- [ ] Environment variables set in production\n- [ ] Database migrations applied (or ready to apply)\n- [ ] DNS and SSL configured\n- [ ] CDN configured for static assets\n- [ ] Logging and error reporting configured\n- [ ] Health check endpoint exists and responds\n\n### Documentation\n\n- [ ] README updated with any new setup requirements\n- [ ] API documentation current\n- [ ] ADRs written for any architectural decisions\n- [ ] Changelog updated\n- [ ] User-facing documentation updated (if applicable)\n\n## Feature Flag Strategy\n\nShip behind feature flags to decouple deployment from release:\n\n```typescript\n\u002F\u002F Feature flag check\nconst flags = await getFeatureFlags(userId);\n\nif (flags.taskSharing) {\n  \u002F\u002F New feature: task sharing\n  return \u003CTaskSharingPanel task={task} \u002F>;\n}\n\n\u002F\u002F Default: existing behavior\nreturn null;\n```\n\n**Feature flag lifecycle:**\n\n```\n1. DEPLOY with flag OFF     → Code is in production but inactive\n2. ENABLE for team\u002Fbeta     → Internal testing in production environment\n3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users\n4. MONITOR at each stage    → Watch error rates, performance, user feedback\n5. CLEAN UP                 → Remove flag and dead code path after full rollout\n```\n\n**Rules:**\n- Every feature flag has an owner and an expiration date\n- Clean up flags within 2 weeks of full rollout\n- Don't nest feature flags (creates exponential combinations)\n- Test both flag states (on and off) in CI\n\n## Staged Rollout\n\n### The Rollout Sequence\n\n```\n1. DEPLOY to staging\n   └── Full test suite in staging environment\n   └── Manual smoke test of critical flows\n\n2. DEPLOY to production (feature flag OFF)\n   └── Verify deployment succeeded (health check)\n   └── Check error monitoring (no new errors)\n\n3. ENABLE for team (flag ON for internal users)\n   └── Team uses the feature in production\n   └── 24-hour monitoring window\n\n4. CANARY rollout (flag ON for 5% of users)\n   └── Monitor error rates, latency, user behavior\n   └── Compare metrics: canary vs. baseline\n   └── 24-48 hour monitoring window\n   └── Advance only if all thresholds pass (see table below)\n\n5. GRADUAL increase (25% -> 50% -> 100%)\n   └── Same monitoring at each step\n   └── Ability to roll back to previous percentage at any point\n\n6. FULL rollout (flag ON for all users)\n   └── Monitor for 1 week\n   └── Clean up feature flag\n```\n\n### Rollout Decision Thresholds\n\nUse these thresholds to decide whether to advance, hold, or roll back at each stage:\n\n| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) |\n|--------|-----------------|-------------------------------|-----------------|\n| Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline |\n| P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline |\n| Client JS errors | No new error types | New errors at \u003C0.1% of sessions | New errors at >0.1% of sessions |\n| Business metrics | Neutral or positive | Decline \u003C5% (may be noise) | Decline >5% |\n\n### When to Roll Back\n\nRoll back immediately if:\n- Error rate increases by more than 2x baseline\n- P95 latency increases by more than 50%\n- User-reported issues spike\n- Data integrity issues detected\n- Security vulnerability discovered\n\n## Monitoring and Observability\n\n### What to Monitor\n\n```\nApplication metrics:\n├── Error rate (total and by endpoint)\n├── Response time (p50, p95, p99)\n├── Request volume\n├── Active users\n└── Key business metrics (conversion, engagement)\n\nInfrastructure metrics:\n├── CPU and memory utilization\n├── Database connection pool usage\n├── Disk space\n├── Network latency\n└── Queue depth (if applicable)\n\nClient metrics:\n├── Core Web Vitals (LCP, INP, CLS)\n├── JavaScript errors\n├── API error rates from client perspective\n└── Page load time\n```\n\n### Error Reporting\n\n```typescript\n\u002F\u002F Set up error boundary with reporting\nclass ErrorBoundary extends React.Component {\n  componentDidCatch(error: Error, info: React.ErrorInfo) {\n    \u002F\u002F Report to error tracking service\n    reportError(error, {\n      componentStack: info.componentStack,\n      userId: getCurrentUser()?.id,\n      page: window.location.pathname,\n    });\n  }\n\n  render() {\n    if (this.state.hasError) {\n      return \u003CErrorFallback onRetry={() => this.setState({ hasError: false })} \u002F>;\n    }\n    return this.props.children;\n  }\n}\n\n\u002F\u002F Server-side error reporting\napp.use((err: Error, req: Request, res: Response, next: NextFunction) => {\n  reportError(err, {\n    method: req.method,\n    url: req.url,\n    userId: req.user?.id,\n  });\n\n  \u002F\u002F Don't expose internals to users\n  res.status(500).json({\n    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },\n  });\n});\n```\n\n### Post-Launch Verification\n\nIn the first hour after launch:\n\n```\n1. Check health endpoint returns 200\n2. Check error monitoring dashboard (no new error types)\n3. Check latency dashboard (no regression)\n4. Test the critical user flow manually\n5. Verify logs are flowing and readable\n6. Confirm rollback mechanism works (dry run if possible)\n```\n\n## Rollback Strategy\n\nEvery deployment needs a rollback plan before it happens:\n\n```markdown\n## Rollback Plan for [Feature\u002FRelease]\n\n### Trigger Conditions\n- Error rate > 2x baseline\n- P95 latency > [X]ms\n- User reports of [specific issue]\n\n### Rollback Steps\n1. Disable feature flag (if applicable)\n   OR\n1. Deploy previous version: `git revert \u003Ccommit> && git push`\n2. Verify rollback: health check, error monitoring\n3. Communicate: notify team of rollback\n\n### Database Considerations\n- Migration [X] has a rollback through the repository-declared tool: `npm exec -- prisma migrate rollback`\n- Data inserted by new feature: [preserved \u002F cleaned up]\n\n### Time to Rollback\n- Feature flag: \u003C 1 minute\n- Redeploy previous version: \u003C 5 minutes\n- Database rollback: \u003C 15 minutes\n```\n## See Also\n\n- For security pre-launch checks, see the `security-and-hardening` skill\n- For performance pre-launch checks, see the `performance-optimization` skill\n- For accessibility verification before launch, see the `frontend-ui-engineering` skill\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"It works in staging, it'll work in production\" | Production has different data, traffic patterns, and edge cases. Monitor after deploy. |\n| \"We don't need feature flags for this\" | Every feature benefits from a kill switch. Even \"simple\" changes can break things. |\n| \"Monitoring is overhead\" | Not having monitoring means you discover problems from user complaints instead of dashboards. |\n| \"We'll add monitoring later\" | Add it before launch. You can't debug what you can't see. |\n| \"Rolling back is admitting failure\" | Rolling back is responsible engineering. Shipping a broken feature is the failure. |\n\n## Red Flags\n\n- Deploying without a rollback plan\n- No monitoring or error reporting in production\n- Big-bang releases (everything at once, no staging)\n- Feature flags with no expiration or owner\n- No one monitoring the deploy for the first hour\n- Production environment configuration done by memory, not code\n- \"It's Friday afternoon, let's ship it\"\n\n## Verification\n\nBefore deploying:\n\n- [ ] Pre-launch checklist completed (all sections green)\n- [ ] Feature flag configured (if applicable)\n- [ ] Rollback plan documented\n- [ ] Monitoring dashboards set up\n- [ ] Team notified of deployment\n\nAfter deploying:\n\n- [ ] Health check returns 200\n- [ ] Error rate is normal\n- [ ] Latency is normal\n- [ ] Critical user flow works\n- [ ] Logs are flowing\n- [ ] Rollback tested or verified ready\n","# Shipping and Launch\n\n## Overview\n\nShip with confidence. The goal is not just to deploy — it's to deploy safely, with monitoring in place, a rollback plan ready, and a clear understanding of what success looks like. Every launch should be reversible, observable, and incremental.\n\n## When to Use\n\n- Deploying a feature to production for the first time\n- Releasing a significant change to users\n- Migrating data or infrastructure\n- Opening a beta or early access program\n- Any deployment that carries risk (all of them)\n\n## The Pre-Launch Checklist\n\n### Code Quality\n\n- [ ] All tests pass (unit, integration, e2e)\n- [ ] Build succeeds; every warning is investigated and either resolved or explicitly accepted by the user\n- [ ] Lint and type checking pass\n- [ ] Code reviewed and approved\n- [ ] No TODO comments that should be resolved before launch\n- [ ] No `console.log` debugging statements in production code\n- [ ] Error handling covers expected failure modes\n\n### Security\n\n- [ ] No secrets in code or version control\n- [ ] `npm audit` shows no critical or high vulnerabilities\n- [ ] Input validation on all user-facing endpoints\n- [ ] Authentication and authorization checks in place\n- [ ] Security headers configured (CSP, HSTS, etc.)\n- [ ] Rate limiting on authentication endpoints\n- [ ] CORS configured to specific origins (not wildcard)\n\n### Performance\n\n- [ ] Core Web Vitals within \"Good\" thresholds\n- [ ] No N+1 queries in critical paths\n- [ ] Images optimized (compression, responsive sizes, lazy loading)\n- [ ] Bundle size within budget\n- [ ] Database queries have appropriate indexes\n- [ ] Caching configured for static assets and repeated queries\n\n### Accessibility\n\n- [ ] Keyboard navigation works for all interactive elements\n- [ ] Screen reader can convey page content and structure\n- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for text)\n- [ ] Focus management correct for modals and dynamic content\n- [ ] Error messages are descriptive and associated with form fields\n- [ ] Every accessibility warning from axe-core or Lighthouse is investigated and resolved or explicitly accepted\n\n### Infrastructure\n\n- [ ] Environment variables set in production\n- [ ] Database migrations applied (or ready to apply)\n- [ ] DNS and SSL configured\n- [ ] CDN configured for static assets\n- [ ] Logging and error reporting configured\n- [ ] Health check endpoint exists and responds\n\n### Documentation\n\n- [ ] README updated with any new setup requirements\n- [ ] API documentation current\n- [ ] ADRs written for any architectural decisions\n- [ ] Changelog updated\n- [ ] User-facing documentation updated (if applicable)\n\n## Feature Flag Strategy\n\nShip behind feature flags to decouple deployment from release:\n\n```typescript\n\u002F\u002F Feature flag check\nconst flags = await getFeatureFlags(userId);\n\nif (flags.taskSharing) {\n  \u002F\u002F New feature: task sharing\n  return \u003CTaskSharingPanel task={task} \u002F>;\n}\n\n\u002F\u002F Default: existing behavior\nreturn null;\n```\n\n**Feature flag lifecycle:**\n\n```\n1. DEPLOY with flag OFF     → Code is in production but inactive\n2. ENABLE for team\u002Fbeta     → Internal testing in production environment\n3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users\n4. MONITOR at each stage    → Watch error rates, performance, user feedback\n5. CLEAN UP                 → Remove flag and dead code path after full rollout\n```\n\n**Rules:**\n- Every feature flag has an owner and an expiration date\n- Clean up flags within 2 weeks of full rollout\n- Don't nest feature flags (creates exponential combinations)\n- Test both flag states (on and off) in CI\n\n## Staged Rollout\n\n### The Rollout Sequence\n\n```\n1. DEPLOY to staging\n   └── Full test suite in staging environment\n   └── Manual smoke test of critical flows\n\n2. DEPLOY to production (feature flag OFF)\n   └── Verify deployment succeeded (health check)\n   └── Check error monitoring (no new errors)\n\n3. ENABLE for team (flag ON for internal users)\n   └── Team uses the feature in production\n   └── 24-hour monitoring window\n\n4. CANARY rollout (flag ON for 5% of users)\n   └── Monitor error rates, latency, user behavior\n   └── Compare metrics: canary vs. baseline\n   └── 24-48 hour monitoring window\n   └── Advance only if all thresholds pass (see table below)\n\n5. GRADUAL increase (25% -> 50% -> 100%)\n   └── Same monitoring at each step\n   └── Ability to roll back to previous percentage at any point\n\n6. FULL rollout (flag ON for all users)\n   └── Monitor for 1 week\n   └── Clean up feature flag\n```\n\n### Rollout Decision Thresholds\n\nUse these thresholds to decide whether to advance, hold, or roll back at each stage:\n\n| Metric | Advance (green) | Hold and investigate (yellow) | Roll back (red) |\n|--------|-----------------|-------------------------------|-----------------|\n| Error rate | Within 10% of baseline | 10-100% above baseline | >2x baseline |\n| P95 latency | Within 20% of baseline | 20-50% above baseline | >50% above baseline |\n| Client JS errors | No new error types | New errors at \u003C0.1% of sessions | New errors at >0.1% of sessions |\n| Business metrics | Neutral or positive | Decline \u003C5% (may be noise) | Decline >5% |\n\n### When to Roll Back\n\nRoll back immediately if:\n- Error rate increases by more than 2x baseline\n- P95 latency increases by more than 50%\n- User-reported issues spike\n- Data integrity issues detected\n- Security vulnerability discovered\n\n## Monitoring and Observability\n\n### What to Monitor\n\n```\nApplication metrics:\n├── Error rate (total and by endpoint)\n├── Response time (p50, p95, p99)\n├── Request volume\n├── Active users\n└── Key business metrics (conversion, engagement)\n\nInfrastructure metrics:\n├── CPU and memory utilization\n├── Database connection pool usage\n├── Disk space\n├── Network latency\n└── Queue depth (if applicable)\n\nClient metrics:\n├── Core Web Vitals (LCP, INP, CLS)\n├── JavaScript errors\n├── API error rates from client perspective\n└── Page load time\n```\n\n### Error Reporting\n\n```typescript\n\u002F\u002F Set up error boundary with reporting\nclass ErrorBoundary extends React.Component {\n  componentDidCatch(error: Error, info: React.ErrorInfo) {\n    \u002F\u002F Report to error tracking service\n    reportError(error, {\n      componentStack: info.componentStack,\n      userId: getCurrentUser()?.id,\n      page: window.location.pathname,\n    });\n  }\n\n  render() {\n    if (this.state.hasError) {\n      return \u003CErrorFallback onRetry={() => this.setState({ hasError: false })} \u002F>;\n    }\n    return this.props.children;\n  }\n}\n\n\u002F\u002F Server-side error reporting\napp.use((err: Error, req: Request, res: Response, next: NextFunction) => {\n  reportError(err, {\n    method: req.method,\n    url: req.url,\n    userId: req.user?.id,\n  });\n\n  \u002F\u002F Don't expose internals to users\n  res.status(500).json({\n    error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' },\n  });\n});\n```\n\n### Post-Launch Verification\n\nIn the first hour after launch:\n\n```\n1. Check health endpoint returns 200\n2. Check error monitoring dashboard (no new error types)\n3. Check latency dashboard (no regression)\n4. Test the critical user flow manually\n5. Verify logs are flowing and readable\n6. Confirm rollback mechanism works (dry run if possible)\n```\n\n## Rollback Strategy\n\nEvery deployment needs a rollback plan before it happens:\n\n```markdown\n## Rollback Plan for [Feature\u002FRelease]\n\n### Trigger Conditions\n- Error rate > 2x baseline\n- P95 latency > [X]ms\n- User reports of [specific issue]\n\n### Rollback Steps\n1. Disable feature flag (if applicable)\n   OR\n1. Deploy previous version: `git revert \u003Ccommit> && git push`\n2. Verify rollback: health check, error monitoring\n3. Communicate: notify team of rollback\n\n### Database Considerations\n- Migration [X] has a rollback through the repository-declared tool: `npm exec -- prisma migrate rollback`\n- Data inserted by new feature: [preserved \u002F cleaned up]\n\n### Time to Rollback\n- Feature flag: \u003C 1 minute\n- Redeploy previous version: \u003C 5 minutes\n- Database rollback: \u003C 15 minutes\n```\n## See Also\n\n- For security pre-launch checks, see the `security-and-hardening` skill\n- For performance pre-launch checks, see the `performance-optimization` skill\n- For accessibility verification before launch, see the `frontend-ui-engineering` skill\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"It works in staging, it'll work in production\" | Production has different data, traffic patterns, and edge cases. Monitor after deploy. |\n| \"We don't need feature flags for this\" | Every feature benefits from a kill switch. Even \"simple\" changes can break things. |\n| \"Monitoring is overhead\" | Not having monitoring means you discover problems from user complaints instead of dashboards. |\n| \"We'll add monitoring later\" | Add it before launch. You can't debug what you can't see. |\n| \"Rolling back is admitting failure\" | Rolling back is responsible engineering. Shipping a broken feature is the failure. |\n\n## Red Flags\n\n- Deploying without a rollback plan\n- No monitoring or error reporting in production\n- Big-bang releases (everything at once, no staging)\n- Feature flags with no expiration or owner\n- No one monitoring the deploy for the first hour\n- Production environment configuration done by memory, not code\n- \"It's Friday afternoon, let's ship it\"\n\n## Verification\n\nBefore deploying:\n\n- [ ] Pre-launch checklist completed (all sections green)\n- [ ] Feature flag configured (if applicable)\n- [ ] Rollback plan documented\n- [ ] Monitoring dashboards set up\n- [ ] Team notified of deployment\n\nAfter deploying:\n\n- [ ] Health check returns 200\n- [ ] Error rate is normal\n- [ ] Latency is normal\n- [ ] Critical user flow works\n- [ ] Logs are flowing\n- [ ] Rollback tested or verified ready\n",{"name":42,"description":43},"shipping-and-launch","Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.","main","38248e428f013b1dc844e2de8de379113913a71b","skills\u002Fgithub-pr-merge",0,"https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills","https:\u002F\u002Fgithub.com\u002FJinsYin","Bigdata Architect. Do more things!","2026-11-09 10:40:45",{"source":8,"skillName":42,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add JinsYin\u002Fskills --skill shipping-and-launch",{"tool":58,"command":59},"bunx","bunx skills add JinsYin\u002Fskills --skill shipping-and-launch",{"tool":61,"command":62},"pnpm","pnpm dlx skills add JinsYin\u002Fskills --skill shipping-and-launch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fgithub-pr-merge\u002FSKILL.md",true,[],[67,98,120,144,175,204],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":37},"01M6D11YS49YDGXSBJ1YJ0FAD3","write-great-skill","Workflow and quality bar for agent skills: draft, polish, compress, verify, ship. Use whenever creating or editing a skill (`SKILL.md`, `references\u002F`, `rules\u002F`), or when project conventions route root `CLAUDE.md`\u002F`AGENTS.md` edits here, even if the user only says “改一下这个 skill”.","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fwrite-great-skill\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[79,80,81,82,83,84,85,86,87,88,89,90,29,91,92,93,94,95,30,96,24,97],"write","write great skill","draft","route","references","project conventions","verify","project","editing","polish","only","conventions","Rules","ship","workflow","quality","compress","for","bar",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":37},"01M6D11PP5HJ8142DKTSRJV73A","write-fspec","Derive the 功能规格说明书 (functional spec) from the product prototype and keep it versioned under products\u002Ffspec\u002F: Flyway-style V files plus a merged CURRENT.md. Use when a prototype is finalized, changed or backfilled, when a draft V is confirmed or CURRENT.md lags, or when the user mentions 功能规格, 功能规格说明书 or fspec. Not for the feature spec (.scratch\u002F*\u002Fspec.md) or DESIGN.md.","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fwrite-fspec\u002FSKILL.md",[],[79,105,81,106,107,108,109,110,111,112,113,114,29,115,30,96,116,24,117,118,119],"write fspec","prototype","feature","product","read","spec","edit","grep","design","files","Bash","scratch","keep","functional","style",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":37},"01M6D11JXM378SWT0VYVCPGN0Y","version-release","Cut a SemVer release — bump every module's version in lockstep, promote CHANGELOG.md, commit, tag, push to origin. Args `major|minor|patch|\u003Cx.y.z>`; none → level inferred from `[Unreleased]`, confirmed with user. Invoke only on explicit request: the user, another skill, or a project convention asking for a release.","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fversion-release\u002FSKILL.md",[],[127,128,129,130,131,132,86,133,134,89,135,136,137,30,138,96,139,140,141,142,143],"release","version release","version","promote","push","changelog","another skill","bump","semver","patch","commit","with","request","cut","module","invoke","origin",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":158,"publishedAt":37},"01M6D11AR4DYNS4JM0QWQGAYS6","ui-ux-best-practices","UI\u002FUX rules for Chinese-language React\u002FVue admin consoles and their product\u002Fdesign specs. Use when designing, building, reviewing, or refactoring forms, lists, modals\u002Fdrawers, destructive actions, copy, formats, or console layout.","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fui-ux-best-practices\u002FSKILL.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":154,"categoryName":155,"taxonomyType":156,"taxonomyTypeDesc":157},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[159,160,161,162,163,164,165,108,166,167,168,169,170,113,29,91,171,172,173,96,24,174],"ux","ui ux best practices","ui","best practices","ui ux","admin","chinese","layout","refactoring","actions","forms","console","vue","language","react","formats",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":184,"publishedAt":37},"01M6D111ECN97WMTB68PSQTGRV","spring-boot-best-practices","Spring Boot 3 + Java 21 + MyBatis Plus 项目的编码规范与架构纪律。涵盖分层依赖、国密 SM2\u002FSM3\u002FSM4、MyBatis Plus 实体与主键策略、多方言数据库迁移、R\u002FRList\u002FRPage 响应包装、DTO 职责边界、鉴权框架选型（Spring Security \u002F Sa-Token）与声明式权限校验、命名约定、模块 README 文档要求。在编写、审查或重构 Spring Boot 后端代码时使用——尤其是新增 Controller\u002FService\u002FMapper、定义 Entity 或 DTO、写数据库迁移、处理加解密与签名、设计 API 契约、或接入鉴权与权限校验时。","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fspring-boot-best-practices\u002FSKILL.md",[181],{"categoryNo":182,"categoryName":183,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000010","后端与接口",[185,186,187,188,162,189,190,191,192,113,193,194,195,196,197,198,199,200,201,202,203],"spring boot best practices","spring boot","spring","boot","controller","README","校验","token","文档","service","security","java","api","spring boot 3","dto","mybatis","spring security","后端","数据",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":37},"01M6D10Q5V8BG1YRW3AV89VVA3","setup-rules","Conduct an interactive interview, then install selected agent conventions, adapters, `skillsw`, and sensitive-file read restrictions into a project; `update` refreshes installed items without prompting. Use when the user asks to set up agent rules, or run `update` after `setup-rules` conventions change (e.g. Skill Workflow sync). Not for reviewing or hand-editing `CLAUDE.local.md`.","https:\u002F\u002Fgithub.com\u002FJinsYin\u002Fskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsetup-rules\u002FSKILL.md",[210],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},[212,91,213,214,215,216,86,217,87,218,109,219,220,221,222,90,29,93,223,224,225,96,24,226,227,228],"setup rules","setup","SET","interview","change","run","update","up","sync","local","install","Adapters","agent rules","conduct","file","interactive","hand"]