delivery-workshop

Files (1)

• SKILL.md

SKILL.md (first lines)

# Delivery — Workshop

This skill adapts instructional design principles for intensive, hands-on developer workshops. It covers facilitated lab environments, peer learning dynamics, coaching strategies, collaborative problem-solving, and creating productive constraints that drive learning through doing.

## Features

- **Scaffolded Practice**: Guided labs progressing from worked examples to independent challenges
- **Collaborative Problem-Solving**: Pair and group work with intentional peer roles
- **Coaching & Circulation**: Facilitator moves through room, asks questions, unblocks without solving
- **Real-Time Feedback**: Immediate debugging support, code review on-the-fly
- **Lab Stations or Breakout Teams**: Differentiated difficulty or specialization
- **Reflection & Debrief**: Group processing after practice, surfacing learning

## When To Use

- Designing 2-4 hour intensive practice sessions
- Building peer programming or pairing-based learning
- Creating capstone projects with facilitation
- Designing hackathons, code retreats, or sprint-style learning
- Facilitating open lab hours with coaching

## Guidelines

### Lab Design

- [ ] **Clear problem statement**: Learners understand what they're trying to achieve
- [ ] **Starter template or skeleton code**: Reduces setup friction, focuses on core learning
- [ ] **Graduated complexity**: Easy win (20-30%), medium challenge (40-60%), extension (80%+)
- [ ] **Acceptance criteria**: "You've succeeded when..."
- [ ] **Hints available, not solutions**: Hint cards, scaffolded docs, not full code
- [ ] **Estimated time**: "This section should take ~20 min" (learners self-pace within bounds)
- [ ] **Checkpoints**: "Stop here; we'll debrief together" at natural breaks
- [ ] **Success is visible**: Running tests, working feature, or artifact to demo

### Pair Programming Structure

**Optimal pairing**:
- Mix skill levels intentionally (novice + intermediate > homogeneous)
- Define roles: **driver** (types) and **navigator** (directs, reviews)
- Rotate every 10-15 minutes (timer helps)
- Both roles critical to learning

**Role clarity**:
- **Driver**: Writes code, asks for direction, types suggestions from navigator
- **Navigator**: Reads code, spots issues, looks ahead, asks clarifying questions
- Avoid: Driver ignoring navigator; navigator dictating verbatim

**Facilitation**:
- [ ] Introduce roles; explain why pairing accelerates learning
- [ ] Watch for dominance: "Navigator, what should happen next?"
- [ ] Support quieter partners: "Driver, can you explain your approach to your navigator?"
- [ ] Normalize struggle: "Disagreement is good—it surfaces assumptions"
- [ ] Debrief: "What did you learn from your partner's approach?"

### Coaching & Circulation

**Ask, don't tell**:
- ❌ "You need to add a null check here"
- ✅ "What could go wrong if the input is null?"

**Diagnostic questions**:
- "What's the error message telling you?"
- "What did you expect to happen? What happened instead?"
- "Walk me through your approach step by step"
- "What have you tried so far?"
- "Is there a simpler test case you could try first?"

**Unblocking strategies** (in order):
1. Clarifying question (helps them find the path)
2. Hint: "Have you considered...?" or "What if you tried...?"
3. Pointed resource: "Check the section on X in the docs"
4. Demonstration (show the concept, not the full solution)
5. Code snippet + explanation (last resort; ensure they understand before moving on)

**Circulation pattern**:
- [ ] Systematically visit every pair/group
- [ ] Start with pairs showing visible struggle
- [ ] Check in with confident pairs to prevent complacency
- [ ] Notice and interrupt unproductive patterns early (thrashing, passivity)
- [ ] Spend 2-5 min per pair, then move on

### Peer Learning Dynamics

**Structured peer feedback** (after practice):
- [ ] Pair review: "Compare your solutions; what's different?"
- [ ] Rotation review: Solution posted; others annotate with feedback sticky notes
- [ ] Fishbowl: One pair codes while others watch, then discuss approach

**Psychological safety in peer work**:
- [ ] Normalize mistakes: "Great—you found a common edge case"
- [ ] Celebrate different approaches: "You both solved it; show both methods"
- [ ] Frame feedback as curious: "I'd expect this to fail; did it?"
- [ ] Facilitator models: "Here's code I wrote; it has a bug—can you spot it?"

**Preventing dominance**:
- [ ] Enforce driver/navigator role rotation (timer)
- [ ] Interrupt code hogging: "Navigator, take the driver role"
- [ ] Group size: pairs are ideal; groups of 3+ require active facilitation
- [ ] Assign roles explicitly: "A is driver; B is navigator; you'll swap at X"

### Lab Checkpoints & Debrief

**Checkpoint design**:
- After ~15-20 min of independent work, pause for group debrief
- Show 2-3 representative solutions (working, partially working, alternative approach)
- Discuss tradeoffs, common errors, and "why this matters"
- Reset: "Clear this and try the next section"

**Debrief structure** (5-10 min):
1. **Show & Tell** (2-3 min): One or two pairs demo their solution
2. **Compare** (2-3 min): "How is your approach different? Both valid?"
3. **Reflect** (2-3 min): "What was hard? What surprised you?"
4. **Connect** (1-2 min): "How does this relate to production code you'll write?"

**Group problem-solving debrief**:
- Start with a failing test or bug introduced by the facilitator
- Pairs/groups debug collaboratively; share findings
- Reveal the solution incrementally (not all at once)

From caraya/agent-skills, MIT.

More from caraya/agent-skills