Meta Prompt Architecture Design

# Meta-Prompt Architecture Design

**Date:** 2026-03-14
**Status:** Draft
**Scope:** Replace hard-coded prompt pipeline with meta-prompt + knowledge base architecture supporting three methodology tiers

---

## 1. Problem Statement

Scaffold v1 uses 29+ hard-coded prompts in a monolithic `prompts.md` file. The v2 design introduced a three-layer prompt resolution system (base/override/extension) with mixin injection and methodology manifests — adding architectural complexity without solving the core maintenance burden.

Two insights drive this redesign:

1. **AI can generate prompts at runtime.** Instead of maintaining detailed hard-coded prompts, we can describe the *intent* of each step and let the AI generate the appropriate working prompt based on project context and methodology depth.

2. **Users need methodology tiers.** Not every project needs the same level of documentation rigor. A solo hackathon project and a complex enterprise system should go through fundamentally different levels of preparation.

## 2. Architecture Overview

### Three Core Components

**Meta-Prompts** — One per pipeline step (32 files). Each is a compact declaration (30-80 lines) of what the step should accomplish: purpose, inputs, outputs, quality criteria, and methodology-scaling rules. They do NOT contain the actual prompt text the AI executes.

**Knowledge Base** — Domain expertise organized by topic (32 files). Contains what makes a good PRD, how to review an architecture document, what failure modes to check in API contracts, etc. Reusable across steps — multiple meta-prompts can reference the same knowledge entry.

**Methodology Configuration** — Controls which pipeline steps are active and the depth level (1-5) for each. Three presets: Deep Domain Modeling (all steps, depth 5), MVP (minimal steps, depth 1), Custom (user picks steps and depth per step).

### How They Interact at Runtime