Skip to content

PRD driven context engineering

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…

Install

$git clone https://github.com/mattgierhart/PRD-driven-context-engineering

Install command taken from the project's README or registry entry. Always review code before running it.

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

  1. Just-in-Time Context — IDs let you load only what a task needs. No repo-dumps, no noise, fewer hallucinations.
  2. The Documentation Ecosystem — PRD ↔ EPICs ↔ SoT connected by links, skills, and hooks. When logic changes, both human and AI know.
  3. Context Validation — context is measured like code. Too sparse, the AI drifts; too dense, it chokes. The repo scores itself (see Readiness Scoring).
  4. 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:

Similar plugs

Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local…

Why use many token when few token do trick. Viral skill + proxy for coding agents that cuts 65% of tokens by talking like a caveman.

The 1st Collaborative AI Design Agent Workspace. Local-first and open source. Create prototypes, websites, apps, dashboards, presentations, images, and videos with your team…