Grid Protocol
OPEN STANDARD · GIT-NATIVE · ANY CLIENT

Your AI is not a tool.
It's your architectural partner.

Grid gives AI models not just persistent, procedural memory — it builds a living knowledge layer that lives in your repository and stays in sync with your code. Conventions, decisions, and architectural knowledge that deepen every session. The model shows up knowing your project. Every time.

# Day 1 — fresh project
Initialize the Grid from G667 at GitHub
✓ Session state initialised
✓ Ready. Grid is active. Skill files travel with the project.

# Day 13 — same project, new session
Continue where we left off
Loaded: architecture, rest-layer, business-layer
3 pending issues · last decision: JWT session design
✓ No re-explaining. No re-discovering. Just work.

The capability is there.
The continuity isn't.

The model is capable of being a genuine architectural partner — reasoning, proposing, pushing back. But every session starts from zero. You re-explain architecture. You re-state conventions. You re-discover what was already decided.

🧠 Context evaporates

Compaction, new sessions, different clients — your project context disappears. The model has no memory of what it helped you build.

🔁 Constant re-explaining

Conventions, architectural decisions, domain vocabulary — you re-teach these every time. Time you could spend building.

📉 Degrades with scale

The larger the project, the more context it needs. Most AI tools get worse as your codebase grows. The model can't keep up.

🔒 Vendor lock-in

Memory features tied to Cursor, Claude Projects, or ChatGPT don't travel across tools. Switch clients and you start over.

The longer you build,
the more it gives back.

Grid is infrastructure, not a shortcut. It earns its keep on projects where consistency matters, decisions accumulate, and the work spans more than a few sessions.

✓ Long-running projects

Anything spanning weeks or months of AI-assisted development. The investment in skills compounds — each session starts sharper than the last.

✓ Architecturally serious work

Multiple layers, cross-cutting concerns, security requirements, non-obvious dependencies. The more there is to know, the more the skill system earns its keep.

✓ Small teams, high AI involvement

Where the model is a genuine co-developer, not an autocomplete tool. Grid assumes the model is a first-class participant — not a prompt recipient.

✓ Developers who maintain discipline

Skills that lag behind code are worse than no skills — they mislead. The Grid asks for one thing: keep skills current with the work. If that's your practice, the Grid compounds it.

A living knowledge layer
that lives in your repo

Grid is built on skill files — SKILL.md documents that tell the model what to do, when, and why. They live in your repository, versioned with your code, and persist across every session. Skills load on demand — keeping the context window slim instead of flooding it upfront. When compaction strikes and throws context overboard, Grid re-establishes everything required for the current task. No bloated context. No lost state. The model stays sharp across the full session — however long it runs. And because skills live in the repository, they compound. Each session adds to what the model knows about this project — not generic knowledge, but the specific decisions, conventions, and architecture that make it yours.

1

Skills — not prompts, not docs

SKILL.md files define what the model should do and when — not just facts to retrieve. They live close to the code they describe. A REST layer skill lives next to the REST code. A commit convention skill loads before every commit.

2

Load on demand — never flood the context

Context is precious. Grid's trigger system routes skill loading to the right phase — architecture skill when entering a module, commit skill before committing, issue management when the user mentions tasks. Never flooding the window with irrelevant knowledge. When compaction strikes, Grid re-establishes everything required for the current task.

3

Isos — your project's own knowledge

Isos are where the Grid's value accumulates. Decisions made, conventions established, domain knowledge discovered — co-authored with the model as the work unfolds. They live close to the code they describe, never come from a registry, and grow in depth and precision with every session.

The programs

Several programs establish the running system. Each owns one concern — session rhythm, skill discovery, state management, workflow enforcement. Together they form the infrastructure your project's isos build on top of.

Session Conductor

Runs the session rhythm — workflow steps, trigger timing, compaction recovery. Present at every decision point, visible only when something needs attention.

Session State Manager

The central memory. Owns skill cache, triggers, tasks, and workflow state. Every program delegates persistence here — nothing survives a session without it.

Skill Scanner

Walks the repository and registers every SKILL.md it finds. Builds the dependency mesh from frontmatter declarations. Detects naming conflicts before they cause behavioral drift. Keeps the knowledge map current without manual upkeep.

Workflow Guardian

Enforces approval gates at every decision point. No commit, close, or install without passing through. The last line of defence for collaboration integrity.

Task Coordinator

Manages the session task list and tracks open work across sessions. Coordinates the full lifecycle of issues from discovery to close.

External Connector

Bridges the Grid to external tools — git, GitHub, and beyond. Routes each action to the right driver skill, keeping integrations modular and independently replaceable.

Program Manager

Installs, updates, and removes programs from the Grid registry. Add new capabilities to the collaboration layer without touching the core.

Issue Tracker side project

Local, model-friendly, browser-viewable issue management with no external service required. Born in the first real Grid project — offered freely to anyone who finds it useful.

Project Skills yours

The primary value surface of the Grid. Isos are the accumulated architectural memory of your project — co-authored with the model as decisions are made, patterns emerge, and the codebase grows. They live in the repository, evolve with the work, and deepen every session.

Skills know about each other

Each iso declares its relationships in frontmatter. The skill scanner builds a live graph across your entire codebase. Load one area — the mesh tells you what to surface next. Touch a module — the mesh tells you what else to verify. Architectural impact is visible before you write a line.

How Grid works in depth

Not retrieval. Not prompts.
Collaborative infrastructure.

Most AI memory systems retrieve facts. Grid loads behavior — what to do, when, and why. It's not a smarter tool. It's a different kind of collaboration entirely.

Approach Git-native Client-agnostic Procedural Team-owned No infra
Grid
IDE-specific rule files
Vendor memory / project context ~
RAG / embedding stores ~ ~ ~
External memory services ~
1
instruction to initialize — no cloning, no scripts
0
external services required
4
AI clients supported: Copilot CLI, Claude Code, Cursor, Windsurf

Before it had a name.

The prototype wasn't called Grid yet. During 13 days of building a software project, an organic skill and issue system emerged — not by design, but out of necessity. The foundation of a full software stack was complete by the end. The speed was unexpected. On day 14, looking back at what had made it possible, the idea for Grid was born.

13 days · solo Full platform: API, business layer, persistence, REST, auth, security hardening, infra
161 issues Created and tracked across the entire project — architecture, features, bugs, security decisions.
108 closed Documented, confirmed, and merged. Every decision recorded alongside the code that implements it.
One click ships Installer, Docker image, SBOM, log management, and coverage reports — production artifacts on every build.
0 re-explains Every convention, decision, and domain rule persisted across every session via skill files.
Day 13 > Day 1 Each session started sharper than the last. Context compounds instead of evaporating.
0 CVE & OSS findings Automated vulnerability and dependency scanning at build time. Clean across the full stack on this project.
Security by design Every security decision was reasoned into the architecture from the start — not retrofitted.

Every security decision — JWT design, session handling, CSRF protection, input validation, permission modelling, TLS hardening — was discussed exhaustively with the model across multiple issues and sessions. Not security added after the fact. Security reasoned into the architecture from the start. The result was a codebase where security properties were deliberate and traceable — not a compliance certificate, but a meaningful step toward building software that takes security seriously from day one.

Not a reset —
an evolution.

The same project that inspired Grid became its first migration target. A prototype skill system had been running for weeks — the direct predecessor to what Grid would become. When Grid was ready, the question was whether it could adopt a mature, mid-flight codebase without disruption. One session answered it.

1 session Full migration: init, knowledge transport, issue migration, cleanup, verification
3 commits Init + skills · Issue migration · Cleanup. Complete and verified by commit 3.
161 issues Migrated to gjuice with all timestamps, descriptions, and history preserved. Exact match.
14 → 26 skills Existing knowledge reorganized into the Grid's locality model. All auto-discovered by Recognizer.
4 clients Copilot CLI, Claude Code, Cursor, Windsurf — all bootstrapped in one pass.
1 rescued A design doc with no frontmatter — invisible to scan-skills — found during cleanup and preserved as a richer iso than anything that existed before.

The model recognized the migration context without being told. During the project survey it independently identified the overlap between the prototype skill system and the Grid, and proposed migration rather than duplication. It distributed git conventions correctly across Tron, Dumont, and user.md — not into a redundant iso. It found a permission-model design discussion buried in a non-SKILL.md file and promoted it to a dedicated iso rather than deleting it. The Grid scales to a project mid-flight. No reset required.

Read the full case study

Grid is one answer.
The question is bigger.

Grid was not designed top-down.
It was discovered — by one developer hitting the same structural limits,
session after session, until solving it properly felt necessary.
The tool is concrete. What it points at is not.

Read the thinking behind Grid

One instruction.
Your project. Remembered.

Open your project in any AI client. Say:
"Initialize the Grid from G667 at GitHub"

The model fetches and installs — no cloning, no scripts, no manual steps.

Requires Python 3 · standard library only · no packages

Early alpha · born in one real project, proven in its migration · see the case study

Using Claude or a strict client?

Some AI clients (Claude in particular) restrict models from fetching and writing files from external sources. If the initialization is blocked, you can install Grid manually:

  1. Download the Grid repository as a ZIP from GitHub
  2. Copy the .grid/ directory into your project root
  3. Copy the bootstrap directories for your desired clients into your project root:
    • GitHub Copilot CLI.github/skills/grid-bootstrap/
    • Claude.claude/commands/grid-bootstrap/
    • Cursor.cursor/rules/grid-bootstrap/
    • Windsurf.windsurf/rules/grid-bootstrap/
  4. Start a new session — the Grid bootstraps automatically via the directories you copied in step 3, exactly as it would through the automated path.

The model reads the local files directly — no external fetching required.