[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JQ95CBZK180P87RHFCZXW6":3,"skill-same:01M6JQ95CBZK180P87RHFCZXW6":80},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6JQ95CBZK180P87RHFCZXW6","metrics-and-okrs",null,"Define OKRs, KPIs, success metrics, and engineering health metrics (DORA). Triggers: OKR, KPI, metrics, success metrics, key results, objectives, measure success, DORA metrics, engineering metrics, velocity, cycle time, deployment frequency, how do we measure, what should we track.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmetrics-and-okrs\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],"metrics","metrics and okrs","deployment","engineering","kpi","health","how","results","okr","do","cycle","velocity","time","define","triggers","dora metrics","2026-11-10 10:12:30",false,"---\nname: metrics-and-okrs\ndescription: \"Define OKRs, KPIs, success metrics, and engineering health metrics (DORA). Triggers: OKR, KPI, metrics, success metrics, key results, objectives, measure success, DORA metrics, engineering metrics, velocity, cycle time, deployment frequency, how do we measure, what should we track.\"\n---\n\n# Metrics & OKRs\n\nDefine meaningful metrics that drive decisions and OKRs that align engineering work with business outcomes. Good metrics answer \"are we succeeding?\" Bad metrics create busywork.\n\n## Core Rule\n\n**Every metric must drive a decision.** If knowing the metric's value wouldn't change what you do, stop tracking it. Metrics without decisions are vanity metrics.\n\n## Workflow: OKRs\n\n### Step 1: Understand the Context\n\nBefore writing OKRs:\n\n- **What's the time horizon?** Quarterly is standard. Annual is too long for engineering.\n- **What level?** Company → Team → Individual? Start with team-level.\n- **What's the business priority?** Growth? Retention? Reliability? Cost reduction?\n- **What did we learn from last quarter?** What OKRs were hit, missed, and why?\n\n### Step 2: Write Objectives\n\nAn Objective is a qualitative, inspiring goal that answers \"where do we want to go?\"\n\n**Good Objectives:**\n- \"Make the checkout experience delightfully fast\"\n- \"Build a platform our enterprise customers trust\"\n- \"Eliminate the deployment bottleneck\"\n\n**Bad Objectives:**\n- \"Improve latency by 40%\" (this is a Key Result, not an Objective)\n- \"Complete the Q3 roadmap\" (this is output, not outcome)\n- \"Increase revenue\" (too vague, not actionable by engineering)\n\nRules: 3-5 objectives per team per quarter. Each should be ambitious but achievable. If you hit 100% of all OKRs, you aimed too low. 70% achievement is healthy.\n\n### Step 3: Write Key Results\n\nKey Results are quantitative measures that prove the Objective is being met.\n\n**Good Key Results:**\n- \"Reduce checkout page load time from 3.2s to under 1.5s at P95\"\n- \"Achieve 99.95% API availability (up from 99.8%)\"\n- \"Reduce time from PR merge to production from 4 hours to 30 minutes\"\n\n**Bad Key Results:**\n- \"Launch the new checkout page\" (this is output, not outcome)\n- \"Improve performance\" (not measurable)\n- \"No production incidents\" (not realistic and incentivizes hiding incidents)\n\nEach Objective should have 2-4 Key Results. Each Key Result needs:\n- **Current value** (baseline)\n- **Target value** (goal)\n- **How it's measured** (data source, calculation)\n\n### Step 4: Validate the OKRs\n\nCheck each OKR against these criteria:\n- [ ] Is the Objective inspiring and clearly directional?\n- [ ] Are Key Results measurable with a specific number?\n- [ ] Can we actually measure this today? (If not, first KR might be \"instrument X\")\n- [ ] Do Key Results measure outcomes, not outputs?\n- [ ] Is 70% achievement of all KRs realistic with focused effort?\n- [ ] Are there perverse incentives? (Reducing errors by not logging them)\n\n### Step 5: Produce the OKR Document\n\nUse the template at [templates\u002Fokr-document.md](templates\u002Fokr-document.md).\n\n## Workflow: Project Success Metrics\n\nFor any project or feature, define metrics in three categories:\n\n**Leading indicators** (early signals during development):\n- Sprint velocity, burndown trend, scope change rate\n- Test coverage of new code, CI pipeline pass rate\n\n**Lagging indicators** (results after launch):\n- User adoption (DAU, feature usage rate)\n- Performance metrics (latency, error rate, availability)\n- Business metrics (conversion rate, revenue, support ticket volume)\n\n**Health indicators** (ongoing system health):\n- DORA metrics (see below)\n- Technical debt metrics (code quality trends, dependency freshness)\n\nSee [references\u002Fmetric-catalog.md](references\u002Fmetric-catalog.md) for a catalog of useful metrics by category.\n\n## Workflow: DORA Engineering Metrics\n\nThe four DORA metrics are the industry standard for measuring engineering team effectiveness:\n\n| Metric | What It Measures | Elite | High | Medium | Low |\n|--------|-----------------|-------|------|--------|-----|\n| **Deployment Frequency** | How often you deploy | Multiple\u002Fday | Weekly | Monthly | Quarterly |\n| **Lead Time for Changes** | PR merge to production | \u003C 1 hour | \u003C 1 day | \u003C 1 week | > 1 month |\n| **Change Failure Rate** | % of deploys causing incidents | \u003C 5% | \u003C 10% | \u003C 15% | > 30% |\n| **Mean Time to Recover** | Incident to resolution | \u003C 1 hour | \u003C 1 day | \u003C 1 week | > 1 month |\n\nThese four metrics together tell you if your team is delivering quickly and reliably. Optimizing one at the expense of another is a trap (deploying fast but breaking things, or never breaking things but never shipping).\n\n## Principles Applied\n\n- **KISS**: 3-5 OKRs per team, 2-4 KRs each. More means none get attention.\n- **Outcomes over outputs**: Measure \"user checkout time reduced\" not \"new checkout page shipped.\"\n- **YAGNI**: Don't build a metrics dashboard for 50 KPIs. Start with the 5 that would actually change a decision.\n- **Leading over lagging**: Prefer metrics you can act on now over metrics you can only measure after the fact.\n","# Metrics & OKRs\n\nDefine meaningful metrics that drive decisions and OKRs that align engineering work with business outcomes. Good metrics answer \"are we succeeding?\" Bad metrics create busywork.\n\n## Core Rule\n\n**Every metric must drive a decision.** If knowing the metric's value wouldn't change what you do, stop tracking it. Metrics without decisions are vanity metrics.\n\n## Workflow: OKRs\n\n### Step 1: Understand the Context\n\nBefore writing OKRs:\n\n- **What's the time horizon?** Quarterly is standard. Annual is too long for engineering.\n- **What level?** Company → Team → Individual? Start with team-level.\n- **What's the business priority?** Growth? Retention? Reliability? Cost reduction?\n- **What did we learn from last quarter?** What OKRs were hit, missed, and why?\n\n### Step 2: Write Objectives\n\nAn Objective is a qualitative, inspiring goal that answers \"where do we want to go?\"\n\n**Good Objectives:**\n- \"Make the checkout experience delightfully fast\"\n- \"Build a platform our enterprise customers trust\"\n- \"Eliminate the deployment bottleneck\"\n\n**Bad Objectives:**\n- \"Improve latency by 40%\" (this is a Key Result, not an Objective)\n- \"Complete the Q3 roadmap\" (this is output, not outcome)\n- \"Increase revenue\" (too vague, not actionable by engineering)\n\nRules: 3-5 objectives per team per quarter. Each should be ambitious but achievable. If you hit 100% of all OKRs, you aimed too low. 70% achievement is healthy.\n\n### Step 3: Write Key Results\n\nKey Results are quantitative measures that prove the Objective is being met.\n\n**Good Key Results:**\n- \"Reduce checkout page load time from 3.2s to under 1.5s at P95\"\n- \"Achieve 99.95% API availability (up from 99.8%)\"\n- \"Reduce time from PR merge to production from 4 hours to 30 minutes\"\n\n**Bad Key Results:**\n- \"Launch the new checkout page\" (this is output, not outcome)\n- \"Improve performance\" (not measurable)\n- \"No production incidents\" (not realistic and incentivizes hiding incidents)\n\nEach Objective should have 2-4 Key Results. Each Key Result needs:\n- **Current value** (baseline)\n- **Target value** (goal)\n- **How it's measured** (data source, calculation)\n\n### Step 4: Validate the OKRs\n\nCheck each OKR against these criteria:\n- [ ] Is the Objective inspiring and clearly directional?\n- [ ] Are Key Results measurable with a specific number?\n- [ ] Can we actually measure this today? (If not, first KR might be \"instrument X\")\n- [ ] Do Key Results measure outcomes, not outputs?\n- [ ] Is 70% achievement of all KRs realistic with focused effort?\n- [ ] Are there perverse incentives? (Reducing errors by not logging them)\n\n### Step 5: Produce the OKR Document\n\nUse the template at [templates\u002Fokr-document.md](templates\u002Fokr-document.md).\n\n## Workflow: Project Success Metrics\n\nFor any project or feature, define metrics in three categories:\n\n**Leading indicators** (early signals during development):\n- Sprint velocity, burndown trend, scope change rate\n- Test coverage of new code, CI pipeline pass rate\n\n**Lagging indicators** (results after launch):\n- User adoption (DAU, feature usage rate)\n- Performance metrics (latency, error rate, availability)\n- Business metrics (conversion rate, revenue, support ticket volume)\n\n**Health indicators** (ongoing system health):\n- DORA metrics (see below)\n- Technical debt metrics (code quality trends, dependency freshness)\n\nSee [references\u002Fmetric-catalog.md](references\u002Fmetric-catalog.md) for a catalog of useful metrics by category.\n\n## Workflow: DORA Engineering Metrics\n\nThe four DORA metrics are the industry standard for measuring engineering team effectiveness:\n\n| Metric | What It Measures | Elite | High | Medium | Low |\n|--------|-----------------|-------|------|--------|-----|\n| **Deployment Frequency** | How often you deploy | Multiple\u002Fday | Weekly | Monthly | Quarterly |\n| **Lead Time for Changes** | PR merge to production | \u003C 1 hour | \u003C 1 day | \u003C 1 week | > 1 month |\n| **Change Failure Rate** | % of deploys causing incidents | \u003C 5% | \u003C 10% | \u003C 15% | > 30% |\n| **Mean Time to Recover** | Incident to resolution | \u003C 1 hour | \u003C 1 day | \u003C 1 week | > 1 month |\n\nThese four metrics together tell you if your team is delivering quickly and reliably. Optimizing one at the expense of another is a trap (deploying fast but breaking things, or never breaking things but never shipping).\n\n## Principles Applied\n\n- **KISS**: 3-5 OKRs per team, 2-4 KRs each. More means none get attention.\n- **Outcomes over outputs**: Measure \"user checkout time reduced\" not \"new checkout page shipped.\"\n- **YAGNI**: Don't build a metrics dashboard for 50 KPIs. Start with the 5 that would actually change a decision.\n- **Leading over lagging**: Prefer metrics you can act on now over metrics you can only measure after the fact.\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","skills\u002Fmetrics-and-okrs","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill metrics-and-okrs",{"tool":58,"command":59},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill metrics-and-okrs",{"tool":61,"command":62},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill metrics-and-okrs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmetrics-and-okrs\u002FSKILL.md",true,[66,72,76],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"evals\u002Fevals.json","REFERENCE","参考文档",3388,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmetrics-and-okrs\u002Fevals\u002Fevals.json",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fmetric-catalog.md",4353,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmetrics-and-okrs\u002Freferences\u002Fmetric-catalog.md",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"templates\u002Fokr-document.md",1788,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmetrics-and-okrs\u002Ftemplates\u002Fokr-document.md",[81,122,147,171,204,233],{"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":102,"publishedAt":40},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[87,90,93,94,99],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":100,"categoryName":101,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000040","财务",[103,104,105,106,107,108,109,110,111,112,113,114,38,115,116,117,118,119,120,121],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","library","frontmatter","editing","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":40},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132,133,134,135,136,137,30,138,139,140,141,142,143,33,144,145,38,146],"working agreement","project","definition of done","done","milestone","documentation","work","progress","contributing","close","run","sync","status","live","README","session","routines",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":40},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[153],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[155,156,157,158,159,160,103,161,133,162,163,164,136,165,139,166,167,168,169,170],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":184,"publishedAt":40},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[177,180,181],{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":182,"categoryName":183,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000032","设计师",[185,186,187,188,189,190,191,192,193,194,195,196,30,197,198,199,200,201,202,203],"design","ux","ui","ui ux design","error","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":214,"publishedAt":40},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[210,211],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000030","开发工程师",[215,216,217,218,36,219,185,220,221,222,223,224,225,226,227,228,229,230,231,232],"modeling","threat modeling","threat","model","element","whiteboard","security analysis","analysis","code","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":244,"publishedAt":40},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[239,240,241,242,243],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":212,"categoryName":213,"taxonomyType":97,"taxonomyTypeDesc":98},{"categoryNo":182,"categoryName":183,"taxonomyType":97,"taxonomyTypeDesc":98},[185,245,246,247,248,249,105,250,251,161,223,252,253,107,254,255,33,256,257,38],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]