Claupair

A Claude Code skill for structured pair programming. Instead of delegating tasks wholesale to Claude, Claupair keeps you in the loop — surfacing decisions, sharing ownership of steps, and logging rationale so nothing gets lost.

What it does

When you invoke /claupair, Claude enters a collaborative mode with three phases:

1. Explore — Understand the problem together before jumping to code. Claude asks clarifying questions one at a time, surfaces assumptions, and confirms scope.

2. Design — Break the work into steps. Each step gets an owner:

   • @claude — Claude drives, you review after
   • @user — You implement, Claude provides context if asked
   • @pair — Back-and-forth: Claude scaffolds, you fill in the logic

3. Build — Execute the plan step by step, with a session file tracking progress and decisions.

A session file (.claude/claupair/<task-name>.md) is created automatically to track decisions, their rationale, and task progress.

Installation

Copy SKILL.md into your Claude Code skills directory:

# Per-project
mkdir -p .claude/skills
cp SKILL.md .claude/skills/claupair.md

# Or globally (applies to all projects)
mkdir -p ~/.claude/skills
cp SKILL.md ~/.claude/skills/claupair.md

Then start a session with /claupair in Claude Code.

Decision level defaults (recommended)

The skill works on its own, but it's much better paired with the decision level defaults in your CLAUDE.md. These tell Claude when to ask you versus when to just do the obvious thing — which is the core of what makes pair programming with an AI feel natural instead of noisy.

Copy the contents of CLAUDE.md.example into your ~/.claude/CLAUDE.md (global) or your project's CLAUDE.md.

The defaults define three tiers:

Tier	When	Examples
Auto-resolve	Always just do it	Naming, formatting, import order, error message wording
Context-dependent	Ask in pair mode, auto-resolve when driving alone	Helper extraction, which pattern to follow, public vs private API
Always ask	Always present as a decision point	New modules, data models, architecture, interface changes, dependency choices

These tiers are fully customizable. Move items between tiers to match your comfort level — if you always want Claude to ask before creating files, keep it in "always ask". If you trust Claude's judgement on error handling, move it to "auto-resolve".

The decision point format looks like this in practice:

── Decision: Where to put the validation logic ──
Context: We need input validation for the new endpoint.

  A) Inline in the handler — simple, keeps it local
  B) Shared validation module — reusable, but adds a file

Leaning: A, because this is the only endpoint using this shape
──

You respond with just "A", "B", or "B but with X" and Claude acts on it immediately.

Customization

The defaults in CLAUDE.md.example are a starting point. Tune them to your style:

• Want more autonomy? Move items from "always ask" to "context-dependent" or "auto-resolve"
• Want more control? Move items up to "always ask"
• Working in a new codebase? Keep more things in "always ask" until you've built trust
• Deep in flow on familiar code? Shift toward auto-resolve to reduce interruptions