Building an Agentic Development Harness: From GitHub Copilot Instructions to Cross-Framework Context

Most developers using GitHub Copilot already know the first big unlock: create a copilot-instructions.md file.

That single file can dramatically improve output quality because it changes GitHub Copilot from a general assistant into a repository-aware collaborator. Instead of re-explaining your architecture in every prompt, you define it once and let the agent carry that context into each task.

Think of it like onboarding a new senior engineer.

Without instructions, they are smart but unfamiliar with your codebase. They can still help, but they will ask the same foundational questions repeatedly. With instructions, they start with your architecture map, coding standards, and operating constraints on day one.

The Starting Point: copilot-instructions.md

In a GitHub Copilot setup, place this file at:

• .github/copilot-instructions.md

This is your always-on baseline guidance for GitHub Copilot in that repository.

A strong copilot-instructions.md should include:

1. Project purpose and architecture summary
2. Source-of-truth documentation links
3. Non-negotiable coding patterns (for example, node signatures, state handling, validation rules)
4. Tooling and workflow constraints (for example, issue/PR handling expectations)
5. Safety rails (what not to do)

In any repository, this file is intentionally focused on GitHub Copilot-specific behavior: MCP-first GitHub workflow, custom agents, custom skills, and issue-closing discipline.

Why This Is Only the Beginning

Eventhough copilot-instructions.md gives you baseline consistency, for serious agentic development, baseline consistency is not enough.

You also want:

• Workflow-level specialization
• Role-level specialization

In GitHub Copilot terms, these are implemented through skills and agents.

Skills: Reusable Workflows for Narrow Jobs

A skill captures a repeatable procedure for a specific class of work. It is narrower than global instructions and more actionable than generic advice.

In practice, a skill usually contains:

1. Trigger description (when to use it)
2. Required references to read first
3. Step-by-step workflow
4. Guardrails and anti-patterns
5. Done checklist

In my private YouTube Creator Ops Agent project (featured on my YouTube channel in the video "How I Built a YouTube Creator Ops Agent With LangGraph and Human Review"), I have used this method extensively.

The skills are organized under .github/skills/:

• implement-langgraph-node: implement or fix a LangGraph node with repository-specific node/state conventions
• wire-langgraph-routing: modify graph routing, ordering, revise loops, and interrupt boundaries safely
• add-llm-task: add or update prompt-driven generation tasks, provider wiring, validation, and retries
• update-youtube-integration: update YouTube read/write integrations with correct API-key/OAuth behavior
• manage-artifacts-and-drafts: control local artifact output and draft lifecycle behavior
• author-repo-tests: add and update unit, integration, smoke, and e2e coverage with the right test-layer choice

The important point is this: skills are not generic Python checklists. They are repository-shaped workflows.

Agents: Role-Based Operators

If skills are specialized procedures, agents are specialized roles.

An agent definition typically contains:

1. Role description and boundaries
2. Tool permissions
3. Delegation options
4. Working constraints
5. Output contract

In the same private project, agents are defined under .github/agents/:

• Creator Ops Architect: planning-focused agent for scoping features, mapping impact, and identifying risks before coding
• Pipeline Engineer: implementation-focused agent for graph, LLM, routing, prompt, and artifact changes
• QA and Smoke Agent: validation-focused agent for targeted tests and coverage gaps
• GitHub Workflow Steward: workflow-focused agent for issue/PR readiness and dependency-aware GitHub operations

This role separation is what keeps multi-step coding tasks coherent. Planning, implementation, validation, and GitHub workflow are treated as different cognitive jobs.

How Instructions, Skills, and Agents Work Together

These three are complementary layers, not competing layers.

1. copilot-instructions.md sets always-on repository and workflow rules
2. Skills provide narrow, repeatable playbooks for specific tasks
3. Agents apply role-specific behavior and tool boundaries while executing end-to-end work

When GitHub Copilot receives a coding task, it effectively combines these layers:

• It starts from global instructions
• It identifies which role (agent) should drive the task
• It applies relevant skills to execute with the right workflow details

This is the difference between "AI that can code" and "AI that can operate reliably inside your engineering system."

The Multi-Agent Reality: GitHub Copilot Is Not Always the Only Tool

Everything above is highly effective for GitHub Copilot. But many developers switch between tools.

A common real-world example:

• GitHub Copilot for one session
• Codex for the next session
• Sometimes Claude Code in another workflow

If your context scaffolding is GitHub Copilot-only, every context switch causes capability loss. The new tool no longer sees your operational playbook the same way.

Making the Setup Framework-Agnostic with AGENTS.md

The practical solution is to keep a framework-agnostic core context file:

• AGENTS.md at repository root

In this repository, AGENTS.md carries the shared architecture, conventions, design decisions, module status, and implementation patterns. GitHub Copilot-specific files then layer on top of it.

That gives you a clean split:

1. Portable context in AGENTS.md (for GitHub Copilot, Codex, and similar coding agents)
2. GitHub Copilot-specific orchestration in .github/copilot-instructions.md, .github/skills/, and .github/agents/

With this pattern, context switching becomes practical because your foundational guidance remains stable across frameworks.

Extending the Same Idea to Claude Code

The same concept extends naturally to Claude Code.

You can keep:

• AGENTS.md as the canonical, shared project context

And add:

• Claude-specific adapter guidance only where needed

The key design principle is to avoid duplicating full architecture content across multiple tool-specific files. Keep one canonical source and let framework-specific files describe only the delta.

Your Own Custom Harness

At this point, you are no longer just adding docs. You are building a custom harness for agentic software development.

That harness has three properties:

1. It is explicit (clear rules instead of prompt-by-prompt memory)
2. It is layered (global baseline plus specialized workflows and roles)
3. It is portable (core context survives tool switching)

That is the real evolution path:

• Start with copilot-instructions.md
• Add skills for recurring workflows
• Add agents for role boundaries
• Anchor shared context in AGENTS.md for framework-agnostic operation

Once this is in place, your AI tooling stops behaving like a set of disconnected assistants and starts behaving like a coordinated engineering system.