GitHub Copilot Is Powerful. Unstructured Copilot Is Chaos.
GitHub Copilot can write code, refactor systems, and build features end to end. But without structure, it fails in four predictable ways: scope creep (it expands beyond what you asked), lost context (it forgets decisions from 20 messages ago), no visibility (you never see what it decided or why), and no quality gate (work ships without review).
Ghost Protocol solves all four. It gives Copilot a team of 8 named specialist agents, each with defined expertise, boundaries, and opinions. It gives every task a structured execution pattern with human checkpoints built in. And it connects the two with dual routing: every task gets assigned both an agent (who does the work) and a pattern (how the work is structured).
The result: you describe the work, Copilot routes to the right specialist and execution pattern, executes within guardrails, and presents structured output for your review. Then it disappears.
| Failure Mode | What Happens | Ghost Protocol Fix |
|---|---|---|
| Scope creep | Agent expands beyond what you asked | Thread patterns enforce scope limits and escalation triggers |
| Lost context | Agent forgets decisions from 20 messages ago | Agent history files and team decisions persist across sessions |
| No visibility | You don't know what the agent decided or why | Structured output, decision logging, Scribe session archive |
| No quality gate | Work ships without structured review | Core Four framework, Review Thread, agent-specific quality checks |
How It Works with Copilot
Ghost Protocol ships with a .github/copilot-instructions.md file. When Copilot reads this file, it knows all 8 agents, all 9 thread patterns, and the routing rules that connect them. No plugins, no extensions, no configuration. Just markdown that teaches Copilot the framework.
Here is what that looks like in practice:
$ ghost-protocol init
# Routing to EECOM + Chain Thread...
C-THREAD: Payment System | Phase 1/4 | Agent: EECOM
CURRENT PHASE: Stripe integration
STATUS: Complete
HANDOFF TO: CAPCOM -- webhook contracts ready
# CHECKPOINT: Approve and continue to Phase 2? [Y/n]
You describe the work. Copilot identifies the right specialist and execution pattern. It executes the first phase, presents a checkpoint, and waits for your approval before continuing. Each phase can hand off to a different specialist. Every handoff is explicit. No implicit context transfer.
Installation
git clone https://github.com/lloydpilapil/ghost-protocol.git
cd ghost-protocol
chmod +x install.sh
./install.sh /path/to/your/project
This copies .ghost-protocol/ (agents, patterns, routing, ceremonies) and .github/copilot-instructions.md into your project. Open Copilot and the framework is active.
The 8 Agents
Ghost Protocol defines 8 named specialist agents. Not generic bots wearing hats. Each agent has a charter (behavioral contract), persistent history, defined boundaries, and a voice that shapes how it approaches work. Names follow the NASA Mission Control convention from Squad by Brady Gaster.
THE 8 AGENTS
Named specialists with charters, boundaries, and persistent memory
Flight
Architect
EECOM
Developer
FIDO
Quality
Procedures
Prompts
PAO
Docs
CAPCOM
Integration
RETRO
Security
Scribe
Logger
Coordinator routes tasks to agents. Does not write code. Selects both the specialist and the thread pattern.
Scribe runs silently in the background after every thread. Logs sessions, archives decisions.
| Agent | Role | What They Own | Thread Affinity |
|---|---|---|---|
| Flight | Lead / Architect | Architecture decisions, code review, scope evaluation | Fusion, Big |
| EECOM | Core Developer | Implementation, runtime, core modules, bug fixes | Base, Chain, Long, Zero |
| FIDO | Quality Owner | Tests, coverage, CI/CD, quality gates | Review, Zero verification |
| Procedures | Prompt Engineer | Agent charters, coordination logic, spawn templates | Big (sub-agent design) |
| PAO | Docs / DevRel | README, API docs, user-facing messaging | Base (docs), Chain (docs phase) |
| CAPCOM | Integration Specialist | External APIs, SDK usage, platform patterns | Chain, Big |
| RETRO | Security | Security review, PII, compliance, auth patterns | Review (security checks) |
| Scribe | Session Logger | Session logs, decision archival, history | Background after all threads |
Each agent has a charter.md that defines identity and behavioral rules, a history.md that persists learnings across Copilot sessions, and clear boundaries about what they handle and what they escalate. When an agent finishes work, their learnings persist. When a team decision affects multiple agents, it goes to decisions.md. Agents remember past patterns, decisions, and failures instead of starting blank.
Dual Routing: Every Task Gets a Who and a How
This is the core innovation. Every task is assigned both a specialist agent (who) and a thread pattern (how). Not one or the other. Both.
DUAL ROUTING
Every task is routed to who (agent) and how (thread pattern)
TASK
"Build payment system: schema, API, checkout, tests"
COORDINATOR
WHO
EECOM
Phase 1-3
CAPCOM
Phase 2
FIDO
Phase 4
RETRO
Phase 4
HOW
CHAIN THREAD (C-Thread)
Schema
checkpointStripe API
checkpointCheckout UI
checkpointTests + Security
Result: 4 specialists execute 4 sequential phases with human checkpoints between each
Here is how routing works in real Copilot conversations:
You say: "Fix the pagination bug. Off-by-one error returning 9 items instead of 10."
Copilot routes to EECOM + Base Thread. EECOM executes a scoped fix, presents for review. Done.
You say: "Build the auth system. Phase 1: database schema. Phase 2: API routes. Phase 3: frontend. Phase 4: tests and security."
Copilot routes to EECOM + CAPCOM + FIDO via Chain Thread. Sequential phases with explicit handoffs. EECOM writes the schema, hands off to CAPCOM for API integration, back to EECOM for frontend, then FIDO and RETRO for testing and security review. Human checkpoint between every phase.
You say: "Evaluate WebSocket vs SSE vs polling for real-time dashboard updates."
Copilot routes to Flight + Fusion Thread. Three strategies compete. Flight evaluates trade-offs. You pick the winner.
You say: "Add Zod validation to all 12 API routes."
Copilot routes to EECOM + Zero Thread. Fully autonomous. FIDO must approve test coverage first. Max 3 self-fix attempts before escalation. You review at the end.
The 9 Thread Patterns
Every thread pattern defines how work is structured: checkpoints, parallelism, phases, verification. The right pattern prevents scope creep before it starts. Ghost Protocol inherits all patterns from Thread-Based Engineering, extended with agent-awareness.
Execution Threads
| Pattern | When to Use | Human Checkpoints | Typical Lead |
|---|---|---|---|
| Base | Single, scoped task (bug fix, small feature) | Start + End | EECOM |
| Parallel (P-Thread) | 3-5 independent sub-tasks, no shared files | Start + End | Multiple agents |
| Chain (C-Thread) | Multi-phase, early decisions affect later phases | Between every phase | EECOM + FIDO |
| Long (L-Thread) | Extended autonomous work with task tracking | Optional self-checkpoints | EECOM |
| Big (B-Thread) | Hierarchical sub-agent coordination | Start + End | Flight coordinates |
| Fusion (F-Thread) | Uncertain approach, compare 2-3 strategies | Start + Selection + End | Flight evaluates |
| Zero (Z-Thread) | Well-tested, low-risk, fully autonomous | End only | EECOM + FIDO verifies |
Quality Threads
| Pattern | When to Use | Lead |
|---|---|---|
| Review | Post-execution evaluation using Core Four | FIDO + RETRO |
| Status | Metrics dashboard and optimization suggestions | Coordinator |
How Threads Work with Agents
Thread patterns interact with agent charters. In a Chain Thread, different agents own different phases with explicit handoffs. In a Big Thread, Flight coordinates a hierarchy of specialists. In a Fusion Thread, Flight designs competing strategies and assigns them to different agents.
A Chain Thread for building a payment system:
C-THREAD: Payment System | Phases: 4
Phase 1: Database schema -> Agent: EECOM -> Checkpoint
Phase 2: Stripe integration -> Agent: CAPCOM -> Checkpoint
Phase 3: Frontend checkout -> Agent: EECOM -> Checkpoint
Phase 4: Tests + security -> Agent: FIDO + RETRO -> Final Review
Each phase handoff is explicit. EECOM writes a summary for CAPCOM before Phase 2 starts. No implicit context transfer.
The Core Four Quality Framework
Every completed thread is evaluated against four dimensions. No hand-waving. Scored 1-5 with evidence.
THE CORE FOUR
Every thread is evaluated against four quality dimensions
Does the work show understanding of the codebase?
Right capability level applied?
Work aligns with original request?
Appropriate tools and tests used?
GREEN
Merge
YELLOW
Minor fixes
RED
Redo
| Dimension | What It Measures | Key Questions |
|---|---|---|
| Context | Codebase understanding | Were existing patterns followed? Did agents stay within charter? |
| Model | Right capability applied | Over-engineered? Under-engineered? Right agent assigned? |
| Prompt | Alignment with request | Scope drift? Ambiguities resolved? Handoffs clean? |
| Tools | Appropriate tools used | Tests written? Linting checked? Right thread pattern? |
Each dimension scores 1-5. The overall thread receives a rating:
- GREEN: Clean, correct, ready to merge
- YELLOW: Minor issues, fixable without redoing the thread
- RED: Significant problems, triggers a Retrospective ceremony
A RED rating is not punishment. It is a signal to stop, analyze what went wrong, and route the fix through the correct agent and thread pattern.
Ceremonies: Automated Team Rituals
Ghost Protocol defines two ceremonies that trigger automatically.
Design Review
Triggers before any multi-agent task where 2+ agents will modify shared systems. Flight facilitates. All involved agents agree on interfaces, contracts, file ownership boundaries, and risk areas before any code is written. This prevents the most common multi-agent failure: two agents writing conflicting code.
Retrospective
Triggers after build failure, test failure, or RED review rating. Flight facilitates root cause analysis. What happened? Root cause? Right thread pattern used? Right agent assigned? What changes? Findings go to decisions.md so all agents learn from failures.
Why Ghost Protocol Exists
Thread-Based Engineering solved execution discipline: 9 thread types with human checkpoints that prevent scope creep, lost context, and unreviewed code. But it was silent on who should do the work. Every task went to the same generalist agent.
Squad by Brady Gaster solved agent specialization: named agents with charters, persistent memory, and defined boundaries. But it was silent on how work should be structured. Agents had roles but no execution discipline.
Ghost Protocol is the synthesis.
| Capability | Squad | Thread Engineering | Ghost Protocol |
|---|---|---|---|
| Named specialist agents | Yes | No | Yes |
| Structured execution patterns | No | 9 patterns | 9 patterns |
| Persistent agent memory | Yes | Stateless | Yes |
| Human checkpoints | Ad hoc | Per-pattern | Per-pattern |
| Quality framework | Reviewer gates | Core Four | Core Four + agent review |
| Dual routing (who + how) | Who only | How only | Who + How |
| Ceremonies (retros, reviews) | Yes | No | Yes, auto-triggered |
| GitHub Copilot native | Yes | No | Yes |
When to Use Ghost Protocol
Ghost Protocol is not always the right choice.
Use Ghost Protocol when:
- Your project has multiple concern areas (frontend, backend, security, integrations, docs)
- You want Copilot to specialize instead of being a generalist
- You need persistent memory across Copilot sessions (decisions, learnings, patterns)
- Quality gates and structured review matter to your workflow
- Multiple people work on the same codebase with Copilot
Use plain Thread-Based Engineering when:
- You are working solo on a focused project
- The project has one primary concern area
- You want execution discipline without agent specialization
- You use Claude Code, Cursor, or another agent with its own instruction format
Use neither when:
- The task is a quick one-off fix
- You are prototyping and speed matters more than structure
Open Source
Ghost Protocol is MIT licensed and open source.
- Landing page: ghost-protocol-ecru.vercel.app
- Source code: github.com/lloydpilapil/ghost-protocol
The repository includes the full framework (agents, patterns, routing, ceremonies), an installer script, and .github/copilot-instructions.md for GitHub Copilot.
Thread execution patterns are adapted from Thread Engineering Kit by Pixelmojo. The multi-agent coordination model is inspired by Squad by Brady Gaster.
Ghost Protocol for GitHub Copilot: Questions Developers Ask
Common questions about this topic, answered.
What Comes Next
Ghost Protocol v1.0.0 ships today with the full framework: 8 agents, 9 thread patterns, dual routing, Core Four, ceremonies, and persistent memory. The roadmap includes SDK-first mode (programmatic team definition via TypeScript config), session replay from execution logs, and agent performance analytics.
Silent agents. Clean code. No trace left behind.
- Get started on the Ghost Protocol landing page
- View source on GitHub
- Read about Thread-Based Engineering, the execution framework Ghost Protocol builds on
- Contact us if you want help implementing structured AI development in your team
