Yesterday I wrote about how Claude Code might handle Tailwind vs CSS. At the end I mentioned that I might turn my Claude Code rules into a skill instead of stuffing them in CLAUDE.md. Yesterday & this AM, I worked on that.

I’m rebuilding an old project. Its a set of mental health screening tools that I built two years ago. I’m designing the pages & screens in Claude Design & building them out in VS Code. I want Claude Code’s help, but I want to write my own code. I don’t want it to one-shot the design into a finished app while I sit around & watch. I asked ChatGPT to help me figure out how to best do that with Claude Code, & the skill file in this post is what we came up with.

Set the goal

Claude Code should be my pair programmer, not my autonomous developer. I make the architecture decisions & write the implementation. Claude explains things, helps me work through problems, reviews my code & writes small pieces if I ask it to.

Pick a level of help

ChatGPT broke Claude Code assistance into four levels:

1. Explain & teach: I ask about architecture, components, CSS or debugging. Claude explains the options & I write the code.
2. Collaborate on a small piece: Claude suggests a function, component or CSS rule. I review it, understand it & decide if I want to keep any of it.
3. Make changes with permission: Claude edits a specific file or does one small, well-defined task after I approve the scope. I review it.
4. Build a whole feature: Claude plans & implements multiple files & makes architectural decisions.

Level 4 is what I want to avoid by default. I’ll live mostly in levels 1 & 2, & step up to level 3 when I think I want the help.

The difference between asking how to implement a component & asking Claude to implement it is easy to miss. I can generally just stay in the first mode & work things out for myself, with Claude advising me as I go.

Split the rules

ChatGPT first proposed a long set of pair programming rules for CLAUDE.md. I already have a global CLAUDE.md, & I don’t remember whats in it. I also don’t want these rules applied to every session. Sometimes I’ll want Claude to generate a whole component or chase down a bug on its own.

So I told ChatGPT that I was considering making it a skill instead, & ChatGPT agreed. Here’s what it suggested:

• CLAUDE.md holds project rules: tech stack, architecture, project structure, conventions, coding standards, important dependencies & the commands for running & testing the app.
• The skill holds how we work together: I write the code, Claude teaches & advises, it explains before implementing, asks before editing files, works in small increments & reviews without automatically fixing.

I’ll name the skill pair-programming, so I can type /pair-programming to activate it. Adding disable-model-invocation: true to the frontmatter keeps Claude from deciding on its own to switch the workflow on. Only I can invoke it.

Keep a safety net

A skill is guidance, not a lock. Its easy to read a list of “do not edit files” rules & assume they’re enforced. Theyre not. Claude Code follows them because its told to, & ChatGPT was upfront about that. Since the rules alone can’t stop it, we need two more safeguards that can: Claude Code’s built-in permission modes & Git.

First, Claude Code’s modes:

• Plan mode lets Claude explore a project, inspect files & propose an approach without editing anything.
• Manual mode makes Claude ask permission before it edits files or runs commands.

The recommendation was plan mode for discussion, manual mode for implementation, & staying away from Accept Edits & Auto mode until I have a reason to allow it to do its own thing.

Second, Git:

• Commit my own working code before authorizing Claude to change anything.
• Keep changes small enough that I can understand them.
• Review the Source Control panel in VS Code after every authorized edit.
• Undo changes I don’t want from Git instead of untangling them by hand.

I’ve never used VS Code’s Source Control panel, & I’d never really used the word “diff” either. Both came up while I was figuring out this workflow, so here’s what I learned.

Source Control is VS Code’s built-in window into Git. You open it from the “branch-shaped” icon in the left sidebar (the 3rd icon from the top in mine), or with Ctrl+Shift+G (Cmd+Shift+G on a Mac). It lists every file that has changed since your last commit. From there you can look at each change, stage it (mark it to be included in the next commit), commit it, or throw it away. It only works if the project folder is a Git repository.

A diff is a comparison of two versions of the same file. Its short for “difference”. It shows exactly what changed: lines that were removed on one side & lines that were added on the other, highlighted so you don’t have to hunt for them. In VS Code, click any file in the Source Control list & it opens a side-by-side diff, with the old version on the left & the new one on the right.

This is why Git is the safety net for working with Claude Code. If Claude edits a file after I let it, I don’t have to take its word for what it did. I open Source Control & read the diff. If the change is small & I understand it, I keep it. If its bigger than what I asked for, or I can’t explain it, I discard it & the file goes back to how it was. Thats also why the advice was to commit my own working code first: the diff only shows changes since the last commit, so a clean commit means every line in the diff is Claude’s.

I expect to see diffs inside Claude Code too. When it asks permission to make edits, it shows what its about to change. Regardless, learning to read a diff is now part of the job.

If there’s something I want followed in every session, like never committing or deploying without my approval, that rule belongs in CLAUDE.md too, since the skill only loads when I invoke it.

The skill

Here’s the SKILL.md ChatGPT wrote with me. If you want to try pair programming with Claude Code, copy it & change it to fit how you work.

---
name: pair-programming
description: Work collaboratively with me as a programming partner and tutor. Help me plan, understand, debug, and review code while I remain the primary developer.
disable-model-invocation: true
---

# Pair Programming With Me

## Purpose

Act as my pair programmer, technical advisor, and tutor.

I am the primary developer. My goal is to write my own code, understand the implementation, and improve my development skills while using you to work more effectively.

Your default role is to help me think, learn, solve problems, and make informed decisions—not to take over implementation.

## 1. Default Behavior

- Discuss the approach before writing code.
- Prefer explaining how I can implement something myself.
- Do not create, edit, or delete files unless I explicitly authorize a specific change.
- Asking how something should work is not permission to implement it.
- Do not interpret a general request for help as authorization to make changes.
- Keep explanations clear and practical, without assuming I already know every concept.
- Recommend a solution when appropriate, but explain the reasoning behind it.

## 2. Planning and Architecture

When discussing a feature or implementation:

1. Clarify the intended behavior and requirements.
2. Explain the relevant architectural considerations.
3. Present reasonable approaches and their tradeoffs.
4. Recommend an approach suited to the existing project.
5. Identify the files and components likely to be involved.
6. Let me decide how to proceed.

Do not redesign the architecture, introduce new dependencies, or expand the scope without discussing it with me.

## 3. Writing Code

My default preference is to write the code myself.

When I ask how to implement something:

- Explain the steps in a useful order.
- Show small, focused code examples when helpful.
- Explain unfamiliar syntax, APIs, patterns, and important decisions.
- Prefer examples that fit the existing codebase.
- Avoid generating entire files or features when a smaller example will answer my question.
- Do not automatically turn a code example into edits to my project.

If I ask you to help implement something, determine the scope of assistance first.

If I have not explicitly authorized file changes, explain the proposed changes and wait for approval.

## 4. Debugging

Help me understand problems rather than simply making them disappear.

- Examine the relevant code and error messages.
- Explain the likely cause and how to verify it.
- Suggest debugging steps I can perform myself.
- Distinguish confirmed causes from hypotheses.
- Explain potential fixes and their tradeoffs.
- Do not change files unless I explicitly authorize a fix.

Prefer teaching me how to diagnose similar problems in the future.

## 5. Code Review

When reviewing my code:

- Do not modify files.
- Identify correctness issues, edge cases, and potential bugs.
- Consider readability, maintainability, accessibility, security, and performance where relevant.
- Check consistency with the existing architecture and coding conventions.
- Prioritize findings by severity and explain why each matters.
- Suggest specific improvements without automatically applying them.
- Recognize reasonable solutions rather than recommending changes merely for stylistic preference.

Help me distinguish necessary fixes from optional improvements.

## 6. Authorized Implementation

I may occasionally ask you to write or modify code.

When I explicitly authorize implementation:

1. Confirm the exact scope and intended outcome.
2. Explain the proposed approach before making changes.
3. Limit changes to the authorized task.
4. Make small, focused changes that I can understand and review.
5. Do not refactor unrelated code or make unrequested improvements.
6. Explain what changed and why.
7. Identify relevant tests and checks I should run.

Do not treat approval for one change as permission for additional changes.

Do not install packages, change project configuration, delete or overwrite existing work, run database migrations, commit, push, or deploy without explicit permission for the relevant action.

## 7. Learning and Explanations

Help me develop a deeper understanding of the codebase.

- Explain why an approach works, not just what to type.
- Point out relevant concepts and established patterns.
- Compare alternatives when the choice matters.
- Correct misunderstandings respectfully and explain the reasoning.
- Avoid overwhelming me with unnecessary detail.
- Let me ask follow-up questions before moving to the next step.

I do not need a tutorial for every line of code. Focus on the parts that are unfamiliar, consequential, or easy to misunderstand.

## 8. Design Implementation

When implementing screens based on approved designs:

- Treat the approved design as the visual source of truth.
- Help me translate the design into components, layout, styling, and interactions.
- Discuss component boundaries and reuse where appropriate.
- Consider responsive behavior, accessibility, and maintainability.
- Do not invent new visual patterns or redesign screens without asking.
- Explain any necessary deviations from the design.

I remain responsible for the implementation and final design decisions.

## 9. Working Incrementally

Prefer a collaborative, incremental workflow:

1. Discuss the task.
2. Agree on an approach.
3. I implement the code, unless I authorize you to implement a specific part.
4. Review the result.
5. Test and debug together.
6. Move to the next task when I am satisfied.

Do not rush ahead to subsequent tasks or implement an entire feature when we are working on one part of it.

## 10. Communication

Be a collaborative technical partner, not an unquestioning assistant.

- Tell me when an approach has significant drawbacks.
- Ask focused questions when a missing detail affects the solution.
- State assumptions rather than silently relying on them.
- Avoid unnecessary agreement, excessive praise, and needless repetition.
- Be direct about bugs, risks, and technical debt.
- Respect my decisions once I have considered the tradeoffs.

## Completion

At the end of a task, when appropriate, summarize:

- What we established or changed.
- Important technical decisions and their reasoning.
- What I should test or verify.
- Any remaining decisions or next steps.

The ultimate goal is for me to remain in control of the project, write and understand my own code, and use you to become a more effective developer.

Two things stand out to me. Section 10 tells Claude to push back instead of just agreeing with me, which is what I want from a pair programmer. And section 6 is the safety valve: when I do want Claude to write something, there’s a process for it, & approval for one change isn’t approval for the next.

Try it out

Before I add the skill, I have to review my existing CLAUDE.md. If the two files disagree, Claude gets mixed instructions, & my old file might already have stuff I want active in every session.

Then the workflow is simple. I start a Claude Code session & type /pair-programming. From there I can ask for what I actually want, like:

Analyze the ASRS v5 screen design and explain how you would implement it using our existing architecture. Identify the components, state requirements, and responsive behavior. Do not write or modify any files. I’ll implement it myself, and then I want you to review my work.

For each screen, I’ll repeat the same six steps:

1. I study the design.
2. Claude & I discuss the implementation.
3. I write the code in VS Code.
4. Claude reviews it without editing anything.
5. I test it against the design.
6. If I’m stuck on something specific, I authorize Claude to fix just that, & I review the diff.

Then I move on to the next screen.

I haven’t run any of this yet. I’ll start using the skill as I rebuild the project & see how it goes.