DOCSEARCHbyAlgolia
Submit Docs

PRD-Driven Context Engineering

repository·main·Indexed 42 days ago

https://github.com/mattgierhart/prd-driven-context-engineering

A methodology and repository structure for providing AI agents with persistent, high-density memory via a markdown-based Knowledge Graph. It features a PRD Skills Library with specialized capabilities mapped to the product lifecycle (v0.1 to v1.0), an EPIC-based execution workflow, and a Source of Truth (SoT) HTML Companion Library for human-readable views of the knowledge graph.

Tokens
357.5K
Snippets
493
Records
1.1K
Agent score
51%

What's inside PRD-Driven Context Engineering

  1. What is PRD-Led Context Engineering?

    main

    PRD-Led Context Engineering is a methodology designed to solve the 'Amnesiac Memory' problem in AI-assisted development. Instead of treating documentation as an afterthought, it treats documentation as the infrastructure of shared memory.

    By using a structured Knowledge Graph of unique IDs (e.g., BR-004, API-045) stored in plain markdown files, both humans and AI agents can navigate a single, version-controlled Source-of-Truth. This ensures that AI models have high Context Density—receiving rich, structured, and specific information rather than noisy, irrelevant documentation dumps.

  2. Overview of the SoT HTML Companion Library

    main

    The SoT HTML Companion Library provides human-review views of the SoT/*.md knowledge graph. While the markdown files serve as the authoritative Source of Truth, the HTML pages re-express those entries in specialized formats optimized for reviewers (e.g., journey maps for journeys, API references for endpoints).

    Key Characteristics:

    • Zero Build Step: Open index.html in any browser; it works via file:// and requires no JavaScript.
    • Parallel Naming: Every SoT markdown file has a corresponding HTML file (e.g., SoT.BUSINESS_RULES.md ↔ SoT.BUSINESS_RULES.html).
    • Stable Deep Linking: Every entry's HTML anchor matches its unique ID, allowing stable links like SoT.BUSINESS_RULES.html#BR-001 to mirror markdown citations (SoT.BUSINESS_RULES.md#br-001-rule-name).
    • Visual Cues: Uses span.ph (italic dashed-underline) to mark template placeholders that require filling during review.

  3. Understand the Portfolio Repo Structure and Roles

    main

    A portfolio-level repository sits above multiple product repositories to coordinate strategy, intelligence, and standards without containing product code. It serves three primary goals:

    1. See into the future: Harvesting strategic intelligence (signals) from individual product repos to identify new product opportunities.
    2. Design connected products: Managing a pipeline where new products are incubated in the portfolio before graduating to their own repositories.
    3. Maintain documentation consistency: Ensuring all products follow a standard structure so humans and AI agents can navigate the ecosystem seamlessly.

    Role Responsibilities

    RoleKey Interaction
    LeadershipOwns PORTFOLIO.md, reviews signal registry, and makes go/no-go decisions on candidates.
    Scrum MastersUpdates product manifests, maintains Jira cross-references, and flags stale documentation.
    DesignersConsumes P:DES- standards and ensures cross-product UX consistency.
    Backend EngineersImplements P:API- contracts and honors P:BR- cross-product rules.
    Data ScientistsContributes to the intelligence layer via signal registry and demand pattern analysis.
    AI AgentsUses CLAUDE.md rules and portfolio context during product incubation.

  4. Use the SoT HTML Companion Library

    main

    The SoT HTML Companion Library provides human-readable views of the SoT/*.md knowledge graph. While the markdown files are the authoritative Source of Truth, these HTML pages re-express entries into specialized formats (e.g., journey maps, API references, adoption curves) for reviewers.

    To use the library, simply open index.html in any web browser. It works via file:// protocols and requires no build step or JavaScript.

  5. Understand the PRD Skills Library purpose and structure

    main

    The PRD Skills Library provides specialized agent capabilities for each stage of the Product Requirements Document (PRD) lifecycle, from initial spark (v0.1) to market adoption (v1.0). Skills are designed to be loaded on-demand to give AI agents specialized expertise for specific tasks, following the Agent Skills Specification.

    Skill Lifecycle Mapping

    Skills are organized by PRD development stages:

    • v0.1 Spark: Problem Framing, User Value Articulation
    • v0.2 Market: Competitive Landscape, Product Type Classification
    • v0.3 Commercial: Outcome Definition, Pricing Model, Moat Definition, Feature Value Planning
    • v0.4 Journeys: Persona Definition, User Journey Mapping, Screen Flow Definition
    • v0.5 Red Team: Risk Discovery Interview, Technical Stack Selection
    • v0.6 Architecture: Architecture Design, Technical Specification
    • v0.7 Build: Epic Scoping, Test Planning, Implementation Loop
    • v0.8 Release: Release Planning, Runbook Creation, Monitoring Setup, Changelog-as-Marketing, Drift Baseline/Compare, Marketing-Ops Handoff
    • v0.9 Launch: GTM Strategy, Positioning (Dunford), Offer Construction (Hormozi), Launch Channels (ORB), AEO Audit, Alternatives Pages, Cold Outreach, HN/Reddit Launch, Launch Metrics, Feedback Loop Setup
    • v1.0 Adoption: Crossing the Chasm (Moore), Continuous Discovery (Torres), Mom Test Interview (Fitzpatrick), Case Study Builder, Testimonial Collector
    • Methodology: Gate Check, ID Register, Status Sync, Harvest, SoT Builder

  6. Overview of the Readiness Protocol scoring layers

    main

    The Readiness Protocol uses three composable scoring layers to determine if work in a PRD-CE repository is ready to advance. These layers run in dependency order (SoT → EPIC → stage) via the scripts/readiness.py orchestrator, which outputs both a text report and a status/readiness.json file.

    LayerAnswersReadsWrites to status/readiness.json
    SoT file (primitive)"Is SoT.X.md in good shape?"SoT files, domain profilesot_files.{path}
    EPIC (middle)"Can we build this EPIC?"SoT file scores, EPIC frontmatter + Section 3epics.{EPIC-ID}
    PRD stage (composer)"Can we advance v0.X → v0.Y?"SoT file + EPIC scores, gate requirementsstages.{v0.X}

  7. Apply the Targeting Decision Framework

    main

    Use the results of your moat analysis to decide your market entry strategy:

    1. Moat is Impenetrable/Strong $\rightarrow$ DON'T COMPETE (unless targeting an ignored segment like SMB or a specific vertical).
    2. Moat is Moderate $\rightarrow$ WEDGE STRATEGY: Identify an entry point that bypasses switching friction.
    3. Moat is Weak/Eroding $\rightarrow$ DIRECT COMPETITION: Execute a feature or price attack on their core offering.

    Wedge Opportunity Signals

    A wedge opportunity exists if:

    • The competitor's moat does not apply to a specific segment.
    • One specific feature has LOW switching costs.
    • The integration allows for coexistence rather than full replacement.
    • Price sensitivity is higher than the switching friction.

  8. Configure launch channel selection criteria

    main

    When picking channels for a launch, evaluate each candidate against these five scoring metrics. Any channel scoring below a Fit of 3/5 should be dropped.

    1. Fit: Does the best-fit segment (defined in Positioning) actually use this channel?
    2. Reach: How many of the target segment does this channel touch (estimated)?
    3. Effort: What is the time cost per launch wave (in hours)?
    4. Cost: What is the direct monetary cost ($)?
    5. Attribution: Can we measure conversion from this channel (e.g., via UTMs)?

  9. Apply The Mom Test framework to customer interviews

    main

    The Mom Test framework ensures you get truthful data by avoiding hypothetical questions that allow people to lie to spare your feelings.

    The Three Rules

    1. Talk about their life, not your idea. Focus on how they actually live and work.
    2. Ask about specifics in the past, not generics or opinions about the future. Use "Last time you faced X, what did you do?" instead of "Would you use Y?".
    3. Talk less and listen more. Aim to talk less than 30% of the time.

    Avoiding Bad Data

    Bad Data typeExampleWhy it's badWhat to do
    Compliments"That sounds awesome!"Politeness; not predictiveDiscard; don't update confidence
    Fluff"I usually..." "I would probably..."Generics, future hypotheticalsAnchor to specifics: "When did you last do that?"
    Ideas"You should add X"Solution suggestions disguised as needsNote as IDEA; ask "what would solving X enable you to do?"

    Confidence Calibration

    Use these floors for CFD-* entries based on observed past behavior:

    • 2/5: Generic statement ("I sometimes have this problem")
    • 3/5: Specific past instance ("Last Tuesday, I spent 2 hours doing X")
    • 4/5: Specific past instance + evidence of investment (e.g., paid for a workaround, built a script, hired a person)
    • 5/5: Repeated specific past instances + ongoing willingness to invest (commit > talk)

  10. Avoid anti-patterns during the Harvest process

    main

    To maintain a high-quality Source of Truth and prevent data loss, avoid these common mistakes:

    Anti-PatternExampleFix
    Orphan tempsTemps not in manifestProcess all files
    Lost contextArchive without manifestAlways create manifest
    Over-extractionEverything becomes SoTApply decision matrix
    Under-extractionValuable insights lostReview before discard

    Boundaries for the Harvest Skill:

    • DO: Extract durable insights, format per templates, create complete manifests, and clean up temps.
    • DON'T: Create new analysis, modify existing conclusions, skip the manifest, or delete files without review.

  11. Understand the 5 phases of an EPIC lifecycle

    main

    Every EPIC follows a structured 5-phase lifecycle to ensure context is managed and the Source of Truth (SoT) is updated correctly:

    1. Phase A: Plan: Load context by reading the EPIC, loading referenced IDs, and verifying the current Session State.
    2. Phase B: Design: Update the SoT by drafting or refining ID entries in the SoT/ directory before any code is written.
    3. Phase C: Build: Implementation phase. Work is divided into Context Windows (smaller focus areas) to prevent token overload, following a test-first approach.
    4. Phase D: Validate: Verification phase. Run tests, perform manual checks, and conduct a traceability audit to ensure code matches the SoT.
    5. Phase E: Finish: Cleanup phase. Finalize the SoT, archive temporary files, capture learnings, and set Resume Instructions to N/A - EPIC Complete.

  12. Understand downstream connections for the Release Planning skill

    main

    The prd-v08-release-planning skill (DEP-003) acts as a central coordination point that feeds several downstream processes. The outputs generated during release planning are used by:

    • Runbook Creation: Rollback procedures defined in the release plan become inputs for runbooks (e.g., DEP-003 → RUN-005).
    • Monitoring Setup: Thresholds defined in the release plan inform alerting configurations (e.g., a 2% error threshold in DEP-003 informs MON-001).
    • v0.9 GTM Strategy: Meeting all release readiness gates triggers the Go-To-Market strategy (e.g., All DEP- met → GTM-001).
    • EPIC- Future Releases: The current release plan serves as a template for planning subsequent releases (e.g., DEP-001 reused).