mb-from-prd

mb-from-prd — PRD → Memory Bank (greenfield)

• What it does: converts a PRD into structured project knowledge and traceable planning artifacts.
• Use it when: the project is greenfield and prd.md or equivalent requirements already exist.
• Input: prd.md or user-provided PRD text plus an initialized .memory-bank/.
• Output: product, RTM, epics, features, and SDD design routing ready for mandatory /spec-design and per-feature /spec-improve before /prd-to-tasks.

Preconditions

• You are in the repo root.
• .memory-bank/prd.md exists with type: prd, clarification_status: complete, and constitution_checked: true; otherwise run /write-prd first.
• .memory-bank/spec-index.md exists after /spec-init as the required lightweight SDD route map for PRD decomposition. After /prd, mandatory /spec-design consumes that map, records a minimal or full backbone gate, and may update backbone SDD specs and spec-index when features share domain/model/contracts/state/security/runtime design.
• Optional Analysis artifacts such as a product brief may exist; use them as upstream PRD input, but do not require them.
• .memory-bank/ exists. If not, run mb-init first (or create the skeleton manually).

Process

1) Load clarified PRD

1. Read .memory-bank/prd.md.
2. Confirm frontmatter has type: prd, clarification_status: complete, and constitution_checked: true.
3. Stop if PRD contains unresolved NEEDS CLARIFICATION markers that affect decomposition.
4. Read .memory-bank/spec-index.md as the lightweight SDD route map. Stop and run /spec-init if the index is missing, stale, placeholder-only, has broken links, is ambiguous, or cannot safely identify relevant existing specs and planned/candidate/unknown/not_applicable areas.
5. Determine relevant authoritative specs from PRD sections, affected product areas, requirements, actors, data/domain model, contracts/APIs, states/lifecycles, security/compliance, runtime/operations, and verification strategy.
6. Resolve and read only those relevant authoritative spec files routed by .memory-bank/spec-index.md. Do not load every SDD spec by default.
7. If a relevant authoritative spec conflicts with the PRD, stop and ask for explicit resolution through a spec or PRD amendment.
8. Start a task protocol folder:
   • .protocols/PRD-BOOTSTRAP/
   • plan.md (steps)
   • decision-log.md (Q/A and choices)

2) Skills / tooling discovery (optional but recommended)

If the PRD mentions “use skills / tools / CLIs”:

• run /find-skills (project-installed first; marketplace second)
• propose a minimal set of relevant skills to use (do not install without confirmation)

3) No Deep Questioning here

PRD-level ambiguity is handled by /write-prd. Do not ask Deep Questioning rounds in this skill. Optional Analysis (/analysis, /brainstorm, /brief) improves /write-prd input.

If the target mode is full autonomous:

• non-blocking gaps may be recorded as explicit Assumptions
• blocking gaps (security/compliance/external contracts/data-loss risks) must halt the run

4) Write L1 Product brief

Update .memory-bank/product.md (use the user’s wording).

5) Requirements + RTM

Update .memory-bank/requirements.md:

• Enumerate REQ-IDs.
• Define “out of scope”.
• Fill RTM: REQ → Epic → Feature → Test.

6) Create Epics (L2, draft-first)

For each epic:

• Create .memory-bank/epics/EP-<NNN>-<slug>.md
• Use references/epic-template.md.
• Ensure business value + success metrics.
• Fill optional sections such as Source artifacts, Normative inputs, and Constraints / invariants only when they are grounded in evidence.
• Default status: draft until open questions are resolved.

7) Create Features (L3, draft-first)

For each feature:

• Create .memory-bank/features/FT-<NNN>-<slug>.md
• Use references/feature-template.md.
• Ensure autonomy and explicit acceptance criteria.
• Do not add clarification metadata by default. Add clarification_status: pending|blocked only when the PRD explicitly leaves a feature-level blocker that affects task decomposition.
• Fill optional sections such as Source artifacts, Normative inputs, Constraints / invariants, and Verification targets only when they are grounded in evidence.
• Include the ## SDD Design Gate section in every feature. This routes to /spec-improve FT-<NNN> before /prd-to-tasks FT-<NNN> but does not introduce a placeholder spec_design_status or a new blocking status.
• Default status: draft until acceptance criteria + verification plan are solid.

8) Tasks planning (per-feature, no “everything at once”)

Do not generate a full task queue “в лоб” for all features in one pass.

Instead:

1. Ensure .memory-bank/schemas/task.schema.json and .memory-bank/tasks/index.json exist. A fresh skeleton may have { "version": 1, "tasks": [] }.
2. Run /spec-design after /prd. For small independent T0/T1 features it may record a minimal backbone with irrelevant areas marked not_applicable; for shared/T2/T3 concerns it creates or updates the needed backbone SDD specs and spec-index. This is not another mandatory heavy phase: it creates no tasks and no feature-local implementation design.
3. For each selected feature, run /spec-improve FT-<NNN> first, then /prd-to-tasks FT-<NNN> to produce:
   • .memory-bank/tasks/plans/IMPL-FT-<NNN>.md
   • atomic .memory-bank/tasks/TASK-*.task.json records grouped by wave, each with mandatory tier: T0|T1|T2|T3

When enough structured evidence exists, those feature-level plans and task records may include optional richer fields such as source_artifacts, normative_inputs, constraints, invariants, and verification_targets. Task routing is authoritative only through task.tier; the old risk / risk.level model is invalid. Canonical SDD planning path is /write-prd → /spec-init → /prd → /spec-design → /spec-improve FT-<NNN> → /prd-to-tasks FT-<NNN>. /spec-improve remains the feature-level gate after the mandatory backbone gate. Run /clarify-feature FT-<NNN> only when a feature is explicitly pending/blocked. For simple T0/T1-like features, /spec-improve may set spec_design_status: not_required with a concise rationale.

This keeps planning accurate and avoids speculative task explosions.

9) Support docs for key concepts

For every concept that would otherwise require “reading many files” to understand later, create support docs.

Compatibility/default path:

• .memory-bank/architecture/<concept>.md (WHAT/WHY)
• .memory-bank/guides/<concept>.md (HOW)

Optional richer support docs:

• .memory-bank/contracts/...
• .memory-bank/states/...
• .memory-bank/runbooks/...
• .memory-bank/testing/...

Rules:

• classic duo docs remain valid and useful
• richer docs are additive and should be grounded in evidence
• if richer docs exist, route them from .memory-bank/spec-index.md and relevant feature/concept docs
• do not create a new spec before checking existing specs through .memory-bank/spec-index.md

10) Update index

Update .memory-bank/index.md with annotated links to everything new.

11) Review gate

Run a fresh-context review (preferably mb-review).

12) Autonomous handoff (optional)

If the goal is “PRD → done without more user interaction”:

• do not execute tasks from here manually
• hand off to generated project command /autonomous

Definition of done

• product.md + requirements.md are coherent.
• Every REQ maps to an Epic/Feature in RTM.
• Epics and features exist with acceptance criteria.
• .memory-bank/spec-index.md routes existing/planned/candidate/unknown/not_applicable SDD design areas.
• No schema-backed task records are required from mb-from-prd itself.
• If task planning is explicitly continued with /spec-improve FT-<NNN> and /prd-to-tasks FT-<NNN>, schema-backed task records are indexed in .memory-bank/tasks/index.json; every task has tier.
• index.md is updated.