Pair Programming

Work as a pair: discuss the change together; the agent writes the authorized code. The human does not have to type. Keep the connection between domain intent, code, and evidence visible without turning the conversation into a lesson or examination.

Activation and scope

Activate only for an explicit pairing request, such as “let's pair on this” or “pair with me while you implement”, or invocation of this skill by name. Claude Code: /pair-programming; Pi: /skill:pair-programming; other clients: request the skill by name. Mentioning key pairs or asking an ordinary coding question is not opting in. Loading this file for review is not activation.

Say briefly that you will write the code and pause between agreed steps to discuss results. Pairing changes interaction, not authority: activation alone grants no permission to edit, run commands, claim work, install anything, or publish changes. Discussion-only intent stays read-only until the user explicitly requests implementation; “sounds right” about an explanation is not that request.

Keep pairing active in the current session across skill handoffs until the user explicitly exits. It is an interaction layer, not an implementation specialist or an always-on gate. No extra orchestration, state files, or runtime dependencies are needed.

Agree on a small step

Use what the user has already told you: the desired outcome, relevant code and domain constraints, what must remain true, and any settled decisions. Read the relevant repository evidence rather than guessing. Ask only about missing context that materially changes the work; no fixed intake questionnaire.

Discuss meaningful alternatives in terms of behavior and trade-offs, and recommend an approach with reasons. Answer direct questions directly. Do not demand a prediction, quiz the user, or withhold an answer to test their understanding.

A step is one reviewable outcome plus proportionate verification, not one tool call and not an entire multi-part feature disguised as a step. Propose that boundary before starting. If the user already requested a concrete small implementation step, acknowledge its scope and proceed without asking for the same permission again. For a broad implementation request, agree on the first step before editing.

Implement within the agreement

Use develop before authorized coding, including a discussion-to-code transition. Follow its routing to implement-solution, diagnose-bug, or architect as appropriate. Continue an already-active specialist; do not reload coding entry points for every edit or restart discovery at every discussion break.

Carry the current step boundary into those workflows. Finish the routine reads, edits, local design details and checks needed for that step without approval per line or tool. Investigate and fix expected test failures within scope; they are feedback, not automatic reasons to hand the work back. Test proportionately using repository-native checks. Do not add unrelated cleanup or launch delegation/review merely because pairing is active. If separately authorized delegation is used, give it only the current agreed scope. Required reviews and source, Git, security, privacy, billing, and production gates still apply; a step agreement never replaces their separate approvals.

Pause before a consequential unagreed decision: changing public behavior, data/schema, introducing a dependency, choosing between materially different domain rules, or expanding the step. Explain the concrete choice and its consequences; offer a recommendation and wait for the user's decision. Ordinary helper names or equivalent local code shapes do not need a vote. Specialist recommendations do not silently become user agreement.

Warn immediately about security, privacy, or data-loss risks, before taking the risky action. Stop that action and resolve the risk under the applicable safeguards; do not let a dangerous mistake proceed for educational effect.

Discuss the result before continuing

While pairing, the agreed step is the unit of completion for continuation purposes. Continue through skill transitions and routine checks inside it; after it, return control to the user before starting another step, even if the broader feature is authorized. A progress message followed immediately by more implementation is not a discussion break.

Briefly explain what changed, what the checks actually showed (including failures or missing evidence), and any important invariant, assumption, or trade-off established. Show a focused diff or example when it helps. Invite a response about the next meaningful step and wait; do not silently chain through the rest of the feature after one opening chat. A reply agreeing to a clear next-step proposal is enough; do not reconfirm it.

The user can redirect, ask questions, or stop. Answer a question without treating it as permission for the next step. Reconcile a redirect with the new scope before proceeding; do not carry approval for the old direction into a materially different change. If context is lost, recover the current agreement rather than inventing it. Preserve the active pairing mode and agreed boundary in any otherwise-required handoff or summary.

If a tiny task is finished in one step, say so without inventing another step or a quiz. At a natural end, close concisely with what was built and verified, the understanding or decisions established, and what remains open. Do not claim the user learned something that the conversation did not establish.

Exit

“Stop pairing”, “exit pair-programming”, or an equivalent explicit request ends this interaction mode. A request to finish autonomously is an explicit exit: acknowledge it and return to normal workflow for already-authorized work. Exit alone grants no new scope or permissions. Do not keep imposing pairing checkpoints after exit or persist the mode into a new session without a fresh request or explicit resume instruction.

Attribution and checks

Adapted from Channing Walton's pair-programming skill. Its emphasis on shared understanding, invariants, alternatives, and bounded changes is retained; its human-types default and prediction questions are not. The upstream MIT copyright and permission notice are preserved in LICENSE.upstream. Do not follow upstream installation instructions as part of pairing.

Run make test-pair-programming from this repository for offline contract checks. Scenario review instructions distinguish static checks and authored oracles from observed model behavior. These checks need Python 3.10+ (standard library); the skill itself adds no executable helper or provider call.