brief

/brief - Product Brief input contract

The Product Brief captures what to build, for whom, why, the MVP boundary, and known decisions. It is not a PRD, backlog, marketing document, research report, or task plan.

<input_contract> Use /brief for a concept that is coherent enough to summarize, either directly from operator input or after /brainstorm.

Read when present and relevant:

• the latest .memory-bank/analysis/brainstorming/BR-*.md;
• .memory-bank/analysis/product-brief.md;
• .memory-bank/glossary.md and the glossary row in .memory-bank/spec-index.md;
• .memory-bank/constitution.md for next-step routing;
• operator-provided concept, notes, or PRD-like text.

If brainstorming exists, include it under Source artifacts. A report is not required when the operator supplied a clear concept directly. </input_contract>

<creator_vibe_contract> Before interpreting source artifacts or interviewing the operator, load and follow the installed creator-vibe skill. Apply it while reading the concept, brainstorming report, notes, PRD-like text, and operator answers so the brief preserves the intended human experience and what is distinctive about the product.

Creator-vibe guides interpretation and phrasing only. It does not supply a missing decision, promote an inference to accepted product intent, or expand scope, value, MVP, success measures, constraints, or terminology without an explicit operator answer or authoritative source. </creator_vibe_contract>

<hard_invariants> Allowed outputs are only:

• .memory-bank/analysis/index.md;
• .memory-bank/analysis/product-brief.md;
• .memory-bank/glossary.md;
• the glossary row in .memory-bank/spec-index.md.

Do not create features, task records, implementation plans, research reports, PRFAQ, command aliases, or .memory-bank/analysis/assumptions.md. Preserve the existing decision vocabulary proceed|blocked; do not add no-go. </hard_invariants>

<operator_decisions> When a relevant ambiguity or branch can change product intent, users, scope, non-goals, value, constraints, success measures, or the PRD input, interview the operator before choosing. Questions are adaptive: ask one or group only tightly related decisions, use multiple choice or open form as useful, explain the impact, and optionally recommend an option.

A recommendation/default is not accepted until the operator explicitly answers. Do not run a decorative questionnaire when authoritative evidence is already clear. Put accepted decisions into the applicable brief sections and keep unresolved material choices under Open Questions with Decision: blocked. </operator_decisions>

<required_outputs> Create or update .memory-bank/analysis/product-brief.md with required frontmatter:

---
description: Product Brief input contract for PRD.
status: draft
type: product-brief
---

Keep the brief concise and cover:

• Metadata: status, Decision: proceed|blocked, and source artifacts;
• One-liner, Target Users, Problem, Current Alternatives;
• Value Proposition and Product Concept;
• MVP Scope and Non-goals;
• Success Metrics and Constraints;
• Assumptions, Risks, Open Questions;
• PRD Input Summary;
• final ## Decision with proceed|blocked.

If .memory-bank/analysis/index.md is created, give it analysis-index frontmatter. Update the index with the brief status, source artifacts, decision, and immediate next command.

After the brief content is formed, create or update .memory-bank/glossary.md: remove bootstrap placeholders, preserve compatible existing definitions, and add only terms grounded in the accepted brief. Do not invent definitions or encode unresolved choices as facts. Keep the glossary row in .memory-bank/spec-index.md consistent and include /brief in its change route. </required_outputs>