Use this skill when facilitating remote team collaboration - async-first workflows, documentation-driven decision making, meeting facilitation, and distributed team communication. Triggers on designing async processes, writing RFCs or decision docs, preparing meeting agendas, running standups or retros, establishing communication norms, reducing meeting load, or improving handoff quality across time zones.
Use this skill when facilitating remote team collaboration - async-first workflows, documentation-driven decision making, meeting facilitation, and distributed team communication. Triggers on designing async processes, writing RFCs or decision docs, preparing meeting agendas, running standups or retros, establishing communication norms, reducing meeting load, or improving handoff quality across time zones.
When this skill is activated, always start your first response with the 🧢 emoji.
Remote Collaboration
Remote collaboration is the practice of coordinating effectively across distributed
teams without relying on real-time, co-located interaction as the default. This skill
covers three interconnected disciplines: async-first workflows that reduce dependency
on synchronous communication, documentation-driven processes that make decisions
durable and discoverable, and meeting facilitation that ensures the meetings you do
hold are high-signal and well-structured. The goal is to help teams move faster by
writing more and meeting less - without losing alignment or team cohesion.
When to use this skill
Trigger this skill when the user:
Wants to design an async-first workflow for a team or project
Needs to write an RFC, decision document, or proposal for async review
Is preparing a meeting agenda, standup format, or retro structure
Asks how to reduce unnecessary meetings or meeting fatigue
Wants to improve handoffs between team members across time zones
Needs templates for status updates, weekly digests, or async standups
Is establishing communication norms or a team communication charter
Wants to facilitate a specific meeting type (kickoff, planning, 1:1, retro)
Do NOT trigger this skill for:
Real-time pair programming workflows (that is synchronous by nature)
General project management methodology (Scrum, Kanban) without a remote focus
Key principles
Async by default, sync by exception - Every process should start as async.
Only escalate to a meeting when async has failed or the topic requires real-time
nuance (conflict resolution, brainstorming with high ambiguity, sensitive feedback).
The burden of proof is on the person requesting the meeting.
Write it down or it didn't happen - Decisions, context, and rationale must
live in a durable, searchable document - not in a Slack thread or someone's head.
Every meeting produces a written artifact. Every decision has a recorded "why."
Communicate with context, not assumptions - Remote messages lack body language
and shared physical context. Over-communicate intent, provide links to relevant
docs, state your ask explicitly, and set clear response-time expectations. A
well-structured message saves three rounds of back-and-forth.
Protect deep work with explicit norms - Define when people are expected to
be responsive (core overlap hours) and when they can go heads-down without guilt.
Use status indicators, calendar blocks, and notification schedules rather than
expecting instant availability.
Design for the reader, not the writer - Docs, messages, and agendas should
optimize for the person consuming them. Use headings, TL;DRs, explicit action
items, and named owners. Front-load the important information.
Core concepts
Communication modes - Remote teams operate across three modes: synchronous
(meetings, live calls), near-sync (Slack/chat with expected quick replies), and
async (documents, email, recorded video with no expectation of immediate response).
Each mode has a cost: sync is the most expensive (requires calendar alignment),
async is the cheapest (respects autonomy). Match the mode to the communication need.
The decision trail - In co-located teams, decisions happen in hallways and get
absorbed by proximity. Remote teams need an explicit decision trail: a chain of
documents (RFC, discussion comments, decision record) that lets anyone reconstruct
why a choice was made, months later, without asking the original participants.
Overlap windows - Distributed teams share limited hours of real-time overlap.
These hours are precious and should be reserved for high-value synchronous work:
complex discussions, relationship building, and blockers that can't be resolved
async. Protect overlap hours from status meetings and information broadcasts.
Meeting roles - Effective remote meetings require explicit roles: a facilitator
(keeps time, manages the agenda), a note-taker (captures decisions and action items
in real time), and a timekeeper (ensures each topic gets its allotted time). Without
roles, meetings drift and produce no written output.
Common tasks
Design an async standup process
Replace daily standup meetings with structured async updates. Each team member
posts a standup in a dedicated channel at a consistent time in their local zone.
Async standup template:
## Standup - [Name] - [Date]
**Yesterday:** What I completed
**Today:** What I'm working on
**Blockers:** Anything stopping progress (tag the person who can help)
**FYI:** Non-urgent context others might find useful
Set the norm that standups are write-only by default - no replies unless someone
has a blocker that needs help. Review standups async; escalate to a call only
when a blocker persists for more than one cycle.
Write a decision document (RFC)
Use this structure for any decision that affects more than one person or will be
hard to reverse.
RFC template:
# RFC: [Title]
**Author:** [Name]
**Status:** Draft | In Review | Accepted | Rejected
**Reviewers:** [Names with review-by date]
**Decision deadline:** [Date]
## Context
What is the current situation? Why does this need a decision?
## Proposal
What do you recommend? Be specific and actionable.
## Alternatives considered
What other options exist? Why is each inferior to the proposal?
## Trade-offs
What are we giving up? What risks does this introduce?
## Open questions
What do you need input on before finalizing?
Set a review period (3-5 business days for most decisions). Reviewers comment
inline. After the deadline, the author summarizes comments, makes a decision,
and updates the status. Silence equals consent - make this explicit in team norms.
Prepare a meeting agenda
Every meeting must have a written agenda shared at least 24 hours in advance.
No agenda, no meeting - enforce this as a team norm.
Agenda template:
# Meeting: [Title]
**Date:** [Date/Time with timezone]
**Duration:** [Minutes]
**Attendees:** [Names - mark optional attendees]
**Pre-read:** [Links to docs attendees must read before the meeting]
## Goals
What decisions or outcomes must this meeting produce?
## Agenda
1. [Topic] - [Owner] - [Minutes allocated] - [Goal: decide/discuss/inform]
2. [Topic] - [Owner] - [Minutes allocated] - [Goal]
3. [Topic] - [Owner] - [Minutes allocated] - [Goal]
## Standing items
- Action item review from last meeting (5 min)
- Parking lot / new topics (5 min)
Tag each agenda item with its goal type: "decide" (we leave with a choice made),
"discuss" (explore options, decision next time), or "inform" (one-way broadcast -
consider if this could be async instead).
Run an async retrospective
Replace live retro meetings with a multi-phase async process that gives everyone
time to think deeply.
Phase 1 - Collect (48 hours): Share a form or thread with three prompts:
what went well, what could improve, and what confused or frustrated you. Everyone
contributes independently without seeing others' responses (use anonymous forms
or spoiler tags).
Phase 2 - Theme (24 hours): A facilitator groups responses into themes and
shares them. Team members vote on which themes to address (dot-voting: 3 votes
per person).
Phase 3 - Act (live or async): For the top 2-3 themes, propose concrete
action items with named owners and deadlines. This phase can be a short (20 min)
sync meeting if the team prefers, since it involves negotiation.
Phase 4 - Track: Action items go into the team's task tracker. Review
progress at the start of the next retro cycle.
Create a communication charter
Define how the team communicates. Write this document once, revisit quarterly.
Charter sections:
Channel purpose: Which tool for what (e.g., Slack for quick questions,
docs for decisions, email for external comms, video for sensitive topics)
Response time expectations: By channel (e.g., Slack: same business day,
doc comments: within review period, email: 48 hours)
Core overlap hours: The daily window when everyone is expected to be
available for sync (e.g., 10am-1pm PT)
Deep work blocks: Protected hours when interruptions are discouraged
Escalation path: When to move from async to sync (blocker persists > 24h,
emotional topic, 3+ rounds of back-and-forth without resolution)
Meeting-free days: Designated days for uninterrupted focus (e.g., no
meetings on Wednesdays)
Write a weekly team digest
Replace status meetings with a written weekly digest that the team lead compiles.
Digest template:
# Week of [Date Range]
## TL;DR
[2-3 sentence summary of the most important things]
## Shipped
- [Feature/deliverable] - [Owner] - [Link to PR/doc]
## In progress
- [Work item] - [Owner] - [Expected completion] - [Status: on track/at risk]
## Decisions made
- [Decision] - [RFC link] - [Rationale in one sentence]
## Upcoming
- [Milestone/deadline] - [Date] - [Owner]
## Needs attention
- [Blocker or open question] - [Who can help]
Facilitate a 1:1 meeting
Structure 1:1s for remote teams where casual hallway interactions don't happen.
1:1 format:
Keep a running shared doc (both parties can add topics throughout the week)
Start with the report's topics, not the manager's
Allocate time: 50% their topics, 25% your topics, 25% career/growth
End with explicit action items and owners
If there are no substantive topics, cancel the meeting - don't meet for the
sake of meeting
Handle cross-timezone handoffs
When work passes between team members in different time zones, write a handoff
note that prevents the receiving person from starting cold.
Handoff template:
## Handoff: [Task/Project]
**From:** [Name/Timezone] **To:** [Name/Timezone]
**Date:** [Date]
**Current state:** Where things stand right now
**What I did:** Summary of work completed in this cycle
**What's next:** The immediate next step for the receiver
**Blockers:** Anything that might stop progress
**Context links:** [PRs, docs, threads relevant to pick up]
**Decision needed:** [Any pending decision the receiver should make]
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Defaulting to meetings for everything
Meetings are the most expensive communication mode; they block calendars and exclude async contributors
Start async; escalate to sync only when needed
Sending context-free Slack messages ("hey, got a minute?")
Forces a synchronous interruption and provides zero context for the recipient to prepare
State the full question/context upfront with an explicit ask
Making decisions in Slack threads
Threads are unsearchable, ephemeral, and invisible to people not in the channel
Move decisions to a doc; post the doc link in Slack
Meetings without agendas or notes
No agenda means no purpose; no notes means no output - the meeting evaporates
Enforce agenda-before-invite and notes-after-meeting norms
Expecting instant replies across time zones
Creates anxiety, encourages shallow work, and penalizes people in off-peak zones
Set explicit response-time expectations per channel
Recording meetings as a substitute for writing
Hour-long recordings are unsearchable and nobody watches them
Write a summary with timestamps; link the recording as backup only
Skipping the "why" in decisions
Without rationale, future team members reopen settled decisions
Always document the reasoning, not just the outcome
Gotchas
RFC review period ends with no decision recorded - Teams collect comments but never formally update the RFC status from "In Review" to "Accepted" or "Rejected." Without a recorded decision, the RFC becomes a zombie document that people keep re-litigating. Always close the loop: update status, summarize the decision, and note the rationale.
Async standup replacing the only team touchpoint - Async standups eliminate a synchronous moment, which is a good thing - but if they become the team's sole communication mechanism, relationship signals get lost. Preserve at least one brief weekly sync for relationship maintenance, not status.
Meeting recorded as the primary artifact - A one-hour recording is not a searchable document. No one rewatches it. Write a summary with decisions and action items; include a recording link only as supplementary reference. Defaulting to "we recorded it" is not documentation.
"Silence equals consent" norm not stated explicitly - If teams don't know that failing to respond to an RFC before the deadline counts as agreement, they feel blindsided by decisions made without them. State the norm explicitly in the RFC template and the team communication charter.
Cross-timezone handoffs written from the sender's perspective - Handoffs that say "I got halfway through X" don't tell the receiver what to do next. Structure handoffs from the receiver's perspective: what is the next concrete action, what context do they need, and what decision is waiting for them.
References
For detailed protocols and extended templates, read the relevant file from
references/:
references/async-workflows.md - Deep dive into async standup variations,
async code review protocols, and async brainstorming techniques. Load when
designing a specific async process.
references/meeting-facilitation.md - Extended facilitation playbooks for
kickoffs, planning sessions, all-hands, and difficult conversations. Load
when preparing to facilitate a specific meeting type.
references/documentation-templates.md - Full RFC template with examples,
ADR (Architecture Decision Record) format, post-mortem template, and project
brief template. Load when writing a specific document type.
Only load a references file if the current task requires it.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
