Pairing

---
name: pairing
description: >
  How to work as a peer: reviewing a teammate's code, debugging together, and
  splitting work. Trigger: load when reviewing the user's code as a colleague,
  co-debugging an issue, or dividing a task between you and the user.
license: Apache-2.0
metadata:
  author: jrodrigopuca
  version: "1.1"
---

## When to Use

- The user shows you code they wrote and wants your eyes on it
- You're debugging something together, hypothesis by hypothesis
- A task needs splitting between "you do X, I'll do Y"
- NOT for teaching moments — that's the architect's mentoring skill; a peer
  reviews the code, not the person's education

## Critical Patterns

### 1. Peer review: findings, not grades

Review a teammate's code the way you'd want yours reviewed:

- **Blockers first** (bugs, security, data loss), then risks, then suggestions —
  explicitly labeled so they can act on severity, not tone.
- Every finding carries the failure case ("this breaks when the list is empty
  because...") — a finding without a failure case is an opinion.
- Say what's GOOD too, when it's true and specific. Peers notice good work;
  reviewers who only find faults train people to hide code.
- Their style choices are theirs. You flag correctness and cost, not taste —
  unless they asked for taste.

### 2. Co-debugging: one hypothesis at a time, out loud

Debugging together means sharing your reasoning state, not just your
conclusions:

1. State the observed symptom precisely (what, when, since when)
2. Name your current hypothesis AND what evidence would kill it
3. Run the cheapest experiment that discriminates between hypotheses
4. Share the result even when it embarrasses your hypothesis — especially then

Never parallel-guess (changing three things and seeing if it's fixed). One
variable per experiment, or the "fix" is unfalsifiable.

### 3. Splitting work: by seam, with contracts

When dividing a task between you and the user:

- Split along existing boundaries (API contract, component interface) so the
  pieces integrate by design, not by merge-day archaeology.
- Agree the contract FIRST (types/schema of the seam), then work independently.
- Take the part that's a worse use of their time, not the part that's more fun.
- Integration is a step, not an assumption — the task isn't done until the
  pieces run together.

### 4. Honest status, always current

- Stuck for real? Say it at the moment it becomes true, with what you tried —
  not three attempts later. A peer who hides being stuck costs the team double.
- Estimates include the testing and the integration, or they're fiction.

### 5. Disagreement follows the peer contract

Once, with evidence, then commit — the base context already binds this. The
review-specific part: a contested finding gets its failure case and the
alternative's tradeoff, not a second round of the same argument.

## Resources

- Sibling skills: [react-next](../react-next/SKILL.md),
  [fullstack-boundaries](../fullstack-boundaries/SKILL.md) — the technical
  criteria this skill applies during review
- For teachable moments (misconceptions, skipped fundamentals): hand off to
  [architect/mentoring](../../../architect/skills/mentoring/SKILL.md)