[Mentiora /feature] Add PRD/requirements-quality review before /map-plan

[azalio]

Source

• Blog: https://mentiora.ai/blog/feature-workflow/
• External repo: https://github.com/mentiora-ai/feature-workflow
• Source files inspected read-only on 2026-08-13 via gh api:
  • feature.md
  • checklist.md
• Repo metadata checked on 2026-08-13: mentiora-ai/feature-workflow, default branch main, description Example workflow patterns for Claude Code. Plan before you code. Review before you ship., observed stars: 25.

Relevant source takeaways

Mentiora /feature is intentionally small: one slash command plus a checklist template. The transferable parts are not the markdown implementation itself; they are the upstream workflow gates:

• The workflow does not start coding immediately. It first assesses BUILD/FIX mode and S/M/L size.
• It runs a codebase scan for reusable code, similar precedents, and collision risks before planning.
• It has a ReAct clarification loop before plan writing: ask one focused question with concrete options, record the answer, and repeat until the agent can write a plan the user would likely approve.
• It treats plan review as a first-class gate: Security, Quality, and Devil's Advocate reviewers inspect the plan before implementation.
• The blog generalizes the pipeline with "fitness function before code": requirements should be measurable enough that a later worker/judge can decide pass/fail.
• For requirements, the Mentiora pipeline uses an adversarial review lens that hunts hand-wavy acceptance criteria and demands measurable outcomes before later stages consume the artifact.

The useful MAP slice is upstream of /map-plan: review an externally supplied PRD/product brief/requirements note before MAP turns it into a spec and blueprint.

Repo evidence

MAP already has strong spec/planning machinery after /map-plan starts:

• /map-plan records workflow fit and can route to direct edit, /map-fast, /map-wayfind, or /map-plan; it also has --light, --deep, --force-fast, and --force-full modes (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:51-136).
• /map-plan performs discovery and an already-implemented gate before writing the spec (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:138-185).
• It interviews on broad/vague/risky requirements and requires the spec to include decisions, contradiction, invariants, constraints, edge cases, acceptance criteria, security boundaries, out of scope, and open questions (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:200-218).
• It validates source citations before decomposition (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:224-234).
• It runs a spec Devil's Advocate review before decomposition, but only after MAP has already converted the input into its own spec (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:236-264).
• It has a deep-mode architecture review before decomposition (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:275-302).
• It has a forward coverage gate from the spec's Requirements Index to blueprint coverage_map (src/mapify_cli/templates_src/skills/map-plan/SKILL.md.jinja:304-360; docs/USAGE.md:126).
• Current docs also describe implementer-readiness review for the spec before handoff to implementation (docs/ARCHITECTURE.md:392).

What is missing: a named PRD/requirements-quality review surface that runs before /map-plan writes MAP's spec. Current spec review can catch defects in the generated spec, but it does not separately preserve the verdict that the original PRD/product input was measurable, scoped, decision-complete, and fit for planning.

Existing issue search

Live duplicate checks performed on 2026-08-13:

• gh issue list --repo azalio/map-framework --state all --limit 100 --search "PRD review OR requirements-quality OR requirements review OR bmad-prd OR slop in slop out OR measurable acceptance criteria" -> no direct results.
• Previous same-session searches also checked:
  • map-plan-review OR plan review OR council review plan OR specification review OR spec review
  • PRD review OR requirements review OR bmad-prd OR slop in slop out OR acceptance criteria quality
  • Mentiora OR /feature OR feature-workflow

Close matches and why they are not duplicates:

• [Continuous Architecture] Add implementer-readiness review before decomposition #348 [Continuous Architecture] Add implementer-readiness review before decomposition is closed and implemented. It reviews MAP's spec/architecture artifact for implementability before coding. This issue is earlier: it reviews the raw PRD/requirements input before /map-plan transforms it.
• [mattpocock/skills] Add decision-frontier wayfinding before implementation planning #362 [mattpocock/skills] Add decision-frontier wayfinding before implementation planning is closed and implemented. It resolves foggy decisions over multiple sessions. This issue is a quality gate for a supplied PRD/brief, not a decision-frontier work queue.
• Scale-adaptive intelligence: automatic scope→workflow-depth mapping #287 Scale-adaptive intelligence is closed and implemented. It routes workflow depth; it does not judge PRD quality.
• SpecKit-style constitution-driven pipeline: spec → plan → tasks → implement #283 SpecKit-style constitution-driven pipeline is closed and broad. MAP now has much of the spec->plan structure; this issue is a narrow upstream review surface.
• [arXiv:2606.29742] Add boundary-quality eval for architectural decomposition plans #316 boundary-quality eval scores decomposition plans, not product/PRD inputs.

No exact duplicate found.

Why this is not already covered

MAP can take weak input, ask questions, and produce a structured spec. That is useful, but it also means the first durable artifact may already contain model-added interpretation. A PRD-quality review should answer a different question:

Is the user-supplied product/requirements input itself good enough to feed into MAP planning?

Without that separate gate, MAP can make a vague PRD look rigorous by wrapping it in a better spec shape, while the original uncertainty remains under-owned.

Problem

Sloppy PRD input causes downstream waste:

• /map-plan may invent missing product decisions.
• Acceptance criteria may be structurally present but not measurable from an implementation/test perspective.
• Non-functional requirements can be implied by domain risk but absent from the input.
• UX/data/security edge cases can be discovered only after code exists.
• A tracker/task automation loop can pull weak tickets and start MAP without a visible input-quality verdict.

This is a product-input gate, not another implementation review.

Proposed slice

Add a PRD/requirements-quality review command or helper, for example:

• /map-prd-review <path-or-text>
• /map-requirements-review <path-or-text>
• or mapify requirements review <path>

Suggested artifact outputs:

• .map/<branch>/prd-review.json
• .map/<branch>/prd-review.md

Suggested verdicts:

• ready_for_plan — input is ready for /map-plan.
• needs_prd_revision — PRD/brief should be amended before planning.
• needs_user_decision — specific product/design choices must be answered before planning.
• route_to_wayfind — input is valuable but too foggy for a PRD review; create a /map-wayfind map instead.

Suggested review dimensions:

• measurable acceptance criteria;
• user/job clarity;
• explicit out-of-scope;
• non-functional requirements when implied by domain or risk;
• data model and lifecycle clarity;
• UX states and failure states;
• security/trust boundaries;
• dependencies/integrations;
• contradictions and hidden assumptions;
• testability of "done";
• migration/rollout/operational concerns when relevant.

Acceptance criteria

• A maintainer can run a documented PRD/requirements review command against a markdown file or inline text and get JSON + Markdown artifacts.
• The JSON schema has a stable verdict, findings, blocking questions, suggested PRD revisions, and route recommendation.
• needs_prd_revision and needs_user_decision include concrete, answerable items, not vague "clarify more" prose.
• The review distinguishes route_to_wayfind from needs_prd_revision: foggy strategic uncertainty goes to /map-wayfind; fixable missing PRD fields stay in PRD review.
• /map-plan documentation explains when to run PRD review first and how a ready_for_plan artifact can seed the spec.
• Tests cover:
  • hand-wavy acceptance criteria -> needs_prd_revision;
  • missing product decision -> needs_user_decision;
  • vague multi-option roadmap prompt -> route_to_wayfind;
  • complete fixture -> ready_for_plan;
  • generated artifact schema validation;
  • no mutation outside .map/<branch>/ artifacts.
• The first implementation ships default-on for the command behavior when invoked; do not hide it behind shadow/calibration mode.

Guardrails

• Do not duplicate /map-plan decomposition or spec writing. This command reviews input quality before planning.
• Do not block tiny direct edits or already-scoped engineering tasks just because they lack a formal PRD.
• Do not use another broad multi-agent ceremony unless the first slice proves a single reviewer/schema is insufficient.
• Do not store secrets, private customer data, or raw production rows in .map/ artifacts.
• Do not require hosted task trackers or external SaaS in the first slice; local markdown must work.

[azalio]

Взял задачу в работу. Реализую write_prd_review в map_step_runner.py, новый skill map-prd-review, схему PRD_REVIEW_SCHEMA и тесты. Буду работать на ветке claude/compassionate-cerf-71p8pe.

---

Generated by Claude Code

[azalio]

Implemented and merged via PR #417.

What was added:

• write_prd_review() in map_step_runner.py — validates and writes .map/<branch>/prd-review.{json,md}, updates the prd_review artifact manifest stage. Verdicts: ready_for_plan, needs_prd_revision, needs_user_decision (requires non-empty blocking_questions), route_to_wayfind. Per-finding validation: required dimension/severity/description, optional suggested_revision, no extra keys, severity in {critical, major, minor, info}.
• /map-prd-review skill (SKILL.md) — 11 review dimensions, verdicts table, step-by-step workflow, troubleshooting section, argument-hint.
• PRD_REVIEW_SCHEMA in schemas.py.
• Registered in skill-rules.json as type=manual, skillClass=task.
• 13 tests; all 4400 suite tests pass (make check green).

---

Generated by Claude Code