[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751VGDKMKYP7KVD3GDK9HX7":3,"skill-same:01M751VGDKMKYP7KVD3GDK9HX7":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},"01M751VGDKMKYP7KVD3GDK9HX7","sprint-retro-facilitator",null,"Structures and facilitates sprint retrospectives with a timeboxed agenda, format selection, anti-blame ground rules, and owned action items that actually close. Use when someone asks \"help me run our retro\", \"our retros produce the same actions every sprint\", \"what format should this retrospective use\", or \"how do I get the team to say what they're really thinking\". Do NOT use for incident postmortems with a timeline and root-cause analysis - use postmortem-writer instead. For diagnosing chronic team dysfunction beyond one sprint, use team-health-check; for planning the next sprint's scope, use sprint-planning.","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\u002Fsprint-retro-facilitator\u002FSKILL.md",[],[],"2026-11-11 18:22:23",false,"---\nname: sprint-retro-facilitator\ndescription: Structures and facilitates sprint retrospectives with a timeboxed agenda, format selection, anti-blame ground rules, and owned action items that actually close. Use when someone asks \"help me run our retro\", \"our retros produce the same actions every sprint\", \"what format should this retrospective use\", or \"how do I get the team to say what they're really thinking\". Do NOT use for incident postmortems with a timeline and root-cause analysis - use postmortem-writer instead. For diagnosing chronic team dysfunction beyond one sprint, use team-health-check; for planning the next sprint's scope, use sprint-planning.\nmetadata:\n  title: \"Sprint Retro Facilitator\"\n---\n\n# Sprint Retro Facilitator\n\nMost retros produce the same three actions every sprint and close none of them, which teaches the team that speaking up changes nothing - the most expensive lesson a team can learn. This skill forces specificity, surfaces the issues people are actually thinking, and ends with someone's name on every action.\n\n## Inputs to collect\n\nBefore the session, gather:\n\n1. Previous retro's action items and their real status (done \u002F in progress \u002F dropped). Non-negotiable - see Step 1.\n2. Sprint facts: what shipped, what slipped, any incidents. Facts anchor discussion away from vibes.\n3. Team mood signal, if you have one (a one-question pulse, or your own read). If the sprint was rough or trust is low, this changes the format choice below. Label your read as a guess if it is one.\n4. Session length. Default 60 minutes maximum; 45 is better. Below 30, cut the discussion topics to one, not the timeboxes.\n\n## Choose the format\n\nRotate formats every 3-4 sprints - any format run ten sprints straight produces autopilot answers. Pick by situation:\n\n- **Start \u002F Stop \u002F Continue** - the default. Fast, action-oriented, works when the sprint was unremarkable.\n- **4Ls (Liked \u002F Learned \u002F Lacked \u002F Longed for)** - after sprints with heavy learning or new territory; surfaces knowledge gaps, not just process complaints.\n- **Sailboat (wind \u002F anchors \u002F rocks \u002F island)** - when the team is stuck in short-term firefighting and needs to reconnect actions to a goal; the \"rocks\" column surfaces risks nobody has said aloud.\n- **Mad \u002F Sad \u002F Glad** - after a rough or emotionally loaded sprint (a failed launch, a departure). Gives feelings a legitimate column so they do not leak sideways into every topic.\n\nWhatever the format, open by stating the anti-blame ground rule in your own words: everyone did the best job they could given what they knew, their skills, and the situation at the time. The retro examines the system that produced the outcome, not the people. Say it every time, not just when things went badly - the sprint it goes unsaid is the sprint someone gets blamed.\n\n## Timeboxed agenda (60 minutes)\n\nRun the phases in order and hold the timeboxes; a timer visible to everyone works better than the facilitator interrupting.\n\n### 1. Review previous actions (10 min)\n\nOpen with the status of last retro's action items: done, in progress, or dropped. If more than half were dropped, say so plainly - that is itself a retro topic, and it outranks whatever else is on the board. Appoint a note-taker who is not the facilitator.\n\n### 2. Gather data - silent brainstorm (15 min)\n\nIndividuals write items on sticky notes or a shared board without seeing each other's input first. This prevents the most vocal person from anchoring the group; it is the single highest-leverage facilitation move in the session. Prompt with three columns: \"What slowed us down?\", \"What went well that we should protect?\", and \"What are we not saying out loud?\" The third column is the most valuable and the most often skipped - keep it even when using a named format above.\n\n### 3. Dot-vote and cluster (5 min)\n\nGive each person exactly 3 votes. Cluster near-duplicate items before voting closes. The top 2-3 clusters by votes become the discussion topics - the group's actual priorities, not the facilitator's.\n\n### 4. Discussion (20 min)\n\nFor each topic, in order:\n\n1. State the observation as a system problem, not a person problem. \"Reviews sat for two days\" - not \"Sam is slow at reviews.\"\n2. Ask \"what made this likely to happen?\" before \"what should we do?\" Solutioning first locks in the shallowest diagnosis.\n3. Root-cause at least one level deeper than the surface complaint. If the answer is \"we need better communication,\" that is not a root cause - push for the structural or process condition that produced the failure (\"nobody is on point for reviews after 3pm\" is actionable; \"communicate better\" is not).\n\nIf discussion turns to a named individual, redirect to the condition that let the failure happen - this is the anti-blame rule doing its job.\n\n### 5. Action items (10 min)\n\nEvery action needs three fields, no exceptions: **what** exactly will change, **who** owns it (one name, never \"the team\"), and **when** it will be done or reviewed. Cap actions at 3 per retro - more than 3 almost never close. If there are more candidates, vote for the top 3 and park the rest in a visible backlog. An action a single person can complete within one sprint beats a grand initiative every time.\n\n## Worked contrast\n\n**Bad action:** \"Improve our deployment process.\" (No owner, no date, no defined change - it will appear again next retro, verbatim.)\n\n**Good action:** \"Priya adds a staging smoke-test step to the deploy pipeline by Thursday the 12th; we review whether deploy rollbacks dropped at the next retro.\"\n\n## Deliverable\n\nProduce a retro packet: the chosen format with a one-line rationale, the timeboxed agenda with clock times filled in, the three brainstorm prompts, the anti-blame opener script, and - after the session - the action list with what\u002Fwho\u002Fwhen per item plus the status ledger of the previous retro's actions.\n\n## Do NOT\n\n- Do not skip reviewing previous actions - it is the only mechanism that makes retros compound instead of repeat.\n- Do not open discussion before the silent brainstorm - the first speaker anchors everyone else's list.\n- Do not accept \"the team\" as an owner - diffuse ownership is no ownership.\n- Do not let a root-cause stop at \"better communication\" or \"be more careful\" - those are restatements of the failure, not causes.\n- Do not exceed 3 actions to seem thorough - a closed action beats three open ones.\n- Do not run a retro on a SEV or outage - that is a postmortem with a timeline and contributing factors; use postmortem-writer.\n\n## Quality bar\n\n- Every action item has one named owner and a date; zero actions assigned to \"the team.\"\n- At least one discussion topic came from votes, not from the facilitator or the manager.\n- Each discussed topic reached a structural cause at least one level below the surface complaint.\n- The anti-blame ground rule was stated aloud at the open.\n- Previous retro's actions were reviewed first, with a plain-spoken dropped count.\n\n## Escalation\n\nIf the same item appears in three consecutive retros with no progress, escalate it outside the retro - it is either blocked by something beyond the team's control or nobody actually owns it. Name both possibilities explicitly to the team and take it to whoever can unblock it. If retro after retro surfaces the same interpersonal friction, that is a team-health problem, not a process problem - move to team-health-check or conflict-resolution rather than another format rotation.\n","# Sprint Retro Facilitator\n\nMost retros produce the same three actions every sprint and close none of them, which teaches the team that speaking up changes nothing - the most expensive lesson a team can learn. This skill forces specificity, surfaces the issues people are actually thinking, and ends with someone's name on every action.\n\n## Inputs to collect\n\nBefore the session, gather:\n\n1. Previous retro's action items and their real status (done \u002F in progress \u002F dropped). Non-negotiable - see Step 1.\n2. Sprint facts: what shipped, what slipped, any incidents. Facts anchor discussion away from vibes.\n3. Team mood signal, if you have one (a one-question pulse, or your own read). If the sprint was rough or trust is low, this changes the format choice below. Label your read as a guess if it is one.\n4. Session length. Default 60 minutes maximum; 45 is better. Below 30, cut the discussion topics to one, not the timeboxes.\n\n## Choose the format\n\nRotate formats every 3-4 sprints - any format run ten sprints straight produces autopilot answers. Pick by situation:\n\n- **Start \u002F Stop \u002F Continue** - the default. Fast, action-oriented, works when the sprint was unremarkable.\n- **4Ls (Liked \u002F Learned \u002F Lacked \u002F Longed for)** - after sprints with heavy learning or new territory; surfaces knowledge gaps, not just process complaints.\n- **Sailboat (wind \u002F anchors \u002F rocks \u002F island)** - when the team is stuck in short-term firefighting and needs to reconnect actions to a goal; the \"rocks\" column surfaces risks nobody has said aloud.\n- **Mad \u002F Sad \u002F Glad** - after a rough or emotionally loaded sprint (a failed launch, a departure). Gives feelings a legitimate column so they do not leak sideways into every topic.\n\nWhatever the format, open by stating the anti-blame ground rule in your own words: everyone did the best job they could given what they knew, their skills, and the situation at the time. The retro examines the system that produced the outcome, not the people. Say it every time, not just when things went badly - the sprint it goes unsaid is the sprint someone gets blamed.\n\n## Timeboxed agenda (60 minutes)\n\nRun the phases in order and hold the timeboxes; a timer visible to everyone works better than the facilitator interrupting.\n\n### 1. Review previous actions (10 min)\n\nOpen with the status of last retro's action items: done, in progress, or dropped. If more than half were dropped, say so plainly - that is itself a retro topic, and it outranks whatever else is on the board. Appoint a note-taker who is not the facilitator.\n\n### 2. Gather data - silent brainstorm (15 min)\n\nIndividuals write items on sticky notes or a shared board without seeing each other's input first. This prevents the most vocal person from anchoring the group; it is the single highest-leverage facilitation move in the session. Prompt with three columns: \"What slowed us down?\", \"What went well that we should protect?\", and \"What are we not saying out loud?\" The third column is the most valuable and the most often skipped - keep it even when using a named format above.\n\n### 3. Dot-vote and cluster (5 min)\n\nGive each person exactly 3 votes. Cluster near-duplicate items before voting closes. The top 2-3 clusters by votes become the discussion topics - the group's actual priorities, not the facilitator's.\n\n### 4. Discussion (20 min)\n\nFor each topic, in order:\n\n1. State the observation as a system problem, not a person problem. \"Reviews sat for two days\" - not \"Sam is slow at reviews.\"\n2. Ask \"what made this likely to happen?\" before \"what should we do?\" Solutioning first locks in the shallowest diagnosis.\n3. Root-cause at least one level deeper than the surface complaint. If the answer is \"we need better communication,\" that is not a root cause - push for the structural or process condition that produced the failure (\"nobody is on point for reviews after 3pm\" is actionable; \"communicate better\" is not).\n\nIf discussion turns to a named individual, redirect to the condition that let the failure happen - this is the anti-blame rule doing its job.\n\n### 5. Action items (10 min)\n\nEvery action needs three fields, no exceptions: **what** exactly will change, **who** owns it (one name, never \"the team\"), and **when** it will be done or reviewed. Cap actions at 3 per retro - more than 3 almost never close. If there are more candidates, vote for the top 3 and park the rest in a visible backlog. An action a single person can complete within one sprint beats a grand initiative every time.\n\n## Worked contrast\n\n**Bad action:** \"Improve our deployment process.\" (No owner, no date, no defined change - it will appear again next retro, verbatim.)\n\n**Good action:** \"Priya adds a staging smoke-test step to the deploy pipeline by Thursday the 12th; we review whether deploy rollbacks dropped at the next retro.\"\n\n## Deliverable\n\nProduce a retro packet: the chosen format with a one-line rationale, the timeboxed agenda with clock times filled in, the three brainstorm prompts, the anti-blame opener script, and - after the session - the action list with what\u002Fwho\u002Fwhen per item plus the status ledger of the previous retro's actions.\n\n## Do NOT\n\n- Do not skip reviewing previous actions - it is the only mechanism that makes retros compound instead of repeat.\n- Do not open discussion before the silent brainstorm - the first speaker anchors everyone else's list.\n- Do not accept \"the team\" as an owner - diffuse ownership is no ownership.\n- Do not let a root-cause stop at \"better communication\" or \"be more careful\" - those are restatements of the failure, not causes.\n- Do not exceed 3 actions to seem thorough - a closed action beats three open ones.\n- Do not run a retro on a SEV or outage - that is a postmortem with a timeline and contributing factors; use postmortem-writer.\n\n## Quality bar\n\n- Every action item has one named owner and a date; zero actions assigned to \"the team.\"\n- At least one discussion topic came from votes, not from the facilitator or the manager.\n- Each discussed topic reached a structural cause at least one level below the surface complaint.\n- The anti-blame ground rule was stated aloud at the open.\n- Previous retro's actions were reviewed first, with a plain-spoken dropped count.\n\n## Escalation\n\nIf the same item appears in three consecutive retros with no progress, escalate it outside the retro - it is either blocked by something beyond the team's control or nobody actually owns it. Name both possibilities explicitly to the team and take it to whoever can unblock it. If retro after retro surfaces the same interpersonal friction, that is a team-health problem, not a process problem - move to team-health-check or conflict-resolution rather than another format rotation.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Sprint Retro Facilitator","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fsprint-retro-facilitator",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 sprint-retro-facilitator",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill sprint-retro-facilitator",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill sprint-retro-facilitator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-retro-facilitator\u002FSKILL.md",true,[],[50,60,67,74,81,88],{"skillNo":51,"name":52,"nameZh":53,"description":54,"descriptionZh":55,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":59},"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).","当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性\u002F柔韧性训练（请使用灵活性训练计划）。","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":59},"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":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":59},"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":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":59},"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":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":87,"publishedAt":59},"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":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":94,"publishedAt":59},"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",[],[]]