[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M750CW855DYVP191EXRFT032":3,"skill-same:01M750CW855DYVP191EXRFT032":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":31,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M750CW855DYVP191EXRFT032","eng-status-rollup",null,"Rolls up engineering team status into an exec-ready written update with exactly three sections - progress in outcomes, risks with likelihood and mitigation, and asks with owners and deadlines - scannable in under 90 seconds. Use when someone asks \"write my weekly eng update\", \"summarize team status for leadership\", \"turn these standup notes into an exec update\", or is prepping for a leadership sync. Do NOT use for updates to external or cross-functional stakeholders on a project - use stakeholder-update instead - for public incident communication - use status-page-update - or for monthly investor letters - use investor-update-writer instead.","SkillMedev\u002Fskills","SkillMedev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F298078254?v=4","01M74ZSGTQ918CB0VXW4EG3RMX","SkillMe","01M74ZSGVBT497NA95CBT8JTY4",25,"MIT","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Feng-status-rollup\u002FSKILL.md",[],[],"2026-11-11 17:59:37",false,"---\nname: eng-status-rollup\ndescription: Rolls up engineering team status into an exec-ready written update with exactly three sections - progress in outcomes, risks with likelihood and mitigation, and asks with owners and deadlines - scannable in under 90 seconds. Use when someone asks \"write my weekly eng update\", \"summarize team status for leadership\", \"turn these standup notes into an exec update\", or is prepping for a leadership sync. Do NOT use for updates to external or cross-functional stakeholders on a project - use stakeholder-update instead - for public incident communication - use status-page-update - or for monthly investor letters - use investor-update-writer instead.\nmetadata:\n  title: \"Eng Status Rollup\"\n---\n\n# Eng Status Rollup\n\nExecs do not need a feature list. They need three answers: are we on track, what might go wrong, and what do you need from us? A rollup that buries those answers under activity logs trains leadership to skim it - and then the one week the update contains a real red flag, nobody reads it. Everything in this skill defends the 90-second scan.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\n- The raw material: standup notes, sprint board, incident log, whatever exists for the period since the last update.\n- The last rollup sent, so claims stay consistent - a risk that silently disappears without a resolution line destroys credibility faster than the risk itself would have.\n- The audience (direct exec, VP group, company-wide) and the milestone or date the team is publicly committed to.\n- Anything the manager knows but hasn't written down; ask directly \"what are you worried about this week?\" - the real risk is usually in the answer, not the ticket system.\n\nIf a claim is unverified (\"I think the migration is on schedule\"), label it as unconfirmed rather than rounding up to green.\n\n### Step 2: write Progress - outcomes, max 4 bullets\n\nLead with outcomes, not activities. \"Auth service is live for 20% of users\" beats \"we finished the auth service work.\" Translate internal metrics into milestone language - velocity numbers require context an exec doesn't have. If nothing shipped, say so in one sentence with the reason; a padded progress section reads as exactly what it is. Hard cap: 4 bullets. The fifth-most-important thing this week is, by definition, not exec-relevant.\n\n### Step 3: write Risks and Blockers\n\nEvery risk gets four fields on one or two lines: description, likelihood (high \u002F medium \u002F low), impact if it materializes, and the current mitigation. Do not soft-pedal to look in control - the rollup's entire credibility budget is spent on raising real issues before they blow up. A status report with no risks is almost always missing something; if the week genuinely has none, write \"No new risks; [previous risk] resolved by [what happened]\" so the empty section is visibly deliberate. Any risk from last week's rollup must reappear as either still-open (with updated mitigation) or explicitly closed.\n\n### Step 4: write Asks - max 2\n\nAn ask is a specific decision or resource, with a named decider and a response-needed-by date. \"We need more headcount\" is not an ask. \"Approval to hire 1 senior backend engineer in Q3 to hold the platform migration date - decision needed from [name] by July 1\" is an ask. More than 2 asks per update means prioritization hasn't happened yet - do it before sending, not in the exec's inbox. If there are no asks, write \"No asks this week.\"\n\n### Step 5: decide on Looking Ahead\n\nAdd a fourth section only when a significant decision point, launch, or external dependency lands in the next two weeks, and cap it at 2-3 bullets. Do not add it by default - a standing Looking Ahead section becomes the place where the real news hides in future-tense optimism.\n\n### Step 6: pressure-test and send\n\nRead it as the busiest recipient: scannable in under 90 seconds? If not, cut - don't compress. Replace jargon and undefined acronyms. Send in writing before any verbal sync so recipients arrive having read it; the meeting is for discussing the asks, not for narrating the update.\n\n## Template\n\n```\nENG ROLLUP - [FILL: team] - week of [FILL: date]\nStatus vs. [FILL: committed milestone]: ON TRACK \u002F AT RISK \u002F OFF TRACK\n\nPROGRESS (max 4)\n- [FILL: outcome, not activity - what changed for users\u002Fsystems]\n- [FILL]\n- [FILL]\n\nRISKS & BLOCKERS\n- [FILL: risk one-liner] - likelihood: [FILL: H\u002FM\u002FL] - impact: [FILL: what breaks\n  or slips] - mitigation: [FILL: what we're doing about it now]\n- Carried from last week: [FILL: risk] - [FILL: still open + change \u002F CLOSED: how]\n\nASKS (max 2)\n- [FILL: specific decision or resource] - decider: [FILL: name] - needed by: [FILL: date]\n\nLOOKING AHEAD (only if a decision\u002Flaunch\u002Fdependency lands within 2 weeks; max 3)\n- [FILL]\n```\n\n## Worked contrast\n\nBad progress bullet: \"Team continued working on the billing migration and made good progress; several PRs merged.\"\n\nGood progress bullet: \"Billing migration: 40% of invoices now generated by the new system (target: 100% by Aug 15); zero discrepancies in reconciliation so far.\"\n\nThe bad version reports effort and forces the exec to ask the follow-up. The good version reports position against the committed date and pre-answers the only question that matters.\n\n## Deliverable\n\nProduce a written rollup containing: a one-line status against the committed milestone, at most 4 outcome-phrased progress bullets, every risk with likelihood\u002Fimpact\u002Fmitigation plus the disposition of last week's risks, at most 2 asks each with a decider and a date, and Looking Ahead only when the two-week trigger applies - the whole document readable in under 90 seconds.\n\n## Do NOT\n\n- Do not list activities (\"worked on\", \"continued\", \"made progress\") - every progress bullet states an outcome or a position against a date.\n- Do not omit the risks section or leave it vague to look in control; a no-risk rollup reads as a no-look rollup.\n- Do not let a previously reported risk vanish without an explicit close-out line.\n- Do not send more than 2 asks, and never send an ask without a named decider and a date - undated asks are FYIs, and FYIs get ignored.\n- Do not include velocity charts, story-point counts, or sprint burndowns; they demand context the reader doesn't have and invite the wrong conversation.\n- Do not deliver verbally first. The written version leads; the sync discusses it.\n\n## Quality bar\n\n- Scannable in under 90 seconds by someone with zero project context.\n- Every claim is either verified or labeled unconfirmed - no rounding up to green.\n- Section caps respected: 4 progress bullets, 2 asks, 3 Looking Ahead bullets.\n- Each risk has all four fields; each ask has a decider and a date.\n- No acronym or internal codename appears without a plain-language gloss.\n","# Eng Status Rollup\n\nExecs do not need a feature list. They need three answers: are we on track, what might go wrong, and what do you need from us? A rollup that buries those answers under activity logs trains leadership to skim it - and then the one week the update contains a real red flag, nobody reads it. Everything in this skill defends the 90-second scan.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\n- The raw material: standup notes, sprint board, incident log, whatever exists for the period since the last update.\n- The last rollup sent, so claims stay consistent - a risk that silently disappears without a resolution line destroys credibility faster than the risk itself would have.\n- The audience (direct exec, VP group, company-wide) and the milestone or date the team is publicly committed to.\n- Anything the manager knows but hasn't written down; ask directly \"what are you worried about this week?\" - the real risk is usually in the answer, not the ticket system.\n\nIf a claim is unverified (\"I think the migration is on schedule\"), label it as unconfirmed rather than rounding up to green.\n\n### Step 2: write Progress - outcomes, max 4 bullets\n\nLead with outcomes, not activities. \"Auth service is live for 20% of users\" beats \"we finished the auth service work.\" Translate internal metrics into milestone language - velocity numbers require context an exec doesn't have. If nothing shipped, say so in one sentence with the reason; a padded progress section reads as exactly what it is. Hard cap: 4 bullets. The fifth-most-important thing this week is, by definition, not exec-relevant.\n\n### Step 3: write Risks and Blockers\n\nEvery risk gets four fields on one or two lines: description, likelihood (high \u002F medium \u002F low), impact if it materializes, and the current mitigation. Do not soft-pedal to look in control - the rollup's entire credibility budget is spent on raising real issues before they blow up. A status report with no risks is almost always missing something; if the week genuinely has none, write \"No new risks; [previous risk] resolved by [what happened]\" so the empty section is visibly deliberate. Any risk from last week's rollup must reappear as either still-open (with updated mitigation) or explicitly closed.\n\n### Step 4: write Asks - max 2\n\nAn ask is a specific decision or resource, with a named decider and a response-needed-by date. \"We need more headcount\" is not an ask. \"Approval to hire 1 senior backend engineer in Q3 to hold the platform migration date - decision needed from [name] by July 1\" is an ask. More than 2 asks per update means prioritization hasn't happened yet - do it before sending, not in the exec's inbox. If there are no asks, write \"No asks this week.\"\n\n### Step 5: decide on Looking Ahead\n\nAdd a fourth section only when a significant decision point, launch, or external dependency lands in the next two weeks, and cap it at 2-3 bullets. Do not add it by default - a standing Looking Ahead section becomes the place where the real news hides in future-tense optimism.\n\n### Step 6: pressure-test and send\n\nRead it as the busiest recipient: scannable in under 90 seconds? If not, cut - don't compress. Replace jargon and undefined acronyms. Send in writing before any verbal sync so recipients arrive having read it; the meeting is for discussing the asks, not for narrating the update.\n\n## Template\n\n```\nENG ROLLUP - [FILL: team] - week of [FILL: date]\nStatus vs. [FILL: committed milestone]: ON TRACK \u002F AT RISK \u002F OFF TRACK\n\nPROGRESS (max 4)\n- [FILL: outcome, not activity - what changed for users\u002Fsystems]\n- [FILL]\n- [FILL]\n\nRISKS & BLOCKERS\n- [FILL: risk one-liner] - likelihood: [FILL: H\u002FM\u002FL] - impact: [FILL: what breaks\n  or slips] - mitigation: [FILL: what we're doing about it now]\n- Carried from last week: [FILL: risk] - [FILL: still open + change \u002F CLOSED: how]\n\nASKS (max 2)\n- [FILL: specific decision or resource] - decider: [FILL: name] - needed by: [FILL: date]\n\nLOOKING AHEAD (only if a decision\u002Flaunch\u002Fdependency lands within 2 weeks; max 3)\n- [FILL]\n```\n\n## Worked contrast\n\nBad progress bullet: \"Team continued working on the billing migration and made good progress; several PRs merged.\"\n\nGood progress bullet: \"Billing migration: 40% of invoices now generated by the new system (target: 100% by Aug 15); zero discrepancies in reconciliation so far.\"\n\nThe bad version reports effort and forces the exec to ask the follow-up. The good version reports position against the committed date and pre-answers the only question that matters.\n\n## Deliverable\n\nProduce a written rollup containing: a one-line status against the committed milestone, at most 4 outcome-phrased progress bullets, every risk with likelihood\u002Fimpact\u002Fmitigation plus the disposition of last week's risks, at most 2 asks each with a decider and a date, and Looking Ahead only when the two-week trigger applies - the whole document readable in under 90 seconds.\n\n## Do NOT\n\n- Do not list activities (\"worked on\", \"continued\", \"made progress\") - every progress bullet states an outcome or a position against a date.\n- Do not omit the risks section or leave it vague to look in control; a no-risk rollup reads as a no-look rollup.\n- Do not let a previously reported risk vanish without an explicit close-out line.\n- Do not send more than 2 asks, and never send an ask without a named decider and a date - undated asks are FYIs, and FYIs get ignored.\n- Do not include velocity charts, story-point counts, or sprint burndowns; they demand context the reader doesn't have and invite the wrong conversation.\n- Do not deliver verbally first. The written version leads; the sync discusses it.\n\n## Quality bar\n\n- Scannable in under 90 seconds by someone with zero project context.\n- Every claim is either verified or labeled unconfirmed - no rounding up to green.\n- Section caps respected: 4 progress bullets, 2 asks, 3 Looking Ahead bullets.\n- Each risk has all four fields; each ask has a decider and a date.\n- No acronym or internal codename appears without a plain-language gloss.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Eng Status Rollup","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Feng-status-rollup",3,"https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills","https:\u002F\u002Fskillme.dev","https:\u002F\u002Fgithub.com\u002FSkillMedev","MCP-native catalog of Claude Agent Skills. Browse, recommend, install, and auto-apply skills in chat. Open source, every skill free and clonable on GitHub.","2026-10-14 03:19:31",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add SkillMedev\u002Fskills --skill eng-status-rollup",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill eng-status-rollup",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill eng-status-rollup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Feng-status-rollup\u002FSKILL.md",true,[],[50,58,65,72,79,86],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":57},"01M75271B256DF3FX2VG5VRYEE","zone-2-cardio-plan","Use when someone asks to build a steady-state cardio plan, train an aerobic base or Zone 2, structure easy or endurance weekly cardio, train by heart-rate zones, or improve resting heart rate, VO2, or endurance. Builds a heart-rate-zone aerobic training block with session structure, modality choice, and progression. General fitness guidance, not medical advice. Do NOT use to design a strength or lifting program (use Strength Training Plan), high-intensity interval conditioning, HIIT, or circuits (use Conditioning & HIIT Program), or a mobility\u002Fflexibility routine (use Mobility Routine).","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":57},"01M7526VP1QBBKYBE17S1WR86Y","youtube-script-writer","Writes retention-engineered long-form YouTube scripts on a hook\u002Fbody\u002Fpayoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says \"script my next video\", \"my retention graph dies at the start\", \"tighten this draft\", or \"outline a video on X\". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-writer\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":57},"01M7526P2T0WKMHDXS4Q58237T","win-back-campaign","Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says \"our users went quiet\", \"design a win-back campaign\", \"how do I re-engage lapsed customers\", \"should we email people who haven't logged in for months\", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwin-back-campaign\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":57},"01M7526HF2RCDJ50P93WRZRHVV","wikipedia-style","Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks \"write this like a Wikipedia article\", \"draft a Wikipedia page for this company or person\", \"make this neutral and encyclopedic\", or \"why does my article draft keep getting rejected\". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwikipedia-style\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":57},"01M7526D43CTGRKGKNQ2GB0KVX","whitepapers","Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks \"write a whitepaper on this topic\", \"turn our research into a lead-gen asset\", \"make this credible enough for executives\", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhitepapers\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":57},"01M75268423Y3K50SY5WC2NX2G","white-space-analysis","Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks \"where are the gaps in this market\", \"what's underserved here\", \"where should we play next\", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhite-space-analysis\u002FSKILL.md",[],[]]