Synthesize Raw Input

Requirements arrive as raw, unstructured artifacts: meeting transcripts from Zoom or Teams, Slack threads, support tickets, customer emails, beta feedback forms. The gap between these raw inputs and an actionable requirements document is where most projects lose information — and where AI adds immediate value.

The synthesis step — turning raw artifacts into structured requirements — traditionally takes a PM an afternoon. With Claude, it takes minutes. But the human judgment of what matters, what is realistic, and what to prioritize still belongs to you. AI handles the mechanical extraction; you handle the meaning.

You might wonder: why not just feed all the raw sources into Claude and say "give me requirements"? You could. But decomposition — breaking a complex task into small, reviewable steps — is the single most important discipline in AI-assisted work. Each intermediate artifact is a checkpoint where you can spot-check quality, correct course, and build confidence before the next step.

Think of it as a pipeline: raw sources → structured notes → triage plan → prioritized requirements → user stories → backlog → spec. At every stage you can inspect the output, catch hallucinations, add your judgment, and fix problems before they compound downstream. Jumping straight to the end skips all those checkpoints.

Requirements typically arrive from three types of sources:

Meeting Transcripts — Auto-generated from Zoom, Teams. Full of cross-talk, tangents, action items buried in conversation. Information-dense but unstructured.

Chat & Support — Slack threads, Zendesk tickets, customer feedback channels. Scattered across time, full of +1s and tangents. Easy to lose signal in noise.

Email & Docs — Customer emails, beta feedback forms, product briefs. More structured than chat, but each source has its own format and priority language.

The pattern is: feed Claude the raw artifact, tell it what structure you want, and specify what to preserve. Claude extracts the signal; you review and correct. Two key principles: preserve the messy reality (contradictions are information — don't over-polish), and use a consistent output format across all sources so downstream steps can merge without reconciling different schemas.

Both synthesis prompts below use the same output structure: organized by topic (validation, comments, error handling, etc.) with source attribution tags showing who said what and where. This consistency matters — when the triage step reads both files, it can compare by topic instead of cross-referencing two different layouts.

Here is what just landed in your inbox — a messy meeting transcript and a dump of customer feedback. The raw inputs you will be working with are:

• requirements/sources/planning-meeting-jan25.md — Raw meeting transcript
• requirements/sources/beta-feedback-raw.md — Raw customer feedback dump

This morning, two things landed in your inbox simultaneously.

First: a transcript from yesterday's planning meeting. Four stakeholders spent 25 minutes debating what to build next. Every customer wants task comments — Acme Corp ($240K renewal) is threatening to leave without them. But the API also has zero input validation, error handling is broken, and there are hardcoded credentials. The team quickly agreed: comments first (it's the revenue driver), then validation. But the details need structuring.

Second: a dump of customer feedback from three beta customers. Acme Corp needs comments for their 200-engineer team. Bright Labs is frustrated by broken error handling. Meridian Health flagged security gaps in their compliance review. All three mention comments. Two are blocked by validation issues.

This is the raw material you'll work with throughout this phase. By the end, you'll have turned this chaos into a validated feature spec with a clear backlog — without losing a single stakeholder concern along the way.

You should be in the taskflow folder with npm install already done. The project has a requirements/sources/ folder with raw artifacts: a meeting transcript and raw customer feedback.

Step 1 — Start Claude Code: Launch Claude Code from the taskflow folder.

Run in terminal:

1
claude

Step 2 — Synthesize meeting transcript: Ask Claude to synthesize the meeting transcript into organized stakeholder notes.

Tell Claude:

Read the meeting transcript in requirements/sources/planning-meeting-jan25.md.
This is a raw Zoom auto-transcript from a planning meeting with 4 stakeholders.

Synthesize it into a structured document at
requirements/stakeholder-notes.md, organized by topic
(e.g. input validation, comments, error handling, auth/security, etc.).

For each topic, capture:
- What was requested and by whom [Source: meeting/Name]
- Direct quotes where they reveal priorities
- Contradictions or unresolved debates between stakeholders

Keep the messy reality — don't over-polish. Real stakeholder notes
have contradictions and open questions.

Observe: Claude reads the raw transcript and produces a structured document organized by topic. Notice how it attributes each point to a specific person, preserves direct quotes, and flags the unresolved priority debate. Compare to what you'd have written manually.

Open requirements/stakeholder-notes.md and skim it. Does every point trace back to a named stakeholder? Are the contradictions and open debates still visible, or has Claude over-polished them away?

Step 3 — Synthesize customer feedback: Now synthesize the customer feedback using the same format.

Tell Claude:

Read the raw beta feedback in requirements/sources/beta-feedback-raw.md.
This contains Zendesk tickets, Slack messages, and email threads from 3 beta customers.

Synthesize it into a structured document at
requirements/customer-feedback.md, organized by topic — same
structure as stakeholder-notes.md.

For each topic, capture:
- What was requested and by whom [Source: Zendesk/CustomerName or Slack/CustomerName]
- Feature requests vs bug reports vs usability issues
- Urgency signals (dealbreakers, deadlines, blockers)

Preserve the customer voice — don't sanitize their frustration.

Observe: Claude processes three different feedback formats into a single structured document. Notice it uses the same topic-based structure as the stakeholder notes — this consistency will make the triage step much cleaner since both files can be compared topic-by-topic.

Open requirements/customer-feedback.md and compare it side-by-side with requirements/stakeholder-notes.md. Are the topic headings consistent across both files? Can you find a topic (e.g. comments, validation) that appears in both — and does it read the same way?