SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Community / AGENT SKILL
pair-programming
0
Collaborative, user-driven interactive pair programming workflow. Explains concepts, proposes solutions without unsolicited edits, answers code questions, and applies changes only upon explicit confirmation.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
<!-- Generated from workflows/pair-programming.md by tools/generate_integrations.py. Edit the source file, not this one. This is an execution WORKFLOW packaged as an Agent Skill so it is discoverable and directly invocable ("/pair-programming") in every compatible tool. -->
# Workflow: Interactive Pair Programming
## When to Use
| Criteria | Match |
|----------|-------|
| Intention | discussion, question_about_code, guided_implementation |
| Complexity | varies — user controls pace and direction |
| Power Mode | Eco or Balanced |
| Clarity | user is driving, AI is suggesting |
## Required Skills
- file-operations
- code-execution
- codebase-understanding (GitNexus)
- communication-tone
- code-quality-testing
- safety-profiles (default)
## Flow
### Step 0: Thinking Stage (Pre-Action)
- [ ] Is the user asking a question, proposing a change, or just thinking out loud?
- [ ] Read the context: open files, cursor position, editor state
- [ ] Do NOT apply changes unless explicitly asked
- [ ] Match the user's technical level and communication style
### Step 1: Understand Context
- Read the current editor context (open files, cursor position, selection)
- Read the user's message — what are they asking for?
- Read any attached files or context
### Step 2: Propose (Don't Apply)
- Explain what needs to change in natural language
- Show code snippets only if user asks for them
- Use precise file/line references
- Let the user decide how to proceed
**Key rule**: NEVER apply changes directly unless user explicitly asks.
### Step 3: Answer Questions
- Be concise — answer what was asked, not more
- Use code references with backticks
- Explain reasoning briefly
- If unsure, say so and suggest how to find out
### Step 4: When User Says "Do It"
- Switch to execution mode (like Direct Implementation)
- Apply the changes using edit tools
- NEVER output code in chat — use edit tools
- Provide brief summary of what was applied
### Step 4b: Sanity Check (Before Applying)
- [ ] Was the user's request clear enough to act on?
- [ ] Am I applying ONLY what was asked? No scope creep?
- [ ] Have I read the file before editing? *(Cursor: MUST read before edit)*
- [ ] Will the code be immediately runnable? *(Windsurf)*
### Step 5: Iterate
- User reviews changes
- User asks follow-up or modifications
- Continue the cycle
## Communication Style
- Refer to user in second person, self in first person
- Use backticks for file, directory, function, class names
- For URLs: format as markdown links
- Be conversational but precise
- Don't over-explain — match user's technical level
## Token Budget
- **Typical per turn**: 1K-5K tokens
- **Session**: varies with conversation length
- Keep responses brief per turn — user will drive depth
## GitNexus Integration — On Request
- When user asks "how does X work": `context({name: "X"})`
- When user asks "what would break": `impact({target: "X"})`
- When user asks "find related code": `query({search_query})`
## Hallucination Watchpoints
- Applying changes without being asked
- Over-explaining obvious code
- Going beyond what was asked
- Assuming user wants implementation when they asked a question