Meeting-to-PRD

Based on this meeting transcript, produce a product one-pager. The
goal is a decision-forcing document a reader can react to in five
minutes.

Be faithful to the conversation — include only problems, solutions,
and scope decisions that were actually discussed. If something is
unclear, write "Unknown — needs decision" rather than guessing.

No emojis. Be concise. Total length under 500 words.

Format:

# {Project / Feature Name}
**Status:** Draft (one-pager)
**Author:** {Name from meeting}
**Source meetings:** {Meeting name — date}
**Last updated:** YYYY-MM-DD

## Problem
Two to four sentences. Who is affected, what's broken, what the
cost of the problem is. Use the user's framing if available —
verbatim if useful.

## Proposed solution
Two to four sentences. The shape of what we'd build, not the
implementation. Specific enough to react to; not so specific that it
pre-empts design.

## Why now
One to two sentences on the trigger. Why are we addressing this in
this period? What's the strategic context?

## Success criteria
How we'll know this worked. Outcome-oriented, not output-oriented.
- {Criterion}

## Out of scope (explicit)
What was discussed but is NOT part of this work.
- {Item}

## Alternatives considered
Other approaches the conversation surfaced. For each: one sentence on
the approach, one sentence on why we're not doing it.
- **{Alternative 1}:** rejected because {reason}
- **{Alternative 2}:** rejected because {reason}
- **Do nothing:** rejected because {reason} (always include this one)

## Open questions
Things we need to answer before scaling to a full PRD or starting work.
- {Question}

## Asks
What is the author asking the reader to do?
- {Approval to proceed | Feedback on direction | Decision on a specific question}

Based on the meeting transcript(s) provided, produce a full PRD for
the project. Be faithful to the conversation. Distinguish between
things explicitly decided, things proposed but not decided, and things
still open. Mark each accordingly.

If a section can't be filled in from the source meetings, write "To
be determined — see open questions" and add the relevant open question.

No emojis. Length 800–1500 words depending on scope.

Format:

# PRD: {Project Name}
**Status:** Draft
**Author:** {Name}
**Reviewers:** {Stakeholders who need to sign off}
**Source meetings:** {List of source meetings}
**Last updated:** YYYY-MM-DD
**Target ship date:** {from meeting or "TBD"}

## Summary
Three to five sentences. The problem, the solution, the expected
outcome. Written so a reader who reads only this paragraph has the
picture.

## Background and context
Two to four sentences on why this work is happening now.

## Problem statement
One paragraph. The specific user problem. Cite customer quotes where
useful. Quantify if quantification came up.

## Users / personas
Specific personas — not "users."

## Goals (and non-goals)
- **Goals:** outcome-oriented, measurable
- **Non-goals:** what this work does NOT aim to do

## Proposed solution
Two to four paragraphs on the approach. Description, not pixel-detail.

## Key scenarios / user flows
Two to five scenarios the solution supports. For each:
- User, trigger, flow, outcome

## Functional requirements
Numbered or bulleted; testable; specific.

## Non-functional requirements
Performance, security, accessibility — only the ones that materially
apply or that the meeting discussed.

## Success metrics
- **Primary metric:** value, target
- **Secondary metrics:**
- **Counter-metrics (what should NOT degrade):**

## Risks and mitigations
For each material risk: likelihood, impact, mitigation.

## Dependencies
- Internal: other teams, systems, or projects
- External: third parties, customer commitments, vendors

## Timeline / phasing
If discussed; otherwise "To be sized in refinement."

## Out of scope (explicit)
- {Item}

## Alternatives considered
- **{Alternative}:** description — why rejected

## Open questions
Items raised but not resolved. Should converge to zero before build.
- {Question} — owner — target resolution

## Stakeholder sign-offs
- {Role / Name} — Approved / Pending / Concerned

## Appendix
- Customer quotes, research links, related PRDs

Based on the meeting transcript, produce a technical design document.
Audience: engineering — current team and future engineers picking up
the codebase.

If multiple approaches were discussed, capture each with the evaluation
that was performed. Mark each architectural decision as decided /
proposed / open.

Format:

# Technical Design: {System / Feature Name}
**Status:** Draft
**Author:** {Name}
**Reviewers:** {Tech lead, architecture council, relevant team leads}
**Source meetings:** {List of source meetings}
**Related PRD:** {Link if applicable}

## Problem and goals
One to two paragraphs.

## Current state
- Relevant existing architecture
- Existing data models / APIs being touched
- Current limitations or constraints

## Proposed approach
- High-level architecture
- Key components: new, modified, deprecated
- Data flow

## Alternatives considered
For each:
- Approach, pros, cons, rejected because

## Data model changes
- New entities, modified entities, migrations required

## API surface changes
- New endpoints, modified endpoints (breaking flagged), deprecated
  endpoints (with sunset)
- Backward compatibility

## Non-functional considerations
- Performance: load, latency targets
- Security: auth, data protection, threat model
- Reliability: failure modes, recovery, SLOs
- Cost: infrastructure implications

## Migration / rollout plan
- Phasing, feature flags, canary, rollback

## Testing approach
- Unit, integration, load, manual QA

## Risks
- Risk: likelihood/impact: mitigation

## Dependencies
- Other systems, teams, services

## Open questions
- Question — owner — target resolution

## Appendix
- Sequence diagrams, ERDs, references

This prompt updates an existing PRD based on a new meeting that
contained additional decisions, refinements, or shifts in direction.

Inputs:
- The existing PRD (paste below)
- The new meeting transcript (the Earmark artifact this task runs on)

Produce an updated version of the PRD that:
- Preserves the existing structure
- Incorporates the new decisions and changes from the meeting
- Flags what changed so reviewers can see deltas
- Resolves open questions that were addressed
- Adds any new open questions raised

Output the updated PRD using the original structure, then append:

## Change log — YYYY-MM-DD
**Source meeting:** {Meeting name — date}

**Changes:**
- {Section} — {what changed}: {brief description}
- {Section} — {what was added}
- {Section} — {what was removed and why}

**Open questions resolved:**
- {Question} — resolution

**Open questions added:**
- {Question}

**Decisions made:**
- {Decision} — by {whom in the meeting}