feat: design prd-review into 5 dispatchable agents with JSON verdict

.github/dependabot.yml

@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly

.github/workflows/publish-cue.yml

@@ -0,0 +1,28 @@
+name: "Publish to CUE Registry"
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      id-token: write
+    steps:
+      - name: Checkout
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
+        with:
+          fetch-depth: 0
+          persist-credentials: false
+      - name: Setup CUE
+        uses: cue-lang/setup-cue@a93fa358375740cd8b0078f76355512b9208acb1 # v1.0.1
+        with:
+          version: "v0.17.0"
+      - name: Login to CUE Central Registry
+        uses: cue-labs/registry-login-action@66d40052b0206031343e17173425fa10508968d0 # v1.0.3
+      - name: Publish module
+        env:
+          REF_NAME: ${{ github.ref_name }}
+        run: cue mod publish "$REF_NAME"

.gitignore

@@ -0,0 +1,15 @@
+.idea/
+.DS_Store
+Thumbs.db
+*.swp
+*.swo
+*~
+.task/
+node_modules/
+.lola/
+*.log
+.claude/
+.superpowers/
+
+# Working artifacts (never committed)
+docs/superpowers/

AGENTS.md

@@ -0,0 +1,62 @@
+# Intake Kit — Developer Guide
+
+This repo is the source for the `intake-kit` Lola module.
+The installable module lives entirely under `./module/`.
+
+## Project layout
+
+```
+module/                            ← installable module (what users get)
+  AGENTS.md                        ← injected into user's AGENTS.md by lola
+  agents/                          ← standalone review agent definitions
+  skills/prd-review/
+    SKILL.md                       ← orchestration skill
+    references/                    ← reviewer protocol and shared refs
+  commands/prd-review.md           ← command entry point
+schema/                            ← CUE schema (published to CUE registry)
+cue.mod/                           ← CUE module definition
+examples/                          ← example PRD YAML files
+.github/workflows/                 ← CI (CUE registry publish)
+```
+
+## Golden rule
+
+**All changes to module content go in `./module/`, never in the installed location.**
+
+The installed copy (typically `~/.config/opencode/skills/prd-review/`
+or `.claude/skills/prd-review/`) is a deployment artifact. If you find
+yourself editing files outside `./module/`, stop — you're modifying a
+copy that will be overwritten on next install.
+
+## Working on review agents
+
+Agent definitions live at `module/agents/prd-*.md`. Each is a standalone
+reviewer that runs in parallel during Phase 2 of the review council.
+Follow the existing agent files as a template when adding new ones.
+
+## Working on the schema
+
+The CUE schema at `schema/prd.cue` is published to the CUE Central
+Registry via the `publish-cue.yml` workflow on tag push. The module
+definition at `cue.mod/module.cue` controls the module path and
+language version.
+
+## Tool Agnosticism
+
+This module MUST remain target-tool agnostic. It must work identically
+whether the hosting tool is Claude Code, OpenCode, Cursor, Windsurf,
+Gemini CLI, or any future AI coding assistant.
+
+Rules:
+
+1. **No tool-specific frontmatter.** Skill and agent files use only
+   keys every host understands.
+2. **No tool-specific dispatch syntax.** Orchestrator docs describe
+   dispatch intent with fallback instructions for hosts that lack
+   named-agent dispatch.
+3. **No tool names in operational text.** References to specific tools
+   are permitted only in docs — never in instructions or agent
+   definitions that affect runtime behavior.
+4. **Graceful degradation over hard requirements.** Features that
+   depend on host capabilities must degrade gracefully when the host
+   lacks them, not fail.

README.md

@@ -1,2 +1,93 @@
-# intake-kit
-A CUE-validated PRD authoring and review system for structured project intake
+# Intake Kit
+
+A structured product requirements intake toolkit. CUE-validated PRD authoring paired with a multi-agent AI review
+council that gates PRD advancement from Draft to Review.
+
+Installs as a [Lola](https://github.com/LobsterTrap/lola) module and works with Claude Code, Cursor, Gemini CLI, and
+OpenCode.
+
+## What's in the box
+
+- **CUE schema** (`schema/prd.cue`) — validates PRD YAML documents. Enforces structure for stakeholders, functional
+  requirements, acceptance criteria, workflows, and lifecycle state.
+- **prd-review skill** (`module/skills/prd-review/`) — a Lola skill that checks CUE schema conformance, then dispatches
+  5 specialist review agents (`module/agents/prd-*.md`) against a PRD family and emits a BLOCKED / NEEDS REVISION /
+  APPROVED verdict.
+- **Example PRDs** (`examples/`) — parent and phase templates ready to copy and fill in.
+
+## Install
+
+```bash
+lola install github.com/unbound-force/intake-kit
+```
+
+## PRD Document Model
+
+PRDs are structured YAML. A **parent PRD** defines the initiative (title, description, personas, NFRs, scope). **Phase
+PRDs** reference the parent and carry delivery-specific fields (FRs with ACs, workflows, state).
+
+```
+parent-prd.yaml          # what + why
+├── phase1-prd.yaml      # phase 1 FRs, workflow, state
+└── phase2-prd.yaml      # phase 2 FRs, workflow, state
+```
+
+See `examples/` for the full field set.
+
+## Validating PRDs
+
+Requires [CUE](https://cuelang.org/docs/introduction/installation/).
+
+```bash
+cue vet schema/prd.cue your-prd.yaml
+```
+
+## Running the Review Council
+
+The `prd-review` skill runs in any AI coding assistant that supports Lola skills.
+
+```
+/prd-review prds/my-feature.yaml prds/my-feature-phase1.yaml
+```
+
+**Phase 0 is schema conformance.** Before any content review, the PRD family is checked against the CUE schema
+(`#PRDDocument`), resolved from the CUE Central Registry first, falling back to a local file if you pass
+`--schema <path>`. A structural violation (bad ID format, invalid enum, disallowed field) blocks immediately with the
+raw `cue vet` error — no point reviewing behavior in a file that doesn't even parse against the schema.
+
+**Phase 2 — 5 has specialist agents** then review content and quality, by default in parallel (pass `--serial` to run them
+sequentially in one context instead — slower, but roughly 1/5th the token cost, since the PRD text is read once
+instead of once per agent):
+
+| Agent | Reviews |
+|---|---|
+| Guard | Intent fidelity, scope discipline, persona/ID/workflow integrity, FR-to-value traceability |
+| Adversary | Security gaps (auth boundaries, trust, credential scope) + ambiguity/completeness |
+| Tester | Behavioral language, testability, AC quality |
+| Operator | Implicit deployment/environment/connectivity assumptions |
+| Curator | Evidence capture, audit trail, retention, provenance, open-question hygiene |
+
+Each agent returns a JSON verdict; a Verify phase confirms every finding's evidence is a literal quote from the PRD
+before it's allowed into the report. The council then produces a consolidated finding report with severity levels
+(BLOCKER, WARNING, INFO) and a verdict that gates PRD state advancement from Draft to Review.
+
+See `module/agents/prd-*.md` for each agent's full review criteria, and `module/skills/prd-review/SKILL.md` for the
+full phase-by-phase process.
+
+## Project Layout
+
+```
+module/                  ← installable Lola module
+  agents/                ← standalone review agent definitions (prd-guard, prd-adversary, ...)
+  skills/prd-review/     ← orchestration skill (schema check + agent dispatch + verdict)
+  commands/              ← command entry points
+schema/                  ← CUE schema (published to registry)
+cue.mod/                 ← CUE module definition
+examples/                ← example PRD YAML files
+```
+
+See [AGENTS.md](AGENTS.md) for the full developer guide.
+
+## License
+
+Apache-2.0 — see [LICENSE](LICENSE).

cue.mod/module.cue

@@ -0,0 +1,7 @@
+module: "github.com/unbound-force/intake-kit@v0"
+language: {
+	version: "v0.17.0"
+}
+source: {
+	kind: "git"
+}

examples/parent-prd.yaml

@@ -0,0 +1,44 @@
+header:
+  schema-version: "0.1.0"
+  version: "0.1.0"
+  last-updated: "2026-01-01"
+
+slug: my-feature
+title: "My Feature"
+features:
+  - "org/repo#99"
+description: >-
+  One paragraph describing what this initiative is and why it exists.
+
+stakeholders:
+  - role: "Product Owner"
+    handle: "@handle"
+  - role: "Requestor"
+    handle: "@handle"
+    approver: true
+  - role: "Stakeholder Representative"
+    handle: "@handle"
+
+personas:
+  - "Example Persona"
+
+scope:
+  in_scope:
+    - "Thing we are building"
+  out_of_scope:
+    - "Thing we are not building"
+
+nonfunctional_requirements:
+  - id: NFR-MF-001
+    title: "Example NFR"
+    description: >-
+      Describe the non-functional requirement here.
+
+kpis:
+  - metric: "Example metric this initiative moves"
+    target: "Qualitative direction is acceptable in Draft; add a number once validated with stakeholders."
+    baseline: "Current value or state, if known"
+
+open_questions:
+  - question: >-
+      An open question that needs resolution before or during delivery.

examples/phase-prd.yaml

@@ -0,0 +1,40 @@
+header:
+  schema-version: "0.1.0"
+  version: "0.1.0"
+  last-updated: "2026-01-01"
+  parent: my-feature
+
+slug: my-feature
+phase: "Phase 1 — Example Phase Name"
+
+stakeholders:
+  - role: "Technical Owner"
+    handle: "@handle"
+  - role: "Technical Owner Understudy"
+    handle: "@handle"
+
+state:
+  status: Draft
+
+dependencies:
+  - description: "What this phase depends on (another team, system, or decision)"
+    blocking: true
+    context: "Why it's blocking and what unblocks it"
+
+workflow:
+  label: "Example Workflow"
+  steps:
+    - label: "Step One"
+      description: "What happens in this step."
+      implements:
+        - FR-MF-001
+
+functional_requirements:
+  - id: FR-MF-001
+    title: "Example Functional Requirement"
+    persona: "Example Persona"
+    acceptance_criteria:
+      - id: AC-MF-001-01
+        description: "First acceptance criterion for FR-MF-001."
+      - id: AC-MF-001-02
+        description: "Second acceptance criterion for FR-MF-001."

module/AGENTS.md

@@ -0,0 +1,28 @@
+# Intake Kit
+
+Skills in this module support structured product requirements intake.
+
+## Skills
+
+- **prd-review** — Multi-agent review council for PRDs. Invoked via `/prd-review` before advancing a PRD from Draft to Review. Checks CUE schema conformance, then runs 5 specialist review agents (Guard, Adversary, Tester, Operator, Curator) — in parallel by default, or `--serial` for lower token cost — and emits a BLOCKED / NEEDS REVISION / APPROVED verdict.
+
+## Review Agents
+
+Agent definitions live at `module/agents/prd-*.md`. Each is a standalone
+dispatchable reviewer with its own phased process and JSON verdict — see
+`module/skills/prd-review/references/reviewer-protocol.md` for the shared
+schema.
+
+## PRD Structure
+
+PRDs are structured YAML validated against a CUE schema. The document model uses parent-child relationships:
+
+- **Parent PRDs** define the initiative: title, description, personas, NFRs, KPIs, stakeholders, scope.
+- **Phase PRDs** define delivery phases: FRs with ACs, workflows, dependencies, state tracking.
+
+## Key Constraints
+
+- PRDs do not name unmade implementation choices in Draft state — but naming an external compatibility constraint the business has already committed to (a required data model, wire format, or certification) is expected, not a defect.
+- Requirements describe behavior, not implementation.
+- Each agent owns its own scope — findings from different agents may overlap in location but are not deduplicated.
+- PRD content is only reviewed for behavior and quality after it passes CUE schema conformance (`schema/prd.cue`, `#PRDDocument`) — structural violations block before the 5 review agents run.