본문으로 건너뛰기
cccskills
무료GitHub에 공개

async-instead

Convert a meeting into async work that actually decides — the doc-plus-deadline format that replaces the room, the comment-window rules, the decision-closure step that async usually fumbles, and the honest test for what still needs synchronous. Use when asked can this meeting be async, replace our status meeting with a doc, run this decision without a call, or async isn't working for us. Produces the conversion design, the async artifact format, the closure protocol, and the still-needs-a-room list.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md5.4 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Async Instead Skill

"This meeting could have been an email" is true more often than the email would have worked — because async fails without structure: the doc nobody read, the thread that discussed forever and decided never. A working conversion replaces the meeting's functions, not just its slot: information transfer becomes a doc with a read-by date; discussion becomes a bounded comment window; decision becomes an explicit closure step with a named decider and a deadline — the part async most often fumbles and the part this skill enforces. And some things genuinely need rooms; the honest list is part of the design.

What This Skill Produces

  • The conversion design — the meeting's functions mapped to async mechanisms, with owners and deadlines
  • The artifact format — the update-doc or decision-doc template that carries the load
  • The closure protocol — how the async thread ends: the decider, the deadline, the decision recorded
  • The still-sync list — what this meeting does that async can't, and the smaller room that remains

Required Inputs

Ask for these if not provided:

  • The meeting being converted — its functions in honest proportion (how much status vs. discussion vs. decision vs. the social glue)
  • The team's async maturity — do docs get read here? Are comment deadlines respected? Conversion designs differ for teams with and without the muscle (and building the muscle starts smaller)
  • The tools — where docs live, where comments happen, where decisions get recorded; the design uses the real stack
  • The failure history — if async was tried and died, the autopsy (nobody read? never decided? discussion sprawled?) — the design patches the specific failure

Framework: The Conversion Rules

  1. Map functions, not the slot: status → the written update (structured, skimmable, due Wednesday); discussion → the comment window (open Thursday–Friday); decision → the closure step (decider decides Monday, recorded). A meeting is usually three functions braided; async unbraids them, and each gets its own deadline.
  2. The doc has a format and a due-date: free-form updates sprawl; the template (template-designer rules: prompting placeholders, lighter than the meeting) plus a hard read-by/comment-by window is what separates async-that-works from a shared doc with hopes.
  3. Closure is explicit or async fails: every async decision names its decider and its deadline up front — "comments until Friday; [name] decides Monday; silence is assent" — because threads without closure rules discuss until the decision gets made in a hallway anyway, discrediting the whole conversion. Decisions land in the decision log, not just the thread.
  4. Silence must mean something, declared: assent, abstention, or blocking-requires-speaking — chosen per decision's stakes and stated in the doc. Undeclared silence is why async decisions get relitigated by people who "never agreed."
  5. The still-sync list is honest: genuine debate with high disagreement, sensitive feedback, creative jamming, relationship glue, and true emergencies — these keep a room, usually a smaller and shorter one than the meeting being converted ("the weekly hour becomes: async status + a 20-minute discussion slot that only fires when the comment window surfaced real conflict"). Conversions that pretend everything asyncs get reversed within a quarter.

Output Format

Async Conversion: [meeting] → [the design]

Function Map

Function (share of old meeting)Async mechanismDeadlineOwner

The Artifact

[The doc format with prompts · where it lives · the read/comment window]

Closure Protocol

[Decider · deadline · silence-means · where decisions get recorded]

Still Sync

[What keeps a room · the smaller residual slot and its fires-only-when trigger]

Quality Checks

  • Every function of the old meeting maps to a mechanism with a deadline
  • The doc is templated and lighter than the meeting it replaces
  • Every decision names decider, deadline, and silence-meaning up front
  • Decisions land in a durable log, not just the thread
  • The still-sync list is honest and its residual room is smaller, not parallel

Anti-Patterns

  • Do not convert by cancelling the meeting and hoping — the functions need explicit new homes
  • Do not run async discussion without a window — unbounded threads are meetings that never end
  • Do not skip the closure step — async that can't decide trains everyone to book rooms again
  • Do not leave silence undefined — "nobody objected" and "nobody read it" look identical without the rule
  • Do not async the genuinely synchronous — one failed forced conversion discredits ten good ones

Example Trigger Phrases

  • "Can this meeting be async?"
  • "Replace our status meeting with a doc."
  • "Run this decision without a call."

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

mohitagw15856/pm-claude-skills1.5천2026년 10월 21일 업데이트

Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

mohitagw15856/pm-claude-skills1.5천2026년 10월 21일 업데이트

Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

mohitagw15856/pm-claude-skills1.5천2026년 10월 21일 업데이트

Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

mohitagw15856/pm-claude-skills1.5천2026년 10월 21일 업데이트

Build or tailor an academic CV for faculty, postdoc, research or fellowship applications: publications, grants, teaching, supervision and service in the order the field expects, with consistent citations. Use when asked to write my academic CV, update my CV for a lectureship, tenure-track or postdoc application, format my publications list, or adapt my academic CV for an industry research role. Produces the full academic CV, a field-appropriate section order, a clean publications list in one citation style, and a two-page summary version when asked.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

mohitagw15856/pm-claude-skills1.5천2026년 10월 21일 업데이트

Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

mohitagw15856/pm-claude-skills1.5천2026년 10월 21일 업데이트

mohitagw15856의 스킬 모두 보기

이 스킬의 문제 신고