[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74ZX5HWS58J4E8PM5PS2RKN":3,"skill-same:01M74ZX5HWS58J4E8PM5PS2RKN":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},"01M74ZX5HWS58J4E8PM5PS2RKN","async-communication",null,"Converts sync meetings and vague pings into structured asynchronous messages - TL;DR up front, an explicit ask with owner and deadline, and a default-action line that keeps work moving if nobody replies - plus team response norms per channel. Use when someone asks \"how do I say this without a meeting\", \"rewrite this message so people actually respond\", \"help my remote team stop living on calls\", or \"draft an async decision doc\". Do NOT use for the recurring exec status update itself - use eng-status-rollup instead - for extracting actions from a meeting that already happened - use meeting-notes-to-actions instead - or for designing the meeting you do keep - use meeting-agenda 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\u002Fasync-communication\u002FSKILL.md",[],[],"2026-11-11 17:59:50",false,"---\nname: async-communication\ndescription: Converts sync meetings and vague pings into structured asynchronous messages - TL;DR up front, an explicit ask with owner and deadline, and a default-action line that keeps work moving if nobody replies - plus team response norms per channel. Use when someone asks \"how do I say this without a meeting\", \"rewrite this message so people actually respond\", \"help my remote team stop living on calls\", or \"draft an async decision doc\". Do NOT use for the recurring exec status update itself - use eng-status-rollup instead - for extracting actions from a meeting that already happened - use meeting-notes-to-actions instead - or for designing the meeting you do keep - use meeting-agenda instead.\nmetadata:\n  title: \"Async Communication\"\n---\n\n# Async Communication\n\nAsync lets distributed teams move without living on calendars, but the trade is real: it demands writing clear enough that the reader can act without a reply loop. The costly failure is the dead thread - a message with no explicit ask, no deadline, and no default, which stalls the work while everyone assumes someone else will respond. Every rule below exists to prevent that thread.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\n- What the sender actually wants from the reader - a decision, a review, an FYI, or an action. If they cannot name it in one sentence, that is the first fix.\n- Who must act, who merely needs to know, and the real deadline.\n- The team's time-zone spread and existing channel conventions, if any.\n- The message or meeting being replaced, when rewriting.\n\nLabel assumptions as assumptions (\"assuming Legal doesn't need to sign off on this\").\n\n### Step 2: decide sync vs async\n\nDefault to async when any of these holds: the topic is informational (status, FYI, announcement); the decision benefits from reflection time; participants span time zones; or a written record matters later.\n\nReserve sync for exactly four cases: high-emotion conversations, fast-moving brainstorms, relationship building, and genuine deadlock after at least one async attempt. \"This is faster to explain live\" is usually a sign the sender hasn't done the thinking yet - writing it forces the thinking.\n\n### Step 3: structure the message\n\nEvery non-trivial message follows this pattern so the reader can act without a reply loop:\n\n```\nTL;DR: [FILL: one line - what you want from the reader]\n\nContext: [FILL: why this is coming up - 2-3 sentences, max]\n\nDetails: [FILL: the substance; link out rather than inline anything long]\n\nDecision\u002FAction needed:\n- [FILL: specific ask] - owner: [FILL: name] - by: [FILL: date]\n\nDefault: [FILL: what happens if no one responds by the deadline]\n```\n\nThe default line is the secret weapon: \"If I don't hear back by Friday EOD, I'll proceed with option B.\" It converts silence from a blocker into a signal, keeps work moving, and respects everyone's time. A message that needs a response but has no default line is a hostage to its slowest reader.\n\n### Step 4: apply the writing rules\n\n- Front-load the ask; the reader knows what is wanted from line one.\n- Be self-contained: link or restate context so zero back-and-forth is needed to start.\n- Set explicit deadlines. \"Soon\" and \"when you get a chance\" guarantee never.\n- Pick the channel by artifact life: chat for quick and ephemeral, docs for decisions that need a record, issues\u002Ftickets for trackable work. A decision made in chat is a decision that will be re-litigated.\n- Over-communicate tone. Without faces and voices, neutral reads as cold - add one line of warmth and assume good intent when reading.\n- Length check: if the ask takes more than one screen to state, split the decision doc from the notification message that links to it.\n\n### Step 5: replace the meeting, not just the invite\n\nMap each recurring meeting to its async form:\n\n- Status meeting → written standup: each person posts done \u002F doing \u002F blocked on a fixed daily deadline.\n- Decision meeting → decision doc: options, a recommendation, comments requested by a named date, then the decider decides. Escalate to a live call only if the thread deadlocks after one full round.\n- Brainstorm → seeded idea doc open for 24 hours, then a short sync to converge only if needed.\n- 1:1 → rolling shared doc for topics, keeping occasional live time for the human conversation - do not fully async the relationship.\n\n### Step 6: set team response norms\n\nNorms only work when agreed, written, and visible - not assumed. Defaults to propose: chat gets a same-working-day response; email and doc comments get 24 hours; anything urgent enough to need under an hour is a phone call, not a ping. Working-hours badges and Do-Not-Disturb are respected without justification. Threads, not new channel messages, keep topics navigable.\n\n## Worked contrast\n\nBad:\n\n```\nhey, do you have a sec to hop on a quick call about the vendor thing?\n```\n\nThe reader must reply just to learn the topic, the urgency, and whether they are the right person - three round trips before substance, likely across time zones.\n\nGood:\n\n```\nTL;DR: Need your yes\u002Fno on switching to Vendor B by Thu EOD.\n\nContext: Vendor A raised renewal pricing 40%. B matches our current cost\nand passed the security review last month.\n\nDetails: comparison doc - [link]. Migration effort is ~2 days, owned by my team.\n\nDecision needed:\n- Approve switch to Vendor B - owner: you - by: Thu EOD\n\nDefault: no response by Thu EOD = I proceed with Vendor B before the\nFriday renewal deadline.\n```\n\nSame request, zero round trips: the reader can decide from the message alone, and silence has a defined meaning.\n\n## Deliverable\n\nProduce one or more of: a rewritten async message in the five-part pattern (TL;DR, context, details, ask with owner and date, default); a meeting-to-async conversion plan naming the replacement format per meeting; or a one-page team response-norms agreement with per-channel windows.\n\n## Do NOT\n\n- Do not send an ask without a deadline and a default - that message starts the dead thread this skill exists to prevent.\n- Do not \"quick call?\" something expressible in two written sentences; each unnecessary sync call taxes every attendee's calendar and time zone.\n- Do not post walls of text with no TL;DR - readers bounce, then answer only the last question they saw.\n- Do not mark everything urgent. Urgency inflation destroys the signal for the message that genuinely is.\n- Do not make decisions in chat; move them to a doc, or accept re-litigating them monthly.\n- Do not async conflict or emotionally loaded feedback - tone loss turns a hard conversation into a worse one. That is one of the four legitimate sync cases.\n\n## Quality bar\n\n- The ask is in the first line, and a stranger to the project could act on the message without asking a clarifying question.\n- Every request carries an owner, a date, and a default action on silence.\n- The channel matches the artifact's lifespan (ephemeral → chat, decision → doc, work → ticket).\n- Tone includes at least one deliberate line of warmth.\n- Any proposed norms are written as a shareable agreement, not implied.\n","# Async Communication\n\nAsync lets distributed teams move without living on calendars, but the trade is real: it demands writing clear enough that the reader can act without a reply loop. The costly failure is the dead thread - a message with no explicit ask, no deadline, and no default, which stalls the work while everyone assumes someone else will respond. Every rule below exists to prevent that thread.\n\n## Operating procedure\n\n### Step 1: gather inputs\n\n- What the sender actually wants from the reader - a decision, a review, an FYI, or an action. If they cannot name it in one sentence, that is the first fix.\n- Who must act, who merely needs to know, and the real deadline.\n- The team's time-zone spread and existing channel conventions, if any.\n- The message or meeting being replaced, when rewriting.\n\nLabel assumptions as assumptions (\"assuming Legal doesn't need to sign off on this\").\n\n### Step 2: decide sync vs async\n\nDefault to async when any of these holds: the topic is informational (status, FYI, announcement); the decision benefits from reflection time; participants span time zones; or a written record matters later.\n\nReserve sync for exactly four cases: high-emotion conversations, fast-moving brainstorms, relationship building, and genuine deadlock after at least one async attempt. \"This is faster to explain live\" is usually a sign the sender hasn't done the thinking yet - writing it forces the thinking.\n\n### Step 3: structure the message\n\nEvery non-trivial message follows this pattern so the reader can act without a reply loop:\n\n```\nTL;DR: [FILL: one line - what you want from the reader]\n\nContext: [FILL: why this is coming up - 2-3 sentences, max]\n\nDetails: [FILL: the substance; link out rather than inline anything long]\n\nDecision\u002FAction needed:\n- [FILL: specific ask] - owner: [FILL: name] - by: [FILL: date]\n\nDefault: [FILL: what happens if no one responds by the deadline]\n```\n\nThe default line is the secret weapon: \"If I don't hear back by Friday EOD, I'll proceed with option B.\" It converts silence from a blocker into a signal, keeps work moving, and respects everyone's time. A message that needs a response but has no default line is a hostage to its slowest reader.\n\n### Step 4: apply the writing rules\n\n- Front-load the ask; the reader knows what is wanted from line one.\n- Be self-contained: link or restate context so zero back-and-forth is needed to start.\n- Set explicit deadlines. \"Soon\" and \"when you get a chance\" guarantee never.\n- Pick the channel by artifact life: chat for quick and ephemeral, docs for decisions that need a record, issues\u002Ftickets for trackable work. A decision made in chat is a decision that will be re-litigated.\n- Over-communicate tone. Without faces and voices, neutral reads as cold - add one line of warmth and assume good intent when reading.\n- Length check: if the ask takes more than one screen to state, split the decision doc from the notification message that links to it.\n\n### Step 5: replace the meeting, not just the invite\n\nMap each recurring meeting to its async form:\n\n- Status meeting → written standup: each person posts done \u002F doing \u002F blocked on a fixed daily deadline.\n- Decision meeting → decision doc: options, a recommendation, comments requested by a named date, then the decider decides. Escalate to a live call only if the thread deadlocks after one full round.\n- Brainstorm → seeded idea doc open for 24 hours, then a short sync to converge only if needed.\n- 1:1 → rolling shared doc for topics, keeping occasional live time for the human conversation - do not fully async the relationship.\n\n### Step 6: set team response norms\n\nNorms only work when agreed, written, and visible - not assumed. Defaults to propose: chat gets a same-working-day response; email and doc comments get 24 hours; anything urgent enough to need under an hour is a phone call, not a ping. Working-hours badges and Do-Not-Disturb are respected without justification. Threads, not new channel messages, keep topics navigable.\n\n## Worked contrast\n\nBad:\n\n```\nhey, do you have a sec to hop on a quick call about the vendor thing?\n```\n\nThe reader must reply just to learn the topic, the urgency, and whether they are the right person - three round trips before substance, likely across time zones.\n\nGood:\n\n```\nTL;DR: Need your yes\u002Fno on switching to Vendor B by Thu EOD.\n\nContext: Vendor A raised renewal pricing 40%. B matches our current cost\nand passed the security review last month.\n\nDetails: comparison doc - [link]. Migration effort is ~2 days, owned by my team.\n\nDecision needed:\n- Approve switch to Vendor B - owner: you - by: Thu EOD\n\nDefault: no response by Thu EOD = I proceed with Vendor B before the\nFriday renewal deadline.\n```\n\nSame request, zero round trips: the reader can decide from the message alone, and silence has a defined meaning.\n\n## Deliverable\n\nProduce one or more of: a rewritten async message in the five-part pattern (TL;DR, context, details, ask with owner and date, default); a meeting-to-async conversion plan naming the replacement format per meeting; or a one-page team response-norms agreement with per-channel windows.\n\n## Do NOT\n\n- Do not send an ask without a deadline and a default - that message starts the dead thread this skill exists to prevent.\n- Do not \"quick call?\" something expressible in two written sentences; each unnecessary sync call taxes every attendee's calendar and time zone.\n- Do not post walls of text with no TL;DR - readers bounce, then answer only the last question they saw.\n- Do not mark everything urgent. Urgency inflation destroys the signal for the message that genuinely is.\n- Do not make decisions in chat; move them to a doc, or accept re-litigating them monthly.\n- Do not async conflict or emotionally loaded feedback - tone loss turns a hard conversation into a worse one. That is one of the four legitimate sync cases.\n\n## Quality bar\n\n- The ask is in the first line, and a stranger to the project could act on the message without asking a clarifying question.\n- Every request carries an owner, a date, and a default action on silence.\n- The channel matches the artifact's lifespan (ephemeral → chat, decision → doc, work → ticket).\n- Tone includes at least one deliberate line of warmth.\n- Any proposed norms are written as a shareable agreement, not implied.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Async Communication","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fasync-communication",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 async-communication",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill async-communication",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill async-communication","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fasync-communication\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",[],[]]