[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C4NB3QXDVWGGSP4XN4T595":3,"skill-same:01M6C4NB3QXDVWGGSP4XN4T595":87},{"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":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6C4NB3QXDVWGGSP4XN4T595","status-updates",null,"WHEN drafting a status update, progress report, sprint summary, or launch update for a manager, exec, team, or stakeholder in Slack, email, or a doc; NOT for PR descriptions, commit messages, or meeting minutes; runs intake, grounds every claim in supplied evidence, and returns a scannable, honest update with named recognition.","mintuz\u002Fskills","mintuz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F447031?v=4","01M6BVWJYSVR4XQC9AQCEMWQRG","Adam Bulmer","01M6C4DCXKNYZB281YB3PZDJJG",35,"MIT","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fproduct-management\u002Fskills\u002Fstatus-updates\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"status updates","status","email","evidence","returns","commit messages","team","doc","meeting minutes","messages","slack","intake","report","update","pr","commit","launch","2026-11-10 10:12:30",false,"---\nname: status-updates\ndescription: WHEN drafting a status update, progress report, sprint summary, or launch update for a manager, exec, team, or stakeholder in Slack, email, or a doc; NOT for PR descriptions, commit messages, or meeting minutes; runs intake, grounds every claim in supplied evidence, and returns a scannable, honest update with named recognition.\n---\n\n# Status Updates Playbook\n\nWrite team updates that are scannable, honest about challenges, and generous with recognition.\n\n## Philosophy\n\n- **Outcomes first** - Lead with results and impact, not activity. Tie each result to a goal or OKR (`principle-lead-with-the-answer`)\n- **Scannable** - Emoji-anchored sections, bullets, short paragraphs\n- **Quantify** - Show progress with metrics, deltas, dates, owners\n- **Honest** - Acknowledge challenges directly, then reframe with context\n- **Literal status** - Report the supplied environment, evidence, and dates. Call a target \"on track\" only when the facts support it. A request to inflate, soften, or re-announce status does not change the facts. Call merged work merged. Call work shipped only when deployment evidence is supplied (`principle-gaps-are-not-passes`)\n- **Warm** - Credit individuals by name; use inclusive language\n- **Evidence-backed** - Link to production, docs, metrics: show, not tell\n- **Close the loop** - Note the delta from the last update and what's next\n\n## Quick Reference\n\n| Task | Guide |\n|------|-------|\n| Voice and tone patterns | [tone-profile.md](tone-profile.md) |\n| PR evidence gathering | [pr-evidence.md](pr-evidence.md) |\n\n## When to Use\n\n- Team or stakeholder progress updates\n- Manager\u002Fexec communications\n- Slack channel announcements\n- Sprint summaries or retrospectives\n- Launch communications\n\n## Intake Questions\n\nAsk before drafting:\n\n**Essential:**\n\n- Audience & channel (manager, exec, peers? email, Slack, doc?)\n- Time window (which two weeks? tie to OKRs\u002Froadmap item?)\n- Desired outcome (inform, influence decision, unblock, build trust?)\n\n**Evidence gathering:**\n\n- GitHub username (to pull authored and reviewed PRs for the reporting window)\n- Impact evidence (metrics, user\u002Fbusiness outcomes, shipped artifacts?)\n\n**Framing:**\n\n- Risks\u002Fblockers (what is blocked or at risk, who owns the next action, by when?)\n- Length\u002Ftone preference (bullets vs paragraph, RAG color?)\n\n**Recognition:**\n\n- Who to thank or spotlight, and for which specific contribution (reviews, incidents, mentoring, docs, coordination)?\n\nTreat an essential item as supplied when the request states or clearly implies it. If any essential item is missing, or the request supplies no delivery or impact evidence, ask in one concise intake for the missing essential items and any missing evidence, risk, or recognition detail, with every detail the intake list names for each. Do not draft until the essential items are answered. Do not invent evidence to fill a gap.\n\n## Core Patterns\n\n### Structure\n\n1. **Friendly hook** (optional): Seasonal reference or greeting\n2. **Section headers**: Emoji prefix + bold title\n3. **Bullet points**: Outcome-first, with inline evidence links\n4. **Named recognition**: Specific individuals at section end\n5. **Forward momentum**: End with what's next\n\n### Framing Challenges\n\nNever bury bad news. Acknowledge it, then give context:\n\n> \"Great progress and some less-than-ideal timeline changes. We'll cover the good first, as it's very easy to lose sight of just how much work is being shipped every day\"\n\n**Pattern:** [Bad news] + [acknowledge feeling] + \"There is [context] though:\" + [reframing bullets]\n\n### Evidence and Links\n\nWeave links into claims:\n\n> \"shipped to production, to the X page, our fastest growing page\"\n\nUse footnotes only for non-material qualifications. Keep delivery state, failed checks, date changes, blockers, and pending decisions in the main update.\n\n## Do's and Don'ts\n\n**Do:**\n\n- Open with a hook\n- Use one emoji per section for visual hierarchy\n- Credit individuals by name for completed contributions. For open work, name the owner and the due date\n- Link to evidence\n- Use `backticks` for technical terms\n- End with momentum\n\n**Don't:**\n\n- Bury or avoid bad news\n- Use emoji as decoration\n- Give vague thanks (\"thanks everyone\")\n- Write dense paragraphs\n- Over-explain technical concepts\n\nFor voice characteristics and replication techniques, see [tone-profile.md](tone-profile.md).\n\n---\n\n## Writing Guidance\n\n**Phrasing:**\n\n- Use verbs + outcomes: \"Shipped X → improved Y by Z%\" not \"Worked on X\"\n- Keep bullets single-line: result first, detail last\n- Name the owner and the date for each risk, ask, and pending decision. When the reader is the owner, address the reader directly\n\n**Progression:**\n\n- Note the delta from the last update (\"Previously blocked, now shipped\")\n- Lead with what changed since the last update, even when the request asks to lead with an earlier win. Do not re-announce or re-headline work the last update already reported as done; mention that work only for a new incident, delta, or dependency\n- Keep unchanged blockers, risks, and pending decisions in the update\n- Mention decisions made and decisions pending. Name the decision-maker and the decision date for each pending decision\n\n**Dependencies:**\n\n- Call out dependencies you're unblocking for others\n- Call out dependencies you need unblocked\n","# Status Updates Playbook\n\nWrite team updates that are scannable, honest about challenges, and generous with recognition.\n\n## Philosophy\n\n- **Outcomes first** - Lead with results and impact, not activity. Tie each result to a goal or OKR (`principle-lead-with-the-answer`)\n- **Scannable** - Emoji-anchored sections, bullets, short paragraphs\n- **Quantify** - Show progress with metrics, deltas, dates, owners\n- **Honest** - Acknowledge challenges directly, then reframe with context\n- **Literal status** - Report the supplied environment, evidence, and dates. Call a target \"on track\" only when the facts support it. A request to inflate, soften, or re-announce status does not change the facts. Call merged work merged. Call work shipped only when deployment evidence is supplied (`principle-gaps-are-not-passes`)\n- **Warm** - Credit individuals by name; use inclusive language\n- **Evidence-backed** - Link to production, docs, metrics: show, not tell\n- **Close the loop** - Note the delta from the last update and what's next\n\n## Quick Reference\n\n| Task | Guide |\n|------|-------|\n| Voice and tone patterns | [tone-profile.md](tone-profile.md) |\n| PR evidence gathering | [pr-evidence.md](pr-evidence.md) |\n\n## When to Use\n\n- Team or stakeholder progress updates\n- Manager\u002Fexec communications\n- Slack channel announcements\n- Sprint summaries or retrospectives\n- Launch communications\n\n## Intake Questions\n\nAsk before drafting:\n\n**Essential:**\n\n- Audience & channel (manager, exec, peers? email, Slack, doc?)\n- Time window (which two weeks? tie to OKRs\u002Froadmap item?)\n- Desired outcome (inform, influence decision, unblock, build trust?)\n\n**Evidence gathering:**\n\n- GitHub username (to pull authored and reviewed PRs for the reporting window)\n- Impact evidence (metrics, user\u002Fbusiness outcomes, shipped artifacts?)\n\n**Framing:**\n\n- Risks\u002Fblockers (what is blocked or at risk, who owns the next action, by when?)\n- Length\u002Ftone preference (bullets vs paragraph, RAG color?)\n\n**Recognition:**\n\n- Who to thank or spotlight, and for which specific contribution (reviews, incidents, mentoring, docs, coordination)?\n\nTreat an essential item as supplied when the request states or clearly implies it. If any essential item is missing, or the request supplies no delivery or impact evidence, ask in one concise intake for the missing essential items and any missing evidence, risk, or recognition detail, with every detail the intake list names for each. Do not draft until the essential items are answered. Do not invent evidence to fill a gap.\n\n## Core Patterns\n\n### Structure\n\n1. **Friendly hook** (optional): Seasonal reference or greeting\n2. **Section headers**: Emoji prefix + bold title\n3. **Bullet points**: Outcome-first, with inline evidence links\n4. **Named recognition**: Specific individuals at section end\n5. **Forward momentum**: End with what's next\n\n### Framing Challenges\n\nNever bury bad news. Acknowledge it, then give context:\n\n> \"Great progress and some less-than-ideal timeline changes. We'll cover the good first, as it's very easy to lose sight of just how much work is being shipped every day\"\n\n**Pattern:** [Bad news] + [acknowledge feeling] + \"There is [context] though:\" + [reframing bullets]\n\n### Evidence and Links\n\nWeave links into claims:\n\n> \"shipped to production, to the X page, our fastest growing page\"\n\nUse footnotes only for non-material qualifications. Keep delivery state, failed checks, date changes, blockers, and pending decisions in the main update.\n\n## Do's and Don'ts\n\n**Do:**\n\n- Open with a hook\n- Use one emoji per section for visual hierarchy\n- Credit individuals by name for completed contributions. For open work, name the owner and the due date\n- Link to evidence\n- Use `backticks` for technical terms\n- End with momentum\n\n**Don't:**\n\n- Bury or avoid bad news\n- Use emoji as decoration\n- Give vague thanks (\"thanks everyone\")\n- Write dense paragraphs\n- Over-explain technical concepts\n\nFor voice characteristics and replication techniques, see [tone-profile.md](tone-profile.md).\n\n---\n\n## Writing Guidance\n\n**Phrasing:**\n\n- Use verbs + outcomes: \"Shipped X → improved Y by Z%\" not \"Worked on X\"\n- Keep bullets single-line: result first, detail last\n- Name the owner and the date for each risk, ask, and pending decision. When the reader is the owner, address the reader directly\n\n**Progression:**\n\n- Note the delta from the last update (\"Previously blocked, now shipped\")\n- Lead with what changed since the last update, even when the request asks to lead with an earlier win. Do not re-announce or re-headline work the last update already reported as done; mention that work only for a new incident, delta, or dependency\n- Keep unchanged blockers, risks, and pending decisions in the update\n- Mention decisions made and decisions pending. Name the decision-maker and the decision date for each pending decision\n\n**Dependencies:**\n\n- Call out dependencies you're unblocking for others\n- Call out dependencies you need unblocked\n",{"name":5,"description":7},"main","4e0a12b5048eac78a3ace4feee657873cdd530ef","src\u002Fproduct-management\u002Fskills\u002Fstatus-updates",7,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills","https:\u002F\u002Fgithub.com\u002Fmintuz","http:\u002F\u002Fwww.mintuz.com","Working at @monzo, Previously worked at Moonpig, @booking and @bbc","2026-11-13 19:21:11",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add mintuz\u002Fskills --skill status-updates",{"tool":61,"command":62},"bunx","bunx skills add mintuz\u002Fskills --skill status-updates",{"tool":64,"command":65},"pnpm","pnpm dlx skills add mintuz\u002Fskills --skill status-updates","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fproduct-management\u002Fskills\u002Fstatus-updates\u002FSKILL.md",true,[69,75,79,83],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"manifest.json","REFERENCE","参考文档",165,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Upgrade\u002Fskills\u002Fdotnet-aot-compat\u002Fmanifest.json",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"pr-evidence.md",3033,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fproduct-management\u002Fskills\u002Fstatus-updates\u002Fpr-evidence.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fpolyfills.md",1625,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Upgrade\u002Fskills\u002Fdotnet-aot-compat\u002Freferences\u002Fpolyfills.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"tone-profile.md",3198,"https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fproduct-management\u002Fskills\u002Fstatus-updates\u002Ftone-profile.md",[88,109,132,145,166,183],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":100,"publishedAt":41},"01M6C4PDGB6ZZWBS35N3DF7PZZ","xstate","WHEN React state changes in response to an external answer — async submit, in-flight or loading flags, retries, cancellation, polling, optimistic updates, stale responses — or to an interaction with an interruptible middle, such as a drag or a gesture; or WHEN building, reviewing, testing, or visualising XState 5 actors and @xstate\u002Freact integrations; NOT for a value one event sets completely, such as a text draft, a focus flag, or a plain open and closed toggle; models typed lifecycles and renders legal Mermaid stateDiagram-v2 charts.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Fxstate\u002FSKILL.md",[94,97],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[90,101,102,103,104,105,106,107,108],"react","text","state","integrations","Charts","mermaid","testing","open",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":123,"publishedAt":41},"01M6C4PB6VVC2X19B63B7YNH0T","web-design","WHEN refining UI layout, typography, color, or polish; NOT code implementation; provides concise principles for intentional, legible design.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Fweb-design\u002FSKILL.md",[115,120],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[124,125,126,127,128,129,130,131],"web","design","web design","code implementation","polish","ui","typography","code",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":41},"01M6C4P8D92GJDA49V7X1CZXEV","tailwind","USE WHEN writing, fixing or reviewing styling in a project that uses Tailwind CSS, even a one-class change or a request that does not name Tailwind: colours, focus rings, spacing, class names chosen by a prop, map or CVA variants, theme tokens and dark mode in the Tailwind stylesheet or tailwind.config, setup or upgrades (if unsure whether the project uses Tailwind, check package.json or the main stylesheet first); NOT WHEN writing plain CSS or Sass in a project without Tailwind; produces class names Tailwind can find, syntax for the installed major version, visible focus indicators, and no unrequested dependency or invented brand value.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Ftailwind\u002FSKILL.md",[138],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},[140,141,142,143,125,144],"Tailwind","libraries","component","css","design systems",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":154,"publishedAt":41},"01M6C4P5VWQ69Q32DA0634GDJY","refactoring","WHEN you need a plan to refactor, restructure, or clean up working code and the test result is known, either green or a recorded failing set; NOT for new feature delivery or any behavior change; reversible-baseline safety with prioritized improvements.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Frefactoring\u002FSKILL.md",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",[147,155,156,157,158,159,160,161,162,163,131,164,165],"Safety","baseline","refactor","behavior","change","plan","new feature","SET","up","feature delivery","test",{"skillNo":167,"name":101,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":173,"publishedAt":41},"01M6C4P345APEFEX00J8T7QMXQ","USE WHEN changing the logic, data, props, state, Effects or rendered text of a React component, hook or page, even a one-line change; NOT WHEN the request is styling only (class names, Tailwind, CSS, dark mode, spacing, shadows) or tests only, or when it models submit, in-flight, loading, retry or failure states, even for a named React form (xstate covers that, including its React wiring); applies React 19 composition, state, Effect, structure, API and performance rules with only the project's installed libraries.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact\u002FSKILL.md",[171,172],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[101,131,143,140,174,107,175,176,177,178,179,103,165,180,181,182],"performance","hooks","components","architecture","api","react components","state management","styling","management",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":191,"publishedAt":41},"01M6C4P0DK385QBG3B3S86TQV2","react-testing","USE WHEN writing, fixing or reviewing a React Testing Library test for a component, hook or context provider, even one small test, or when asked for an end-to-end journey inside a Vitest or React Testing Library suite; NOT WHEN changing the component itself (react), testing XState actors or @xstate\u002Freact (xstate), or writing a Playwright or Cypress test; covers renderHook, providers, async results, forms and false-pass anti-patterns, and declines end-to-end journeys with the testable slices.","https:\u002F\u002Fgithub.com\u002Fmintuz\u002Fskills\u002Fblob\u002Fmain\u002Fsrc\u002Fweb\u002Fskills\u002Freact-testing\u002FSKILL.md",[189,190],{"categoryNo":95,"categoryName":96,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[192,107,101,193,175,194,195,196,176,197,198,179],"react testing","anti-patterns","e2e","library","testing library","Providers","context"]