async_communication v1.0.0

name: async-communication description: Run a team async-first: write for timezones, run decision threads instead of meetings, set response norms, and replace status meetings with docs. Use when a team needs async communication practices, meeting replacement plans, or decision-by-writing processes. metadata: { "includeInPrompt": true }

Async Communication

Purpose

Make a team work without everyone being awake at the same time. Decisions happen in written threads, status comes from docs not calls, and meetings are the last resort instead of the default. Works for remote teams and for hybrid teams that want remote members to have the same information as people in the room.

Workflow

1. Run the async test. Before scheduling anything, ask: "Could we handle this asynchronously for everyone's benefit?" If yes, write it up instead of meeting. GitLab's version of this question: "How would I deliver this information if no one on my team were awake?"
2. Set response norms. Agree on reply SLAs in writing (a common baseline: under 24 hours for messages, 48-hour windows for proposal feedback). Post them where everyone sees them. Async without a response promise just becomes silence.
3. Write decisions as threads, not meetings. For any decision worth revisiting later, open a written proposal using the decision thread template in references/templates.md. One person owns the final call and the deadline. Record the outcome AND the rationale: future teammates need to know why, not just what.
4. Replace each recurring meeting with its async equivalent. Map the calendar: standup -> async standup thread (done / next / blockers, posted by a fixed time), status meeting -> written weekly update in the project tool, brainstorm -> shared doc with ideas collected over 2-3 days, update call -> 5-minute recorded video. See the full mapping in references/templates.md.
5. Write messages that don't need a reply-clarification round. Every async message carries its own context: what happened, the relevant links, the specific question or ask, and the deadline for input. A message that takes one read to understand is the whole job.
6. Review monthly. Check: are standups consistent (inconsistent ones die within a month)? Are decision threads being found and cited? Is anyone still holding decisions in chat threads nobody can find? Adjust the norms, don't abandon them.

Output Contract

When asked to produce async communication material, deliver artifacts that fit the template in references/templates.md, and always include:

• the response SLA being assumed (or a note that none exists yet),
• a named decision owner and a feedback deadline on any proposal,
• the rationale recorded with the decision, not just the verdict,
• where the artifact lives (channel, doc, or repo path) so it can be found later.

Operating Rules

1. Default to public channels and shared docs. A decision made in a private thread three people were in is a future bug.
2. Meetings are fine for brainstorming energy, conflict, and celebration. Anything that must be referenceable later goes in writing, even if it started on a call.
3. If a call did happen, the call is not the record. Post the summary with decisions, action items, and owners the same day.
4. Video is a tool for complex explanation (3-5 minute recorded walkthrough), not a substitute for a written decision record.
5. Never schedule a meeting to "prepare background materials" for another meeting. The doc is the meeting.
6. Treat message quality as the metric: one read to understand, zero clarification rounds.