Stop Teaching the AI. Teach the Repository. Claude Code Has Skills, Agents and Hooks. So Does the Pattern.

Stop Teaching the AI. Teach the Repository.

Claude Code Has Skills, Agents and Hooks. So Does the Pattern.

Something interesting is happening in AI-assisted software engineering.

Developers keep asking:

Which AI should we standardize on?

Claude Code? GitHub Copilot? Cursor? Gemini? Something that hasn’t been released yet?

I think that’s increasingly the wrong question.

A better question is:

How do we engineer a repository so that an AI coding agent understands how work is supposed to be done?

That’s a much more durable problem to solve.

And once you look at Claude Code and GitHub Copilot through that lens, the similarities become more interesting than the differences.

The Repository Is Becoming an AI Operating Environment

We’ve traditionally thought of a repository as:

Source code + configuration + tests + documentation.

Agentic development changes that.

A modern AI-ready repository can contain:

Code + Intent + Instructions + Skills + Agents + Hooks + Contracts + Validation

The repository doesn’t merely contain the application anymore.

It teaches an AI how to work on the application.

That’s a significant architectural shift.

Start With the Claude Code Mental Model

Claude Code makes this relatively easy to understand.

You can provide repository instructions, reusable Skills, specialized agents, deterministic Hooks, MCP tools and an Intent describing what needs to become true.

The important part isn’t the terminology.

It’s the separation of responsibilities.

Instructions

Persistent context:

This is how we work in this repository.

Skills

Reusable procedural knowledge:

This is how we perform this type of work.

Agents

Specialized, bounded workers:

This is who should reason about this particular problem.

Hooks

Deterministic enforcement:

This must happen regardless of what the AI decides.

MCP / Tools

External capabilities:

This is how the agent obtains context or performs actions outside the repository.

Intent

The outcome contract:

This is what must become true.

Put them together and you stop relying entirely on prompts.

You begin engineering the environment in which the agent operates.

Now Look at GitHub Copilot

Here’s where it gets interesting.

GitHub Copilot increasingly exposes many of the same architectural primitives.

A Copilot-ready repository can contain structures along these lines:

.github/

│

├── copilot-instructions.md

│

├── instructions/

│   ├── api.instructions.md

│   └── intent.instructions.md

│

├── skills/

│   ├── start/

│   │   └── SKILL.md

│   ├── intent-creator/

│   │   └── SKILL.md

│   └── execute-intent/

│       └── SKILL.md

│

├── agents/

│   ├── architecture-reviewer.md

│   └── intent-normalizer.md

│

└── hooks/

    └── secret-guard.json

AGENTS.md

INTENT.md

Different platform.

Very familiar architecture.

Here’s the Translation

If you’re already comfortable with Claude Code, don’t relearn everything from zero.

Think conceptually:

Engineering Concept

Claude Code

GitHub Copilot

Repository operating rules

CLAUDE.md

Copilot instructions / AGENTS.md

Reusable knowledge

Skills

Skills

Specialized worker

Agent/Subagent

Custom Agent/Subagent

Deterministic enforcement

Hooks

Hooks

External capabilities

MCP/Tools

MCP/Tools

Desired outcome

Intent

Intent

Evidence

Tests/validation

Tests/validation

The implementation details matter.

But the engineering principles matter more.

Let’s Build a Tiny One

Suppose I want every AI working in my repository to follow one simple rule:

Understand the repository before changing it.

Instead of typing that into every prompt, make it reusable.

Create something conceptually like:

.github/skills/start/SKILL.md

The Skill could tell the agent:

Before editing:

1. Locate repository guidance.

2. Identify languages and frameworks.

3. Find the closest existing implementation.

4. Identify reusable capabilities.

5. Discover build, test and lint commands.

6. Determine the smallest safe implementation surface.

7. Report blockers before introducing new architecture.

Now we’ve moved knowledge out of somebody’s head—and out of a temporary chat prompt—and placed it with the software.

That’s powerful.

Add a Specialized Architecture Agent

Maybe architecture review deserves isolated reasoning.

Create a bounded architecture reviewer.

Its job isn’t to write code.

Its job is to answer:

What pattern already exists?

What is the smallest required delta?

What can be reused?

What architectural impact does this introduce?

What are the risks?

What evidence supports the recommendation?

Recommendation:

REUSE / EXTEND / NEW ARCHITECTURE

Then restrict its tools.

Maybe it can read and search, but not modify code.

That’s intentional.

An agent shouldn’t receive every tool merely because the platform supports them.

Minimum sufficient context. Minimum sufficient authority.

Now Add a Hook

Suppose secrets absolutely cannot enter the repository.

You could write:

Please make sure you don’t commit credentials.

That’s useful guidance.

But it’s still guidance.

Instead, attach a deterministic secret scan to an appropriate lifecycle event.

Now the architecture becomes:

Agent finishes work

        ↓

Secret Guard Hook

        ↓

Inspect changed content

        ↓

Credential detected?

     /             \

   YES              NO

    ↓                ↓

  FAIL            CONTINUE

That’s the distinction between asking AI to behave and engineering a boundary.

Don’t Bring an Agent to a Skill Job

This may be the most important lesson.

Agentic engineering does not mean:

Planner Agent

    ↓

Architecture Agent

    ↓

Developer Agent

    ↓

Testing Agent

    ↓

Security Agent

    ↓

Documentation Agent

for every feature.

That’s architecture theater.

Sometimes the correct workflow is simply:

INTENT

   ↓

SKILL

   ↓

IMPLEMENT

   ↓

TEST

   ↓

EVIDENCE

Use an agent when specialization, isolation, parallel reasoning or restricted authority provides actual value.

Use a Skill when you’re encoding reusable knowledge.

Use a Hook when something must be enforced.

Use a Tool when an external action must occur.

And use orchestration only when the problem actually requires orchestration.

This Is Bigger Than Copilot or Claude

That’s the part I find most interesting.

Imagine defining an enterprise engineering capability once:

             ENGINEERING CAPABILITY

                      │

        ┌─────────────┼─────────────┐

        ▼             ▼             ▼

      Intent       Contracts     Governance

        │             │             │

        └─────────────┼─────────────┘

                      ▼

              Engineering Patterns

                      │

                      ▼

               Vendor Adapters

                      │

       ┌──────────────┼──────────────┐

       ▼              ▼              ▼

   Claude Code     Copilot         Cursor

Now we’re not betting the enterprise on one AI.

We’re betting on engineering.

Claude may package something one way.

Copilot may package it another way.

Cursor may introduce another mechanism.

Those implementations will continue changing.

But concepts like intent, context boundaries, reusable knowledge, specialized workers, deterministic governance, contracts and evidence are much more durable.

Your First AI-Native Repository Doesn’t Need to Be Complicated

Start small.

Give the repository:

1. An Intent contract

Define what needs to become true.

2. Repository instructions

Define how engineering work should be performed.

3. One useful Skill

Capture a procedure your team repeats constantly.

4. One bounded Agent

Use it only where specialized reasoning genuinely helps.

5. One meaningful Hook

Automate a rule that should never depend solely on AI judgment.

6. Validation

Require evidence before declaring completion.

Then use it.

Break it.

Learn from it.

Improve the pattern.

That’s how engineering practices emerge.

The Bigger Idea: AI Shouldn’t Own Your Engineering System

The AI model will change.

The IDE will change.

The agent framework will change.

The terminology will definitely change.

Your engineering principles shouldn’t have to.

That’s why I believe the future isn’t simply AI-assisted coding.

It’s repositories that carry enough intent, context, procedure, governance and evidence that multiple capable AI systems can operate within them safely.

The AI becomes replaceable.

The engineering system remains.

That’s the direction we’re exploring with Intent-Driven Engineering and Learn Teach Master:

Learn it.

Teach it.

Turn it into a pattern.

Govern the pattern.

Then let the AI execute it.

And maybe the most important principle of all:

Don’t teach every AI your engineering process from scratch. Teach the repository.