PRD-driven-context-engineering
mattgierhart · mattgierhart/PRD-driven-context-engineering
Provides a methodology and skills to build products with AI agents that remember, by turning documentation into a navigable knowledge graph.
PRD-Led Context Engineering — Memory as Infrastructure. An ontology layer for product teams building products that solve real problems — with AI agents that remember. Gated PRD, typed IDs, markdown knowledge graph, Claude Code skills & hooks.
Preview
What you can do with it
- Ensure your AI agent retains project context across multiple sessions for consistent development.
- Collaborate with AI agents using a shared knowledge graph derived from product requirements documents.
- Develop complex features where agents need to reference previous design decisions and product history.
Safety check
No risky patterns found in the files we scanned.
Automated scan of the repo files. Always review code you run.
From the README
PRD-Led Context Engineering
Memory as Infrastructure — an operating system for building products with AI agents
Your AI partner is brilliant in one session and amnesiac by the next. This repository is the fix: a fork-ready methodology that turns documentation into a knowledge graph humans and AI navigate together — so the 50th session is smarter than the 1st.
Quick Start · The Idea · The Lifecycle · The Skills · Live Demo Views
⭐ If this changes how you build with AI, star the repo — stars put this method in front of the next team drowning in context drift.
The Problem: AI forgets. Teams drift.
Every era of software solved memory its own way — and broke it its own way:
- Waterfall had Static Memory. Write everything down upfront: certainty, at the cost of change.
- Agile moved fast and created Fragmented Memory. Knowledge scattered across tickets, wikis, and chats; shared understanding evaporated.
- AI-assisted building adds a third failure: Amnesiac Memory. The model that architected your system yesterday has never heard of it today.
The common mistake is treating these as tooling problems. They are memory problems.
PRD-Led Context Engineering builds Shared Memory: it treats AI as a team member, not a tool, and keeps documentation synchronized with code so humans and AI navigate the same truth.
The Idea: Memory as Infrastructure
This methodology comes from two converging experiences.
Leading human teams — alignment always followed the same pattern: rally around a single Source-of-Truth artifact and the team moves as one. Without it, even great talent drifts.
Partnering with AI — sometimes the model performs at a senior level, sometimes it hallucinates. The variable was never the model's intelligence. It was the Context Density provided: rich, structured context in; senior-level output out.
The convergence: documentation is not an afterthought. Documentation is the infrastructure of shared memory.
The Golden Rule: If it isn't part of the memory infrastructure, it isn't true.
So every durable decision gets a Unique ID (UJ-101, BR-004, API-045) in a Source-of-Truth file. That ID is a memory node with weight: when the AI references BR-004, it isn't guessing — it's retrieving a specific, validated decision you encoded. The linked network of IDs across files is the Knowledge Graph, and it lives in plain markdown, in your repo, under version control.
The 4 Pillars
- Just-in-Time Context — IDs let you load only what a task needs. No repo-dumps, no noise, fewer hallucinations.
- The Documentation Ecosystem — PRD ↔ EPICs ↔ SoT connected by links, skills, and hooks. When logic changes, both human and AI know.
- Context Validation — context is measured like code. Too sparse, the AI drifts; too dense, it chokes. The repo scores itself (see Readiness Scoring).
- Progressive Documentation — update in place, never copy. No
PRD_v2.md, ever. One document, many versions, single current reality.
The Cognitive Shift
This changes how work is measured, not just how it's tooled:
| Traditional Agile | PRD-Led Context Engineering | The Shift |
|---|---|---|
| Sprints | Context Windows | We don't time-box based on dates; we scope-box based on cognitive capacity. |
| User Stories | Prompts | We don't write descriptions; we engineer prompts that deterministically load context. |
| Tribal Knowledge | Source of Truth | If it isn't in the Knowledge Graph (SoT/), it doesn't exist. |
| Standups | Documentation Hooks | No status meetings. Event-driven hooks handle context loading, gate checks, and memory handoffs. |
| Project Management | Context Governance | We don't task-manage people. The system gates execution until context is verified valid. |
What's in the box
Everything below ships in this repo, works offline, and forks in one click:
| Feature | What it gives you |
|---|---|
| 🧠 The Knowledge Graph | 14 SoT files, 21 ID types, zero databases — durable memory in markdown |
| 📈 The Progressive PRD | A gated v0.1 → v1.0 lifecycle that stops AI from one-shotting your architecture |
| 🛠 47 Skills | Stage playbooks from problem framing to crossing the chasm — Dunford, Hormozi, Moore, Torres built in |
| 📊 Readiness Scoring | The repo computes whether you're ready to advance — and what to fix first |
| 🫀 The Development Graph | @implements tags bridge code to specs; drift surfaces as a verdict, not a surprise |
| 📰 The Human Review Layer | Every SoT file rendered as a styled, hyperlinked page its reviewer actually wants to read |
| 🤖 The Agent Squad | Four role agents with persistent memory, coordinated through files instead of meetings |
🧠 Feature: A Knowledge Graph in plain markdown
The pitch: long-term product