Prompt: Raw Notes to Testable Requirements Register

Start here

Paste your raw stakeholder notes where the line MY INPUT (paste below, replacing this line): appears, then run the prompt in any ordinary AI chat that accepts text. Add optional context (project name, target date, known constraints, existing requirement IDs) right after the notes.

What you get back: a Markdown document with sections A–E — a requirements register table (ID, requirement, category, source, acceptance check, confidence), conflicts and duplicates, dependencies, open questions, and items excluded because the notes did not support them.

How to check the output: every row must have a source and a confidence value; each functional or data row must show either a Given/when/then acceptance check or NEEDS DETAIL; the conflicts section must cite IDs that actually exist in the table. If a row cites nothing from your notes, delete it.

What this is for

Teams often leave a meeting with scattered minutes and chat excerpts but no testable list of what was actually asked for. This prompt converts those notes into a structured draft register that a person can review before scope is committed. It works only from the pasted text and refuses to add industry-standard requirements, invent thresholds, or assume an approval nobody stated. Uncertain items are marked rather than guessed.

Built for office and small-team settings: anyone who takes minutes and needs a reviewable artifact. No terminal, API key or integration is required.

Prerequisites and permissions

• An ordinary AI chat interface that accepts pasted text.
• Your notes, plus optional project name, target date, constraints and existing IDs.
• Permission to share the notes with that tool. Notes frequently contain names, client data or pricing: redact or anonymise before pasting, and follow your organisation's data rules.
• If you use requirement IDs already in circulation, supply them so new IDs do not collide.

Limitations

• Output is a draft for human review only; it is not approved, final or complete.
• The prompt does not send, schedule or notify anyone, and it does not update any tracker.
• If your notes are thin, expect many NEEDS DETAIL rows — that is the correct result, not a failure.
• Pasting an updated set of notes starts a fresh pass rather than merging with the earlier register.
• source reviewed; runtime not tested — the documented setup is instruction only; no command was executed and no model output was verified here.

FAQ

My notes are a rough chat dump. Is that enough? Yes, as long as they contain statements or clear implications. Vague remarks become low-confidence rows or open questions rather than invented requirements.

Two people seemed to disagree about the same thing. What happens? The prompt lists both readings in the register and moves the choice into the open-questions section, so a named person can decide.

Complete reusable prompt

You are helping me turn raw stakeholder notes into a reviewable requirements register with acceptance checks. I will paste the notes below. Work only from what is present in those notes; do not add industry-standard requirements, infer missing numbers, or assume a stakeholder agreed to something they did not say.

MY INPUT (paste below, replacing this line):

• Raw stakeholder notes, meeting minutes, chat excerpts, or email fragments. Include speaker names or roles if available.
• Optional: project name, target date, known constraints, and any requirement IDs already in use.

YOUR TASK

1. Identify every distinct requirement stated or clearly implied by the notes. Split compound sentences into separate requirements when they describe different obligations.
2. Classify each requirement as one of: functional, data, access/permission, reporting, compliance/audit, usability, or operational.
3. Assign a stable ID (R-01, R-02, ...) and record the source phrase or speaker that supports it. If the source is ambiguous, say so in the Source column.
4. Write at least one acceptance check per requirement in the form: Given [context], when [action], then [observable result]. If the notes do not supply enough detail to write a testable check, write NEEDS DETAIL and state exactly what is missing.
5. Flag conflicts, duplicates, and dependencies between requirements.
6. Produce an open-questions list for anything the notes leave unclear.

OUTPUT FORMAT Use Markdown with these sections in order: A. Requirements register table with columns: ID | Requirement (imperative sentence) | Category | Source | Acceptance check | Confidence (High/Medium/Low). B. Conflicts and duplicates with the IDs involved and a one-line explanation. C. Dependencies between requirements. D. Open questions, each tied to at least one requirement ID. E. Items excluded because the notes did not support them.

UNCERTAINTY AND MISSING INPUT

• Never invent a deadline, metric threshold, owner, or approval.
• If a requirement could be read two ways, list both readings in the register and put the choice in Open questions.
• If the notes contain no acceptance detail for a requirement, mark it NEEDS DETAIL rather than guessing a test.

FICTIONAL WORKED EXAMPLE (illustrative only, not real data) Input excerpt: "Priya said the export must include all active clients, not archived ones. Marcus wants finance to approve before anything goes out. Someone mentioned it should run weekly but no one confirmed." Illustrative output shape:

• R-01 | The export must include active clients only, excluding archived clients. | Data | Priya | Given an active-client list, when the export runs, then archived clients are absent. | High
• R-02 | The export requires finance approval before release. | Operational | Marcus | Given a completed export, when release is attempted without finance approval, then the release is blocked. | Medium
• R-03 | The export may run weekly. | Operational | Unconfirmed group remark | NEEDS DETAIL: confirm frequency, day, and timezone. | Low
• Open question Q1 tied to R-03: Who confirms the schedule?

REVIEW CHECKS BEFORE YOU FINISH

• Every requirement row has a source and a confidence value.
• Every functional or data requirement has either an acceptance check or NEEDS DETAIL.
• No requirement was invented from general good practice.
• Conflicts list references real IDs from section A.
• Open questions are answerable by a named person or role, not vague.

BOUNDARIES

• This produces a draft register for human review only.
• Do not claim the requirements are approved, final, or complete.
• Do not tell me to send, schedule, or notify anyone; the next step is a person reviewing the draft register.
• If I later paste an updated set of notes, treat them as a new input and repeat the process rather than silently merging.

Start by asking me to paste the notes and any optional context if I have not already done so.

References and reuse

• ChatGPT release notes · Reviewed 2026-10-04

Original TokRepo prompt · CC BY 4.0. Reference documents retain their own rights.