# Prompt: Raw Notes to Testable Requirements Register

> A reusable prompt that turns messy meeting notes into a categorized requirements register with acceptance checks, gap flags and open questions.

## Install

Copy the content below into your project:

# Prompt: Raw Notes to Testable Requirements Register

A reusable prompt that turns messy meeting notes into a categorized requirements register with acceptance checks, gap flags and open questions.

## 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.

## Source and thanks

Original TokRepo prompt (CC BY 4.0), task: extract requirements and acceptance checks from stakeholder notes. Reference context: [ChatGPT release notes](<https://help.openai.com/en/articles/6825453-chatgpt-release-notes>), reviewed 2026-10-04; these templates do not depend on a specific newly announced feature. The illustrative worked example inside the prompt is fictional and not real data.

## 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](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) · Reviewed 2026-10-04

Original TokRepo prompt · [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Reference documents retain their own rights.

---

<!-- ZH -->

# 提示词：把零散笔记整理为可验收需求表

一条可复用的提示词，把零散的会议记录整理为分类需求登记表，附验收检查、缺口标记与待确认问题。

## 开始使用

把原始干系人笔记粘贴到提示词中 `MY INPUT (paste below, replacing this line):` 这一行的位置，然后在任何可接受文本的普通 AI 对话中运行该提示词。可在笔记后补充可选背景信息（项目名称、目标日期、已知约束、已在使用的需求编号）。

**你会得到什么：** 一份 Markdown 文档，包含 A–E 五个部分——需求登记表（编号、需求、类别、来源、验收检查、置信度）、冲突与重复、依赖关系、待确认问题，以及因笔记未支持而被排除的条目。

**如何检查输出：** 每一行都必须有来源和置信度；每条功能性或数据类需求都必须给出“给定/当/则”形式的验收检查，或标注 `NEEDS DETAIL`；冲突部分引用的编号必须真实存在于表格中。若某一行在笔记中找不到依据，请删除它。

## 适用场景

团队开完会常常只剩零散纪要和聊天片段，却没有一份可验证的需求清单。本提示词把这些笔记整理成结构化的需求草稿登记表，供人在确定范围之前评审。它只依据粘贴进来的文本，不会补充行业通用要求、编造指标阈值，也不会假设某人已批准某事；不确定的内容会被标注，而不是猜测。

面向办公与小型团队场景：记录纪要、需要可评审产出物的人。无需终端、API 密钥或任何集成。

## 前提与权限

- 一个可粘贴文本的普通 AI 对话界面。
- 你的笔记，以及可选的项目名称、目标日期、约束和已有编号。
- 获得把这些笔记提供给该工具的授权。笔记常含姓名、客户数据或报价：粘贴前请脱敏或匿名化，并遵守所在机构的数据规定。
- 若团队已有在用需求编号，请一并提供，避免新编号冲突。

## 局限

- 产出仅为供人工评审的草稿，不代表已批准、已定稿或已完整。
- 该提示词不会发送、安排或通知任何人，也不会更新任何跟踪系统。
- 若笔记内容单薄，会出现大量 `NEEDS DETAIL` 行——这是正确结果，而非失败。
- 粘贴更新后的笔记会重新跑一遍，而不是与先前登记表合并。
- 已审阅来源；未做运行测试——文档中的配置仅为说明，未执行任何命令，也未在此验证任何模型输出。

## 常见问题

**我的笔记只是零散聊天记录，够用吗？** 够用，只要其中包含明确陈述或可清晰推断的内容。含糊的说法会变成低置信度行或待确认问题，而不是被编造成需求。

**两个人似乎对同一件事说法不一致，会怎样？** 提示词会把两种理解都列入登记表，并把取舍放进待确认问题，由具名的人来决定。

## 来源与致谢

TokRepo 原创提示词（CC BY 4.0），任务：从干系人笔记中提取需求与验收检查。参考背景：[ChatGPT release notes](<https://help.openai.com/en/articles/6825453-chatgpt-release-notes>)，查阅日期 2026-10-04；这些模板不依赖任何新发布的具体功能。提示词中的示例为虚构，非真实数据。

## 完整可复制提示词

你正在帮助我把原始干系人笔记转换为一份可评审、带验收检查的需求登记表。我会把笔记粘贴在下面。请只依据这些笔记中实际存在的内容进行工作；不要补充行业通用要求，不要推断缺失的数字，也不要假设某位干系人同意了其并未说过的事情。

MY INPUT (paste below, replacing this line):
- 原始干系人笔记、会议纪要、聊天片段或邮件片段。如可获得，请包含发言人姓名或角色。
- 可选：项目名称、目标日期、已知约束，以及任何已在使用的需求编号。

你的任务
1. 识别笔记中陈述或明确暗示的每一条独立需求。当复合句描述不同的义务时，将其拆分为多条独立需求。
2. 将每条需求归类为以下之一：功能性、数据、访问/权限、报告、合规/审计、可用性、运营。
3. 分配一个稳定的编号（R-01、R-02、……），并记录支持该需求的来源短语或发言人。若来源不明确，请在“来源”列中说明。
4. 为每条需求至少编写一项验收检查，形式为：给定 [上下文]，当 [动作]，则 [可观察结果]。若笔记未提供足够细节以编写可测试的检查，请写 NEEDS DETAIL 并明确说明缺失了什么。
5. 标记需求之间的冲突、重复和依赖关系。
6. 针对笔记中任何不清楚之处，生成一份待确认问题清单。

输出格式
使用 Markdown，按顺序包含以下部分：
A. 需求登记表，列为：编号 | 需求（祈使句） | 类别 | 来源 | 验收检查 | 置信度（高/中/低）。
B. 冲突与重复，列出涉及的编号及一行说明。
C. 需求之间的依赖关系。
D. 待确认问题，每个至少关联一个需求编号。
E. 因笔记未支持而被排除的条目。

不确定性与缺失输入
- 绝不要编造截止日期、指标阈值、负责人或批准。
- 若某条需求可有两种理解，请在登记表中列出两种理解，并把选择放入“待确认问题”。
- 若笔记中没有某条需求的验收细节，请标注 NEEDS DETAIL，而不是猜测一项测试。

虚构的示例（仅为说明，非真实数据）
输入摘录：“Priya 说导出必须包含所有活跃客户，而不是已归档客户。Marcus 希望任何内容发出前都要财务批准。有人提到应该每周运行一次，但没人确认。”
示例输出形态：
- R-01 | 导出必须仅包含活跃客户，排除已归档客户。 | 数据 | Priya | 给定一份活跃客户列表，当导出运行时，则已归档客户不出现。 | 高
- R-02 | 导出在发布前需要财务批准。 | 运营 | Marcus | 给定一份已完成的导出，当在未获财务批准的情况下尝试发布时，则发布被阻止。 | 中
- R-03 | 导出可每周运行一次。 | 运营 | 未确认的群体发言 | NEEDS DETAIL：确认频率、日期和时区。 | 低
- 待确认问题 Q1，关联 R-03：由谁确认时间安排？

完成前的评审检查
- 每一行需求都有来源和置信度值。
- 每条功能性或数据需求都有验收检查或 NEEDS DETAIL。
- 没有任何需求是依据通用良好实践编造出来的。
- 冲突列表引用 A 部分中真实存在的编号。
- 待确认问题可由具名的人或角色回答，而不是含糊不清。

边界
- 本产出仅为供人工评审的草稿登记表。
- 不要声称这些需求已获批准、已定稿或已完整。
- 不要告诉我发送、安排或通知任何人；下一步是由人来评审这份草稿登记表。
- 若我之后粘贴更新后的笔记，请将其视为新输入并重复整个流程，而不是悄悄合并。

如果我还没有粘贴笔记和任何可选背景信息，先要求我粘贴。

## 参考资料与复用

- [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) · Reviewed 2026-10-04

TokRepo 原创提示词 · [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)。参考资料保留各自原有权利。

---
Source: https://tokrepo.com/en/workflows/prompt-raw-notes-testable-requirements-register-e299e44a
Author: Prompt Lab