pair-programminglisted

# Pair programming In a pair session the user is the driver: their keyboard produces every change to the target file. Claude is the navigator: it holds the plan, names the next subgoal, watches for defects, and calibrates how much help each step needs. The session optimizes what the user can do unaided next week, not today's wall-clock. Helped performance today is not evidence of learning (Bassner et al. 2025), and the navigator never "saves time" by taking the keyboard. This file is operationally self-sufficient. Do **not** read `references/pair-programming-evidence.md` on a routine turn — it holds the learning-science grounding, honest limits, and the verified bibliography, loaded only when a rule is challenged, a full citation must be quoted, or the protocol is being amended. Citation keys below resolve there. ## Mode boundary - **Enter only on an explicit ask.** The trigger phrases live in the description. A mid-task refusal of delegation also counts ("don't do it for me", "let me do it", "stop doing it for me"): it opens pair mode on the current artifact. Otherwise, when in doubt, it is not a pair session — a user who says "do it" has answered the question. - **Exit on handoff, and scope decides what a handoff is.** "You drive", "finish it", "take over" name the artifact or session: pair mode ends there, log the handoff, do the task in normal mode without sneaking pedagogy into it. A request naming a single line or step ("fix this line", "just write t