Home page
Back to articles
17 min readMehdi Hadeli

Shared Features in Claude Code and GitHub Copilot: What You Can Reuse and What Still Needs Separate Settings

claude-codegithub-copilotai-tools

On this page

Table of contents

Shared Features in Claude Code and GitHub Copilot: What You Can Reuse and What Still Needs Separate Settings

If you switch between Claude Code and GitHub Copilot, the first surprise is not model quality. It is file layout.

The two tools are close enough to make shared setup feel possible, but different enough to punish you if you assume everything is portable. That is why teams often end up with a messy prompt stack: one instructions file for Claude Code, another for Copilot, duplicated review prompts, duplicated MCP config, and a vague feeling that the setup should be simpler than it is.

It can be simpler, but only if you split your repo into two layers:

  • a shared layer that both tools can read reliably
  • a tool-specific layer for files whose location or schema still differs

That is the practical lesson I took from Rafferty Uy's write-up on Claude Code and GitHub Copilot cross-compatibility. This article expands that idea into a more detailed working model: what is genuinely shared today, what is only partially shared, what still needs separate files, and how to structure a repository so the overlap actually saves maintenance instead of creating subtle drift.

Where the article makes product-behavior claims, I have added links to the original Claude Code, VS Code, or GitHub Copilot documentation so you can verify the current behavior against the primary source rather than relying on a secondary summary.

The Short Version

If you only want the operating rule, use this:

  • Put common high-level instructions in CLAUDE.md.
  • Put reusable prompt snippets in .claude/prompt-snippets/.
  • Put reusable skills in .claude/skills/.
  • Keep language- or path-specific rules in .github/instructions/ as the source of truth.
  • Keep Claude-only wrappers in .claude/rules/.
  • Keep agent definitions separate in .claude/agents/ and .github/agents/, but make them thin wrappers that point to the same shared snippets.
  • Maintain both .mcp.json and .vscode/mcp.json because the wrapper format still differs.
  • Do not try to force settings, hooks, or memory into one shared file. Those are still separate concerns.

That is the whole strategy. The rest of the article explains why each part belongs where it does.

Why This Matters in Real Repositories

This is not just about tidiness.

Once a team starts relying on AI tooling for coding standards, review instructions, commit conventions, repo maps, and workflow shortcuts, prompt files become part of the project's operating system. If those files drift, the tools stop behaving consistently. One assistant follows the frontend rules, another ignores them. One review agent reads the security checklist, another uses an older copy. One tool knows how to start the dev environment, the other does not.

That inconsistency is worse than having no setup at all, because it creates false confidence.

The real goal is not "make every file shared." The real goal is "keep the shared intent in one place, and keep tool-specific wrappers as thin as possible."

What Is Actually Shared

The good news is that the shared layer is now large enough to be useful.

1. CLAUDE.md can be your common top-level instructions file

This is the biggest win.

Claude Code reads CLAUDE.md by design; Anthropic documents that behavior in its memory docs, including where CLAUDE.md can live and how it loads. VS Code also documents CLAUDE.md support for GitHub Copilot custom instructions, which is what makes it practical to use one top-level file instead of maintaining both CLAUDE.md and .github/copilot-instructions.md with overlapping content.

That does not mean Copilot ignores its own instruction files. It means CLAUDE.md is now a viable common denominator.

That matters because the top-level guidance is usually the part that changes least often:

  • coding philosophy
  • repository overview
  • testing expectations
  • review standards
  • naming conventions
  • commit message style
  • safe-editing rules

Those are exactly the kinds of instructions you do not want duplicated.

Here is a simple example:

# CLAUDE.md

## Project Defaults

- Prefer small, reversible edits.
- Run targeted tests after changes.
- Preserve existing public APIs unless the task requires a change.
- For frontend code, follow the standards in the shared snippets below.

## Review Checklist

- Check for behavior regressions first.
- Call out missing tests before style comments.
- Prefer root-cause fixes over defensive patching.

## Shared References

@.claude/prompt-snippets/coding-standards.md
[Coding Standards](./.claude/prompt-snippets/coding-standards.md)

@.claude/prompt-snippets/commit-style.md
[Commit Style](./.claude/prompt-snippets/commit-style.md)

The dual reference syntax looks redundant, but it is there for a reason:

  • Claude Code understands the @... import style inside CLAUDE.md.
  • GitHub Copilot and VS Code customizations can follow markdown file references.

That gives both tools a path to the same underlying snippet files.

Primary docs:

2. .claude/skills/ is a practical shared command layer

Reusable prompt skills are another strong overlap point. Claude Code documents skills in .claude/skills/, and VS Code documents both agent skills and prompt-style slash command files, which is the closest equivalent on the Copilot side.

Primary docs:

If you have recurring tasks such as these:

  • review a pull request
  • generate a commit message
  • inspect a failing test
  • summarize a bug report
  • plan a refactor

you can often define them once in .claude/skills/ and use that folder as a shared skill catalog.

A small example:

.claude/
  skills/
    review-pr/
      SKILL.md
    commit/
      SKILL.md
    bug-summary/
      SKILL.md

And a minimal skill file:

---
name: review-pr
description: Review code changes for bugs, regressions, and missing tests.
---

# Review Pull Request

Review the current changes with this priority order:

1. Functional regressions
2. Security or data-loss risk
3. Missing or weak tests
4. Maintainability issues

Keep style comments brief unless they affect correctness.

This is the kind of file that ages well because it contains workflow logic, not tool-specific plumbing.

3. Shared prompt snippets are the right place for reusable policy text

Prompt snippets are where a lot of teams save the most maintenance time.

These are not full agents or full instruction files. They are small chunks of reusable guidance such as:

  • frontend standards
  • API design rules
  • commit style guidance
  • review expectations
  • release checklist
  • test writing rules

I prefer keeping these in .claude/prompt-snippets/ when the goal is cross-tool reuse:

.claude/
  prompt-snippets/
    coding-standards.md
    commit-style.md
    review-standards.md
    frontend-standards.md

That works well because the snippets become the stable source material, while CLAUDE.md, agent files, and rules files can all point to them.

Here is a realistic snippet:

# review-standards.md

- Prioritize correctness over formatting.
- Explain why a change is risky, not just that it is risky.
- If no issues are found, state that explicitly and mention residual test gaps.
- Treat missing migration steps and config changes as findings when relevant.

This content is portable because it is plain markdown with no tool-specific schema.

What Is Only Partly Shared

This is where people usually over-assume compatibility.

The content may be shared, but the loading mechanism is not.

1. Agents can share prompt text, but not agent definition files

Claude Code and GitHub Copilot both support agent concepts. That does not mean the agent definition files are interchangeable.

Primary docs:

The safe pattern is:

  • keep the shared instruction body in a normal markdown snippet
  • create one thin agent wrapper for Claude Code
  • create one thin agent wrapper for GitHub Copilot

For example, put the real review policy here:

.claude/prompt-snippets/review-standards.md

Then create tool-specific wrappers.

Claude Code wrapper:

---
name: reviewer
model: sonnet
tools: ['Read', 'Edit', 'Grep', 'Glob']
---

You are a code reviewer.
Follow the review guidance in .claude/prompt-snippets/review-standards.md.

GitHub Copilot wrapper:

---
name: reviewer
---

You are a code reviewer.
Follow the review guidance in .claude/prompt-snippets/review-standards.md.

The frontmatter is different. The files live in different folders. The loading rules are different. But the real instruction body stays shared.

That is the correct level to share.

2. Path-specific rules share intent, not file format

Both tools let you scope instructions to subsets of the repo. That is useful for language-specific conventions or area-specific rules such as:

  • React component standards for src/**/*.tsx
  • Terraform rules for infra/**/*.tf
  • API rules for src/Controllers/**/*.cs

But the two tools represent that idea differently:

  • Claude Code uses .claude/rules/*.md with a paths: frontmatter field.
  • GitHub Copilot uses .github/instructions/*.instructions.md with applyTo: frontmatter.

Primary docs:

Since VS Code Copilot features outside strict agent mode also use .github/instructions/, that folder is usually the better source of truth.

A strong pattern looks like this.

Full rule in GitHub Copilot format:

---
applyTo: ['src/**/*.tsx', 'src/**/*.css']
---

# Frontend Standards

- Use functional components.
- Keep state local unless it is shared across screens.
- All interactive elements must be keyboard accessible.
- Prefer focused tests over snapshot-heavy coverage.

Thin Claude wrapper:

---
paths: ['src/**/*.tsx', 'src/**/*.css']
---

Follow the frontend standards in .github/instructions/frontend.instructions.md.

That gives you one canonical body and one lightweight redirect.

3. Prompt snippet references are shared, but the reference syntax is not identical

This is a subtle one.

You can share the underlying snippet files. You cannot assume every instruction surface resolves them the same way.

The safest mental model is:

  • snippet files are shared assets
  • each tool reads those assets through its own supported reference mechanism

That is why the dual-reference pattern in CLAUDE.md is so useful. It is explicit, ugly in a harmless way, and dependable.

What Is Not Shared

These are the parts where you should stop trying to unify everything.

1. MCP server configuration still needs two files

Both tools can use MCP servers. The protocol is shared. The config wrapper is not.

Primary docs:

That means the actual server payload is mostly portable:

  • command
  • args
  • env

But the enclosing file differs.

Claude Code expects something like this in .mcp.json:

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

GitHub Copilot in VS Code expects something like this in .vscode/mcp.json:

{
  "servers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

The inner server definition is the same. The top-level schema is not.

That means the maintenance rule should be:

  • duplicate the wrapper file
  • keep the server entries as mechanically similar as possible
  • avoid hand-editing them in different ways unless the tool requires it

If your repo uses several MCP servers, consider generating one file from the other in CI or with a small script. The important point is that you are syncing shape, not pretending the files are interchangeable.

2. Settings files are still separate

Claude Code settings and VS Code or Copilot settings are not one shared configuration surface.

Primary docs:

In practice, that means these concerns stay separate:

  • Claude Code settings in .claude/settings.json
  • editor and Copilot behavior in VS Code settings
  • local overrides in gitignored local settings files when appropriate

Trying to collapse them into one abstraction usually creates confusion. The names may sound similar, but they control different runtimes.

3. Hooks are different systems

Both ecosystems have hook concepts, but they are not the same thing and should not be documented as if they were.

Primary docs:

If you use hooks for actions like these:

  • post-edit checks
  • commit validation
  • notifications
  • environment setup

document the desired behavior once in prose, but keep the actual hook files separate.

4. Auto memory is not portable

Claude Code supports its own project memory model. GitHub Copilot does not expose an equivalent shared project-memory feature in the same way.

Primary docs:

That means team-critical preferences should not live only in Claude's memory layer. If they matter to both tools, promote them into versioned instructions.

That is an easy rule to remember:

  • personal preference can stay personal
  • team policy must live in the repo

A Repository Structure That Holds Up Well

Here is a layout that keeps shared content centralized without pretending the platforms are identical.

my-project/
├── CLAUDE.md
├── .mcp.json
├── .vscode/
│   └── mcp.json
├── .claude/
│   ├── settings.json
│   ├── settings.local.json
│   ├── prompt-snippets/
│   │   ├── coding-standards.md
│   │   ├── commit-style.md
│   │   ├── review-standards.md
│   │   └── frontend-standards.md
│   ├── skills/
│   │   ├── commit/
│   │   │   └── SKILL.md
│   │   └── review-pr/
│   │       └── SKILL.md
│   ├── agents/
│   │   └── reviewer.md
│   └── rules/
│       └── frontend.md
└── .github/
    ├── agents/
    │   └── reviewer.md
    └── instructions/
        └── frontend.instructions.md

This structure works because each folder has a clean job:

  • CLAUDE.md is the shared high-level entry point.
  • .claude/prompt-snippets/ holds reusable bodies of instruction text.
  • .claude/skills/ holds shared reusable tasks.
  • .github/instructions/ holds canonical scoped rules for the VS Code side.
  • .claude/rules/ mirrors those scoped rules through thin wrappers.
  • .claude/agents/ and .github/agents/ hold tool-specific wrappers around shared snippets.
  • .mcp.json and .vscode/mcp.json stay parallel because the schemas differ.

That separation keeps the maintenance burden honest.

A Practical Source-of-Truth Strategy

The easiest way to keep this setup maintainable is to assign one source of truth per kind of content.

Here is the strategy I would use on a team.

Shared high-level guidance

Source of truth: CLAUDE.md

Use it for:

  • project-wide behavior expectations
  • global review habits
  • editing philosophy
  • repo map
  • references to shared snippet files

Reusable policy text

Source of truth: .claude/prompt-snippets/

Use it for:

  • code review standards
  • commit style
  • coding conventions
  • security reminders
  • testing expectations

Scoped language or path rules

Source of truth: .github/instructions/

Use it for:

  • frontend rules
  • backend rules
  • infra rules
  • area-specific conventions tied to paths

Then mirror them into .claude/rules/ as lightweight wrappers.

Agent behavior

Source of truth: shared snippet files, not the agent wrappers themselves

Use agent wrapper files only to:

  • declare the agent in the format the tool expects
  • point to the shared instruction snippet

MCP configuration

Source of truth: conceptually shared, physically duplicated

In other words, the server definitions should match, but the files should remain separate.

A Worked Example: Sharing Review Standards Between Both Tools

Suppose your team wants one consistent review policy across Claude Code and GitHub Copilot.

Do it in three steps.

Step 1: write the real policy once

# .claude/prompt-snippets/review-standards.md

- Start with correctness, regressions, and data risk.
- Flag missing tests when a behavior change is introduced.
- Do not spend half the review on formatting unless formatting hides a real problem.
- If no issues are found, say so clearly and mention any remaining validation gaps.

Step 2: point CLAUDE.md at that policy

## Review Guidance

@.claude/prompt-snippets/review-standards.md
[Review Standards](./.claude/prompt-snippets/review-standards.md)

Step 3: make both agent definitions thin wrappers

Claude Code:

---
name: reviewer
model: sonnet
tools: ['Read', 'Grep', 'Glob']
---

You are a code reviewer.
Follow .claude/prompt-snippets/review-standards.md.

GitHub Copilot:

---
name: reviewer
---

You are a code reviewer.
Follow .claude/prompt-snippets/review-standards.md.

Now the agent definitions are tiny, and the policy can evolve in one place.

Common Mistakes to Avoid

1. Duplicating full instruction bodies in every tool-specific file

This feels fast at first. It becomes expensive the second your rules change.

2. Treating cross-compatibility as all-or-nothing

Some files are portable. Some are portable only at the content level. Some are not portable at all. The setup gets cleaner when you accept that distinction.

3. Hiding important team rules in personal memory or local settings

If the rule matters for shared work, put it in version control.

4. Letting wrappers become full copies

A wrapper should stay small. Once it starts carrying full policy text, you have lost the benefit of the shared layer.

5. Forgetting that non-agent VS Code Copilot features also matter

If your team uses Ask, Edit, or completion surfaces in VS Code, .github/instructions/ is more valuable than it first appears. That is one reason it is a better home for canonical path-specific rules than .claude/rules/. VS Code’s custom-instructions docs make that broader IDE integration explicit.

Recommended Operating Rules for Teams

If I were setting this up for a team instead of just for myself, I would document these rules directly in the repo:

  1. CLAUDE.md is the shared high-level instruction file.
  2. Shared instruction text lives in .claude/prompt-snippets/.
  3. Reusable commands live in .claude/skills/.
  4. Scoped rules live in .github/instructions/ first.
  5. .claude/rules/ and agent files must remain thin wrappers.
  6. MCP server definitions must be kept equivalent across .mcp.json and .vscode/mcp.json.
  7. Team-critical behavior must not rely on tool-specific memory.

Those seven rules are enough to keep most repos from turning into prompt sprawl.

The Real Compatibility Model

The easiest way to think about Claude Code and GitHub Copilot is not "they support the same things."

It is this instead:

  • they share a meaningful prompt layer
  • they do not share every config surface
  • they are easiest to manage when shared content and tool-specific wrappers are kept separate on purpose

That model is practical because it matches how the tooling behaves today.

If you design around that reality, you can reuse a lot:

  • one main instructions file
  • one set of reusable snippets
  • one skill catalog
  • one source of truth for scoped coding rules
  • one body of review or commit policy text

And you only duplicate the parts that genuinely need separate files:

  • MCP config wrappers
  • agent definition wrappers
  • rule wrappers
  • settings and hooks

That is a much better trade than trying to force total unification and ending up with hidden inconsistencies.

Final Take

The overlap between Claude Code and GitHub Copilot is now strong enough to justify a shared prompt architecture. The mistake is expecting a shared settings architecture in the same sense.

Use one shared layer for instructions, snippets, and reusable skills. Use thin, explicit wrappers for the parts each tool still models differently. Keep team rules in versioned files, not in personal memory. And when a config format differs, duplicate the wrapper cleanly instead of pretending the tools will reconcile it for you.

That approach is not glamorous, but it is stable. In practice, stability is what makes AI tooling useful on real projects.