devstack 0.1.0

package/vendor/skills/skills/professional-communication/references/meeting-structures.md

@@ -0,0 +1,333 @@
+# Meeting Structures for Developers
+
+Templates and structures for common software development meetings. Use these to run effective meetings and ensure productive outcomes.
+
+## Daily Standup
+
+**Duration:** 15 minutes max
+**Frequency:** Daily
+**Format:** Each person answers 3 questions
+
+### Structure
+
+Each team member shares (1-2 minutes max per person):
+
+1. **Yesterday:** What did I complete?
+2. **Today:** What am I working on?
+3. **Blockers:** What's in my way?
+
+### Best Practices
+
+- **Stand up** (if in person) - Keeps it short
+- **Focus on work, not activity** - "Completed feature X" beats "Attended meetings"
+- **Parking lot** - Note follow-up discussions for after standup
+- **Timebox strictly** - 15 minutes, then end
+- **Blockers get attention** - If someone's blocked, identify who can help
+
+### Anti-Patterns to Avoid
+
+- Turning into status report to manager (it's team sync, not reporting)
+- Problem-solving during standup (take it offline)
+- Going into technical details (save for pairing sessions)
+- Skipping when "nothing to report" (brief updates still valuable)
+
+---
+
+## Sprint Planning
+
+**Duration:** 1-2 hours
+**Frequency:** Start of each sprint
+**Purpose:** Agree on sprint goals and work commitment
+
+### Structure
+
+| Phase          | Duration | Activity                          |
+| -------------- | -------- | --------------------------------- |
+| Sprint Goal    | 10 min   | What will this sprint accomplish? |
+| Backlog Review | 20 min   | Review prioritized items          |
+| Estimation     | 30 min   | Size items being considered       |
+| Commitment     | 20 min   | Team commits to sprint scope      |
+| Capacity Check | 10 min   | Account for PTO, meetings, etc.   |
+
+### Agenda Template
+
+```markdown
+1. **Sprint Goal** (10 min)
+   - Product Owner presents sprint objective
+   - Team asks clarifying questions
+
+2. **Backlog Review** (20 min)
+   - Review top items in priority order
+   - Clarify acceptance criteria
+   - Identify dependencies
+
+3. **Estimation** (30 min)
+   - Estimate items using team's method (points, t-shirts, etc.)
+   - Break down large items if needed
+
+4. **Sprint Commitment** (20 min)
+   - Team selects items that fit capacity
+   - Confirm everyone understands the work
+
+5. **Wrap-up** (10 min)
+   - Recap sprint goal and committed items
+   - Note any risks or dependencies to watch
+```
+
+### Best Practices
+
+- **Come prepared** - PO has prioritized backlog, items are refined
+- **Focus on "what" not "how"** - Save implementation details for during sprint
+- **Protect focus time** - Account for meetings, support, etc. when committing
+- **Team decides capacity** - Only team members estimate and commit
+
+---
+
+## Sprint Retrospective
+
+**Duration:** 1-1.5 hours
+**Frequency:** End of each sprint
+**Purpose:** Continuous improvement
+
+### Structure
+
+| Phase             | Duration | Activity               |
+| ----------------- | -------- | ---------------------- |
+| Set the Stage     | 5 min    | Check-in, set tone     |
+| Gather Data       | 20 min   | Collect feedback       |
+| Generate Insights | 20 min   | Discuss patterns       |
+| Decide Actions    | 15 min   | Commit to improvements |
+| Close             | 5 min    | Appreciate, wrap up    |
+
+### Common Formats
+
+**Start/Stop/Continue:**
+
+- **Start doing:** What should we begin?
+- **Stop doing:** What should we stop?
+- **Continue doing:** What's working well?
+
+**Liked/Learned/Lacked/Longed For (4Ls):**
+
+- **Liked:** What went well?
+- **Learned:** What did we discover?
+- **Lacked:** What was missing?
+- **Longed for:** What do we wish we had?
+
+**Mad/Sad/Glad:**
+
+- **Mad:** What frustrated you?
+- **Sad:** What disappointed you?
+- **Glad:** What made you happy?
+
+### Best Practices
+
+- **Safe space** - No blame, focus on systems not people
+- **Limit action items** - 1-3 concrete improvements
+- **Follow up** - Review last retro's actions at start
+- **Vary the format** - Keep it fresh to avoid ruts
+- **Everyone participates** - Make space for quieter voices
+
+---
+
+## Architecture Review / Tech Design Review
+
+**Duration:** 45-60 minutes
+**Frequency:** As needed for significant technical decisions
+**Purpose:** Get feedback on technical approach before implementation
+
+### Structure
+
+```markdown
+1. **Context & Problem** (10 min)
+   - What problem are we solving?
+   - Why now? What's driving this?
+
+2. **Proposed Solution** (15 min)
+   - High-level architecture diagram
+   - Key components and their responsibilities
+   - Data flow
+
+3. **Trade-offs & Alternatives** (10 min)
+   - What alternatives did you consider?
+   - Why this approach over others?
+   - What are we trading off?
+
+4. **Discussion & Questions** (15 min)
+   - Open floor for questions
+   - Concerns and risks
+   - Edge cases and failure modes
+
+5. **Decision & Next Steps** (5 min)
+   - Approved / Approved with changes / Needs revision
+   - Action items and timeline
+```
+
+### Best Practices
+
+- **Share materials beforehand** - Send design doc 24-48 hours before
+- **Timebox discussion** - Don't let it become a working session
+- **Focus on architecture, not code** - Implementation details come later
+- **Document decisions** - Record the outcome in an ADR or design doc
+
+---
+
+## One-on-One (1:1)
+
+**Duration:** 30-60 minutes
+**Frequency:** Weekly or bi-weekly
+**Purpose:** Support, feedback, career growth
+
+### Structure (Flexible)
+
+```markdown
+1. **Their Topics First** (15-20 min)
+   - What's on their mind?
+   - Blockers, concerns, wins
+
+2. **Feedback Exchange** (10-15 min)
+   - Recognition for recent work
+   - Growth areas or coaching
+
+3. **Career/Growth** (10-15 min)
+   - Progress on development goals
+   - Upcoming opportunities
+
+4. **Admin/Updates** (5 min)
+   - Any org updates to share
+   - Upcoming schedule impacts
+```
+
+### Good Questions to Ask
+
+**For team members:**
+
+- "What's your biggest blocker right now?"
+- "What's one thing I could do to better support you?"
+- "What are you most proud of recently?"
+- "What would you like to be doing more of?"
+
+**For managers:**
+
+- "Is there anything you need from me?"
+- "How can I help the team succeed this sprint?"
+- "What feedback do you have for me?"
+
+### Best Practices
+
+- **Their meeting, their agenda** - Let them drive topics
+- **Don't cancel** - Consistency builds trust
+- **Take notes** - Remember what you discussed
+- **Follow through** - If you commit to something, do it
+
+---
+
+## Incident Postmortem / Blameless Review
+
+**Duration:** 60-90 minutes
+**Frequency:** After significant incidents
+**Purpose:** Learn and prevent recurrence
+
+### Structure
+
+```markdown
+1. **Timeline Review** (20 min)
+   - What happened, when?
+   - Build shared understanding of events
+
+2. **Impact Assessment** (10 min)
+   - What was affected?
+   - Customer impact, business impact
+
+3. **Root Cause Analysis** (20 min)
+   - 5 Whys or Fishbone diagram
+   - Contributing factors (not just trigger)
+
+4. **What Went Well** (10 min)
+   - What worked in our response?
+   - What should we keep doing?
+
+5. **Action Items** (15 min)
+   - Prevention measures
+   - Detection improvements
+   - Response improvements
+
+6. **Wrap-up** (5 min)
+   - Assign owners and timelines
+   - Schedule follow-up if needed
+```
+
+### Best Practices
+
+- **Blameless** - Focus on systems, not individuals
+- **Assume good intent** - People made reasonable decisions with available info
+- **Prioritize actions** - Don't try to fix everything; focus on highest impact
+- **Share learnings** - Document and share with broader team/org
+
+---
+
+## Code Review Walkthrough
+
+**Duration:** 30-45 minutes
+**Frequency:** As needed for complex changes
+**Purpose:** Deep review of significant code changes
+
+### Structure
+
+```markdown
+1. **Context Setting** (5 min)
+   - What problem does this solve?
+   - Why was this approach chosen?
+
+2. **High-Level Walkthrough** (10 min)
+   - Architecture/structure overview
+   - Key files and their purposes
+
+3. **Detailed Review** (20 min)
+   - Walk through critical paths
+   - Highlight non-obvious decisions
+   - Answer questions in real-time
+
+4. **Wrap-up** (5 min)
+   - Note remaining concerns
+   - Agree on approval path
+```
+
+### Best Practices
+
+- **Share PR link beforehand** - Let reviewers skim first
+- **Focus on logic, not style** - Linters catch style issues
+- **Author drives the walkthrough** - Explain your thinking
+- **Note follow-up items** - Track issues for separate PRs
+
+---
+
+## General Meeting Tips
+
+### Before the Meeting
+
+- [ ] Clear purpose/objective defined
+- [ ] Agenda sent in advance
+- [ ] Right people invited (and only right people)
+- [ ] Materials shared for pre-read
+- [ ] Time and duration appropriate for scope
+
+### During the Meeting
+
+- [ ] Start on time
+- [ ] State objective at opening
+- [ ] Timebox discussions
+- [ ] Capture action items live
+- [ ] Leave 5 minutes for wrap-up
+- [ ] End on time (or early!)
+
+### After the Meeting
+
+- [ ] Send summary within 24 hours
+- [ ] Action items have owners and due dates
+- [ ] Follow up on commitments
+- [ ] Cancel recurring meetings that aren't adding value
+
+---
+
+**Related:** Return to `professional-communication` skill for email and written communication guidance.

package/vendor/skills/skills/professional-communication/references/remote-async-communication.md

@@ -0,0 +1,310 @@
+# Remote and Async Communication
+
+Guide to effective communication in remote-first and async-first environments.
+
+## Async-First Principles
+
+### Default to Async
+
+Before scheduling a meeting, ask: "Could this be async instead?"
+
+| Sync (Meeting)                        | Async (Document/Message)            |
+| ------------------------------------- | ----------------------------------- |
+| Brainstorming with immediate building | Collecting feedback over time       |
+| Sensitive/emotional conversations     | Status updates                      |
+| Real-time collaboration               | Decisions with clear options        |
+| Urgent problem-solving                | Non-urgent questions                |
+| Relationship building                 | Documentation and knowledge sharing |
+
+### Why Async Matters
+
+- **Time zones:** Not everyone is online at once
+- **Deep work:** Meetings fragment focus time
+- **Inclusion:** Async gives introverts equal voice
+- **Documentation:** Async creates artifacts for later
+- **Flexibility:** People work when they're most productive
+
+## Channel Selection Guide
+
+Choose the right tool for the job:
+
+### Instant Messaging (Slack, Teams)
+
+**Best for:**
+
+- Quick questions expecting same-day answers
+- Informal team chat
+- Time-sensitive coordination
+- Celebrations and recognition
+
+**Anti-patterns:**
+
+- Long-form discussions (use docs)
+- Decisions needing documentation (use PRs or docs)
+- Anything requiring more than 3 back-and-forths
+
+### Documents (Notion, Google Docs)
+
+**Best for:**
+
+- Proposals and RFCs
+- Meeting notes and follow-ups
+- Complex decisions with multiple stakeholders
+- Knowledge that should persist
+- Async reviews and feedback
+
+**Format tips:**
+
+- Start with TL;DR
+- Use headers for scannability
+- Call out action items and decisions clearly
+- Include deadline if feedback is needed
+
+### Email
+
+**Best for:**
+
+- External communication
+- Formal announcements
+- Reaching people outside your company
+- When you need a paper trail
+
+**Avoid for:**
+
+- Internal quick questions (use Slack)
+- Collaborative editing (use docs)
+
+### Video Calls
+
+**Reserve for:**
+
+- Complex discussions needing real-time back-and-forth
+- Sensitive conversations (feedback, conflict)
+- Relationship building
+- Urgent problem-solving
+- Brainstorming and creative work
+
+**Always:**
+
+- Send agenda beforehand
+- Record for those who can't attend
+- Document decisions and action items after
+
+### PRs and Code Comments
+
+**Best for:**
+
+- Code-specific discussions
+- Technical decisions with code context
+- Review feedback
+- Architectural choices in implementation
+
+## Over-Communication
+
+In remote work, default to over-communication:
+
+### Share Context Liberally
+
+People can't see what you're working on:
+
+| Don't                            | Do                                                  |
+| -------------------------------- | --------------------------------------------------- |
+| Disappear for hours              | Post "heads down on X, will be slow to respond"     |
+| Assume people know your schedule | Share working hours in your profile                 |
+| Go silent when stuck             | Post "blocked on X, exploring options"              |
+| Complete work silently           | Share progress: "Finished the API, moving to tests" |
+
+### Working Out Loud
+
+Share your thinking, not just your conclusions:
+
+**Good examples:**
+
+> "Exploring two approaches for the caching problem: Redis vs. in-memory. Leaning toward Redis for cross-instance consistency. Will share trade-offs in #architecture by EOD."
+
+And:
+
+> "Hit an unexpected issue with the auth flow - user sessions aren't persisting across subdomains. Investigating cookie settings. ETA unclear, will update in 2 hours."
+
+### When Changing Plans
+
+If priorities shift:
+
+- Communicate the change and reason
+- Update anyone who was expecting the old thing
+- Don't assume people will notice
+
+## Time Zone Awareness
+
+### Know Your Team's Time Zones
+
+Keep a quick reference:
+
+- Who overlaps with you (synchronous possible)
+- Who doesn't (async required)
+- When each person's day starts/ends
+
+### Async by Default
+
+When in doubt, don't expect immediate response:
+
+- Include context so they can reply without follow-up questions
+- Set clear but reasonable deadlines
+- Acknowledge receipt even if you can't respond fully yet
+
+### Schedule Sends
+
+Don't send messages at 2am someone else's time:
+
+- Use "schedule send" features
+- Or add context: "No response expected until your morning"
+
+### Rotating Meeting Times
+
+For regular cross-timezone meetings:
+
+- Rotate who bears the inconvenient time
+- Record meetings for those who can't attend live
+- Default to async when sync isn't essential
+
+## Documentation Over Meetings
+
+### Meeting Decision Rule
+
+Before scheduling a meeting:
+
+1. **Write first:** Draft the problem, context, and options
+2. **Collect async feedback:** Give 24-48 hours
+3. **Then decide:** If still unresolved, schedule a meeting
+
+Many meetings can be avoided if the organizer documents well enough that discussion isn't needed.
+
+### Meeting Follow-Up
+
+Every synchronous meeting should produce async artifacts:
+
+- **Notes:** Key discussion points
+- **Decisions:** What was decided and why
+- **Action items:** Who does what by when
+- **Recording:** For those who couldn't attend
+
+Share within 24 hours while context is fresh.
+
+### Recording and Summarizing
+
+For important sync meetings:
+
+- Record video/audio
+- Create written summary with timestamps
+- Call out decisions and action items
+- Share in relevant channels
+
+## Writing for Async
+
+### Frontload the Point
+
+Start with the conclusion/ask, then provide context:
+
+**Buried lead (bad):**
+
+> "I've been looking at our deployment pipeline and noticed that the test suite takes 45 minutes. After investigating, I found that most of the time is spent on integration tests that could be parallelized. I've put together a proposal to reduce this by 60%..."
+
+**Frontloaded (good):**
+
+> "**Proposal:** Reduce our test suite time from 45 min to 18 min by parallelizing integration tests.
+>
+> **Context:** Our deployment pipeline is slow because..."
+
+### Make It Scannable
+
+Use structure for long messages:
+
+- **Headers** for sections
+- **Bold** for key points
+- **Bullets** for lists
+- **TL;DR** at the top for long documents
+
+### Include Everything Needed
+
+The reader shouldn't need to ask follow-up questions:
+
+| Missing context         | Complete context                                                                                                   |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| "The deploy failed"     | "The 3pm deploy to staging failed with timeout error (link to logs). I'm investigating and will update in 1 hour." |
+| "Can you review my PR?" | "Can you review my PR (#123)? It's ~200 lines touching the auth flow. Happy to answer questions async or sync."    |
+
+### Set Clear Expectations
+
+Make response expectations explicit:
+
+- **Deadline:** "Feedback needed by Friday EOD"
+- **Priority:** "Not urgent, whenever you have time"
+- **Type of response:** "Looking for approval" vs. "Want to brainstorm"
+- **Who should respond:** "@team" vs. specific people
+
+## Anti-Patterns
+
+### The Slack Novel
+
+Long-form content in chat messages:
+
+- Hard to skim
+- Gets lost in scroll
+- Can't be edited or organized
+
+**Fix:** Put it in a document, share the link.
+
+### The Ping-Pong Conversation
+
+Back-and-forth that takes 3 hours in chat but would take 10 minutes in a call:
+
+**Fix:** After 3 exchanges, offer "Want to hop on a quick call?"
+
+### The Surprise Meeting
+
+Adding meetings without context or asking availability:
+
+**Fix:** Always include agenda; ask before scheduling.
+
+### The Ghost
+
+Disappearing without communication:
+
+**Fix:** Post status when stepping away; respond to acknowledge messages even if you can't fully address them.
+
+### The Always-On Expectation
+
+Expecting immediate responses:
+
+**Fix:** Set team norms about response times; use async by default.
+
+## Team Norms
+
+Consider establishing explicit norms:
+
+```markdown
+## Our Communication Norms
+
+### Response Times
+
+- **Slack DM:** Within 4 working hours
+- **Slack channel:** Within 24 hours
+- **Email:** Within 48 hours
+- **Document comments:** Before stated deadline
+
+### Urgent vs. Non-Urgent
+
+- For truly urgent: Use @here or call
+- For everything else: Assume async
+
+### Deep Work Protection
+
+- No expectation of response during focus time (blocked on calendar)
+- "Do Not Disturb" is respected
+
+### Time Zone Respect
+
+- Core overlap hours: 10am-2pm EST
+- Meetings scheduled in overlap hours only
+- Async preferred outside overlap
+```