feat: design prd-review into 5 dispatchable agents with JSON verdict by jpower432 · Pull Request #1 · unbound-force/intake-kit

jpower432 · 2026-08-12T23:41:27Z

Summary

Design of prd-review from a single-context 6-lens inline checklist model into 5 standalone dispatchable review agents (Guard, Adversary, Tester, Operator, Curator) with a shared JSON verdict protocol. Adds Phase 0 schema conformance gate with registry-first/--schema fallback dispatch, parallel/serial execution modes, and schema extensions (KPIs at parent level, dependencies at phase level). Includes CUE module scaffolding, CI publish workflow, and example PRDs demonstrating parent and phase-level schema conformance.

Reviewer Hints

This has been tested with Claude Code (Claude Sonnet 5) with success
This was modeled after the review council - https://github.com/lolables/lola-mod-review-council

…protocol Design of prd-review from a single-context 6-lens inline checklist model into 5 standalone dispatchable review agents (Guard, Adversary, Tester, Operator, Curator) with a shared JSON verdict protocol. Adds Phase 0 schema conformance gate with registry-first/--schema fallback dispatch, parallel/serial execution modes, and schema extensions (KPIs at parent level, dependencies at phase level). Includes CUE module scaffolding, CI publish workflow, and example PRDs demonstrating parent and phase-level schema conformance. Assisted-by: Claude (Anthropic, Claude Sonnet 5) Signed-off-by: Jennifer Power <barnabei.jennifer@gmail.com>

Signed-off-by: Jennifer Power <barnabei.jennifer@gmail.com>

yvonnedevlinrh

Review Summary

Solid initial design for the PRD review council. The 5-agent architecture with domain-scoped ownership, the shared verdict protocol, and the graceful-degradation strategy for host capabilities are well thought through. The CUE schema is clean and the conditional parent/phase validation is a nice pattern. Good to see the CI updated to use CUE Trusted Publishing (OIDC) instead of a static token.

No blockers — the findings below are clarifications and minor consistency issues worth addressing before this becomes the foundation users build on.

Key findings

Schema & examples

The parent and phase examples both use slug: my-feature with no schema constraint preventing slug collision across documents. Since FR IDs derive from the slug (FR-MF-001), this creates an ambiguous namespace when multiple phases exist. Either enforce uniqueness or use distinct slugs in the examples.

Orchestration

Per-agent verdicts use APPROVE / REQUEST CHANGES (reviewer-protocol.md) but the council-level verdicts use APPROVED / NEEDS REVISION / BLOCKED (SKILL.md). The protocol doc explains they're separate, but the naming inconsistency will trip up contributors.
README says "Phase 2 — 5" but SKILL.md defines Phases 0–4. Looks like a numbering error in the README.

Agent paths

All 5 agents reference ../skills/prd-review/references/reviewer-protocol.md as a relative path, while SKILL.md uses $SKILL_DIR/references/.... After Lola installation the directory structure may differ — worth aligning on one convention.

CI

publish-cue.yml publishes on tag push but never validates the schema against the examples first. A cue vet step before cue mod publish would catch regressions before they reach the registry.

Missing artifact

README references [LICENSE](LICENSE) but no LICENSE file exists in this PR. Broken link on day one.

yvonnedevlinrh · 2026-08-14T08:49:49Z

+
+#PRDDocument: {
+	header: #PRDHeader
+	slug?:  string & =~"^[a-z][a-z0-9-]*$"


Both examples/parent-prd.yaml and examples/phase-prd.yaml use slug: my-feature. Since FR/AC/NFR IDs embed the slug abbreviation (e.g. FR-MF-001), sharing a slug across parent and phase creates an ambiguous ID namespace when a second phase is added.

Options: add a schema constraint that slug must differ when parent is set, or use distinct slugs in the examples (e.g. my-feature-phase1).

yvonnedevlinrh · 2026-08-14T08:52:07Z

+	// A document is either a phase (has `phase`) or a parent (does not).
+	// Each shape has its own required fields — `header` alone is not a
+	// valid document either way.
+	if phase != _|_ {


Minor: the if phase != _|_ / if phase == _|_ conditional is valid CUE, but a new contributor unfamiliar with CUE bottom values might find a brief comment helpful — something like // Discriminate parent vs phase document shape.

yvonnedevlinrh · 2026-08-14T08:57:06Z

+        uses: cue-labs/registry-login-action@66d40052b0206031343e17173425fa10508968d0 # v1.0.3
+      - name: Publish module
+        env:
+          REF_NAME: ${{ github.ref_name }}


Consider adding a validation step before publish to catch schema regressions before they reach the registry:

- name: Validate examples run: | for f in examples/*.yaml; do cue vet schema/prd.cue "$f" -d '#PRDDocument' done

yvonnedevlinrh · 2026-08-14T08:59:28Z

+{
+  "agent": "prd-guard",
+  "sections_read": ["parent.personas", "phase1.functional_requirements"],
+  "verdict": "APPROVE | REQUEST CHANGES",


Per-agent verdict uses "APPROVE | REQUEST CHANGES" but the council-level verdicts in SKILL.md L175-179 use APPROVED / NEEDS REVISION / BLOCKED. The naming inconsistency (APPROVE vs APPROVED) could confuse contributors. Consider aligning — e.g. "APPROVE" / "REQUEST_CHANGES" here, with a note that these map to the council's ternary verdict.

yvonnedevlinrh · 2026-08-14T09:00:16Z

+
+PRD family file paths (parent + phase YAML) provided in the delegation
+prompt, plus
+`../skills/prd-review/references/reviewer-protocol.md`.


This (and all 4 other agents) uses a relative path ../skills/prd-review/references/reviewer-protocol.md. SKILL.md uses $SKILL_DIR/references/reviewer-protocol.md for the same file. After Lola installation the directory layout may differ from the source repo structure. Worth aligning on one path convention.

yvonnedevlinrh · 2026-08-14T09:04:38Z

+
+## License
+
+Apache-2.0 — see [LICENSE](LICENSE).


[LICENSE](LICENSE) is a broken link — no LICENSE file exists in this PR or the repo. If this is Apache-2.0 as stated, the LICENSE file should be added in this PR.

There is a LICENSE file on main.

yvonnedevlinrh · 2026-08-14T09:04:53Z

+`--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


"Phase 2 — 5" doesn't match SKILL.md, which defines Phases 0–4. Should this read "Phases 2–4" (Dispatch, Verify, Synthesis)?

- schema/prd.cue: comment explaining phase discriminator conditional - examples/phase-prd.yaml: distinct slug/ID prefix from parent to avoid FR/AC namespace collision - publish-cue.yml: validate examples against schema before publish - reviewer-protocol.md: align per-agent verdict naming with council ternary (APPROVE/REQUEST_CHANGES), clarify it's not a 1:1 mapping - module/agents/prd-*.md: stop hardcoding relative path to reviewer-protocol.md, defer to SKILL_DIR-resolved path passed by the dispatching skill - README.md: fix phase range reference (Phases 2-4, not "2 - 5") Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Jennifer Power <barnabei.jennifer@gmail.com>

jpower432 requested a review from a team August 12, 2026 23:41

ci: updates publish workflow to use CUE Trusted Publishing

33b5f7c

Signed-off-by: Jennifer Power <barnabei.jennifer@gmail.com>

jpower432 force-pushed the initial branch from b3befe7 to 33b5f7c Compare August 13, 2026 19:56

yvonnedevlinrh approved these changes Aug 14, 2026

View reviewed changes

Navigation Menu

Uh oh!

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

feat: design prd-review into 5 dispatchable agents with JSON verdict#1
jpower432 wants to merge 3 commits into
unbound-force:mainfrom
jpower432:initial

jpower432 commented Aug 12, 2026 •

edited

Loading

Uh oh!

yvonnedevlinrh left a comment

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

jpower432 Aug 14, 2026

Uh oh!

yvonnedevlinrh Aug 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jpower432 commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Reviewer Hints

Uh oh!

yvonnedevlinrh left a comment

Choose a reason for hiding this comment

Review Summary

Key findings

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jpower432 commented Aug 12, 2026 •

edited

Loading