/pairing

name: pairing
description: >
  Build work collaboratively in reviewable pieces, handing each piece back for review before starting the next, so the
  person stays in the lead and steers while the work happens instead of reviewing a finished result. Use when someone
  says to pair with them on something, asks to collaborate rather than direct, wants to review as it goes, or wants to
  guide the work piece by piece — on code, on a design decision, or on writing. For a test-first build it runs tdd, for
  restructuring it runs refactor, for an interface contract it runs design-an-api, and for plan work it runs
  iterative-plan-review or plan-implementation, each collaboratively; invoke any of those directly instead to run it
  straight through without pausing. Does not pace someone through code that already exists and builds nothing — use
  code-walkthrough. Does not explain, summarize, or research something instead of producing it — use code-overview or
  research.
allowed-tools:
  Read, Write, Edit, Glob, Grep, Skill, Bash(find *),
  Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")
argument-hint: "[what to pair on]"

Project Context

• personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
• project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`
• CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

The contract this skill runs on

Read [collaborative-stop-rule.md](../../references/collaborative-stop-rule.md) before Step 4. It defines what a stop presents, when the pre-build ask fires, what makes a choice expensive to walk back, and what to do with the answer. The skills this one hands work to follow the same file, which is what makes a stop feel the same whoever performed it.

Two constraints from that file govern every step below and are repeated here because they are the ones most easily lost:

• **The pacing is the deliverable.** Ending the turn at each stop is the product, not an interruption in it. Never

continue past a stop to be helpful.

• **A stop hands over something to check, never a case for the work.** Lead with what the person can verify. The

reasoning goes last or goes unsaid until asked, BECAUSE a fluent explanation raises agreement without raising scrutiny, which is the failure this whole loop exists to prevent.

Pairing

Step 1: Resolve the Record Location

Resolve where the running feedback record will be written, using the output base directory from the configuration probed above. Absent any configuration, write it beside the work under `.han/pairing/`.

Name the file for this run so a second run in the same repository does not overwrite the first. State the path to the person in Step 4's plan, in one clause, BECAUSE a record they cannot find is not a record.

Read the file first if it already exists. A run resuming after an interrupted session inherits the record rather than starting a new one.

Step 2: Split the Request Into Concerns

Split the request into concerns before sorting any of it. A request holding two concerns and sorted as one produces one kind, one set of boundaries, and one uninterrupted run through both, which is how a build and the work that depends on that build end up in the same turn with neither of them reviewed.

**A concern is one thing the person asked for, with its own deliverable.** Two asks joined by "and", "and then", "then help me", or a numbered list are two concerns whenever they produce two things the person would check separately. An edit to a file and a reply to a question are two deliverables even when they are about the same lines of code.

**Changing code and understanding or answering a question are always separate concerns.** This one takes no judgment. Never bundle them, whatever their subject, however small either one is, and however plainly the second follows from the first, BECAUSE checking an edit means reading a diff and checking an answer means reading the answer. Bundled, the answer arrives before the edit it rests on has been verified, so a wrong edit yields a confident wrong answer and the two pass unreviewed together.

**Do not split one deliverable into concerns.** The steps inside a single deliverable are pieces, and Step 4's plan divides them. Two concerns exist when the person would check two different artifacts, not when one artifact takes several steps.

Concerns run in sequence and never interleave. The last piece of one concern is a stop like any other, and the next concern does not begin until the person responds.

**When you cannot tell whether the request holds one concern or two, treat it as two** and say so in the plan, where the person can merge them back. An extra stop costs one turn. A missing one costs the review this whole loop exists to get.

Step 3: Sort Each Concern

Apply this test to each concern separately, in order, and stop at the first match:

1. Does a skill carrying the collaborative flag cover this work? Then it is **skill-backed**. The flagged skills are `tdd` for a test-first build, `refactor` for restructuring, `design-an-api` for an interface contract, `iterative-plan-review` for sharpening a plan, and `plan-implementation` for planning a build. 2. Does the work produce a choice among options that commits the person to something? Then it is **decision work**. 3. Does the work produce prose someone will read? Then it is **prose work**. 4. Otherwise it is **open-ended**, and Step 4's plan supplies the bound