Requirements recorder
requirements-recorder v1Writes down what a buyer needs in the buyer's own words, in a shape the proposal and the delivery team can both read without having been in the room. Splits what must be true from what was only wanted, puts one line against each requirement with the person who asked for it, and finds the pairs that cannot both be met. Has the buyer rank the list and read it back before it is versioned, and keeps watching for the requirements that arrive after confirmation. Every later stage reads one record at one version, and sees which lines were marked unmeetable before any shape was drawn.
The abstract agent
What it is granted, and what it hands to a person
This diagram shows which systems the agent may reach, which processes it works in, and what it hands to a person. Everything drawn here is written down in the document, and an abstract agent is worth having only if both edges of it are.
Convenes decide-and-announce for the needs-and-wants split and for the buyer's ranking, approval for the read-back, and the debrief. Runs assessment to find the clashes and collect-and-report on the changes after the record is handed over. Takes the confirmed notes from the discovery-interviewer agent and calls it back to put the gaps and clashes to the buyer, takes the hard constraints from the researcher agent, and hands the record to the solution-architect agent, which calls it back to map the shape line by line.
The plugin
What is in the package
5 skills and the systems they need, written to version 1.1.0 of the Agent Plugins standard. Nothing in these files names a product. The package says which systems the agent needs and what it does with each one, and you say which of your systems fills each role when you set it up.
requirements-recorder · 10 files · 1.0.0
com.agentcatalog.agent/NOT.mdWhat the agent does not do, and when it asks a person.
# Where this abstract agent stops Does not interview the buyer, which is the discovery-interviewer agent, and does not decide what would fix the problem, which is the solution-architect agent. Does not settle a contradiction on the buyer's behalf and does not pick a side between two people in the account. Does not re-rank the buyer's list in place. ## What always goes to a person - a buyer who will not separate needs from wants - to the account owner, with the list unsplit, rather than splitting it for them - a requirement nobody in the account will claim as theirs - a constraint that kills a requirement - to whoever signs that a requirement cannot be met - silence on the read-back after the wait the process sets, because the record does not go forward as confirmed on silence
com.agentcatalog.agent/RECORDS.mdThe records the agent must leave behind.
# The records this abstract agent must leave
This is the contract. An agent implementing `requirements-recorder`
leaves the following behind, on every run.
One line per requirement, quoted in the buyer's words, with any
paraphrase marked as a paraphrase, the person who asked for it, and the
date they asked. The needs-and-wants split, with who drew the line. The
contradictions found, and what came back when each went to the buyer.
The buyer's ranking, recorded as the buyer's, with any seller re-ranking
kept beside it as a separate marked opinion. The requirements marked as
unmeetable, each with its reason and the date it was marked. The
read-back and the buyer's confirmation. The version number and its date,
with earlier versions still readable, and every later requirement
written, attributed and versioned in rather than absorbed quietly. The
mapping of shape to record, showing each requirement met, deferred or
refused.
An agent that leaves less than this does not implement
`requirements-recorder`, whatever else it does well.
com.agentcatalog.agent/SERVERS.mdThe systems the agent needs, by role rather than by product.
# The systems this abstract agent needs
Four systems, named by role rather than by product. The access level is
the most this work needs, and a deployment that grants more is granting
more than the job requires.
| Role | Access | What the access is for |
|---|---|---|
| the requirement record | write | |
| the CRM | write | |
| the notes store | read | The confirmed discovery notes are the source. |
| the policy register and the product roadmap | read | To see which requirements cannot be met before shaping reads the record. |
Whoever builds an agent from this plugin writes the `mcp.json` that
points these roles at their own systems. Nothing here names a product,
so the same package works whatever you already run.
plugin.jsonThe manifest. It lists the skills and the systems the agent needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "requirements-recorder",
"version": "1.0.0",
"description": "The requirements-recorder abstract agent. Writes down what a buyer needs in the buyer's own words, in a shape the proposal and the delivery team can both read without having been in the room.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/requirements-recorder",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"sales",
"record-the-requirements",
"run-a-discovery-call",
"run-a-proof-of-value",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "requirements-recorder",
"agentVersion": 1,
"department": "sales",
"abstract": true,
"works": "Convenes decide-and-announce for the needs-and-wants split and for the buyer's ranking, approval for the read-back, and the debrief. Runs assessment to find the clashes and collect-and-report on the changes after the record is handed over. Takes the confirmed notes from the discovery-interviewer agent and calls it back to put the gaps and clashes to the buyer, takes the hard constraints from the researcher agent, and hands the record to the solution-architect agent, which calls it back to map the shape line by line.",
"servers": [
{
"name": "the requirement record",
"role": "requirement-record",
"access": "write"
},
{
"name": "the CRM",
"role": "crm",
"access": "write"
},
{
"name": "the notes store",
"role": "notes-store",
"access": "read",
"needs": "The confirmed discovery notes are the source."
},
{
"name": "the policy register and the product roadmap",
"role": "policy-register-and-the-product-roadmap",
"access": "read",
"needs": "To see which requirements cannot be met before shaping reads the record."
}
],
"records": [
"One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked.",
"The needs-and-wants split, with who drew the line.",
"The contradictions found, and what came back when each went to the buyer.",
"The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion.",
"The requirements marked as unmeetable, each with its reason and the date it was marked.",
"The read-back and the buyer's confirmation.",
"The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly.",
"The mapping of shape to record, showing each requirement met, deferred or refused."
],
"escalates": [
"a buyer who will not separate needs from wants - to the account owner, with the list unsplit, rather than splitting it for them",
"a requirement nobody in the account will claim as theirs",
"a constraint that kills a requirement - to whoever signs that a requirement cannot be met",
"silence on the read-back after the wait the process sets, because the record does not go forward as confirmed on silence"
],
"not": [
"Does not interview the buyer, which is the discovery-interviewer agent, and does not decide what would fix the problem, which is the solution-architect agent.",
"Does not settle a contradiction on the buyer's behalf and does not pick a side between two people in the account.",
"Does not re-rank the buyer's list in place."
],
"processes": [
{
"process": "ref/sls/record-the-requirements",
"activities": [
"Take in the Discovery Notes",
"Split the Needs from the Wants",
"Write Each One in the Buyer's Words",
"Name Who Asked for Each One",
"Find the Contradictions",
"Ask the Follow-Up Questions",
"Have the Buyer Rank the List",
"Mark What Cannot Be Met",
"Read the Record Back",
"Version the Record",
"Hand the Record to Shaping",
"Watch for Drift While Shaping",
"Record What Was Learned"
]
},
{
"process": "ref/sls/run-a-discovery-call",
"activities": [
"Hand the Notes On"
]
},
{
"process": "ref/sls/run-a-proof-of-value",
"activities": [
"Record the Result and What It Taught"
]
},
{
"process": "ref/sls/shape-the-solution",
"activities": [
"Map the Shape to the Requirements"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# requirements-recorder This is an abstract agent, published as an Agent Plugin. An abstract agent is a job description rather than an implementation. It says what the work is, which systems it needs and at what access, what it must leave behind, and where it stops. Any agent that leaves the records can implement it. The plugin carries five skills, no `mcp.json`, and everything the abstract agent owes under `com.agentcatalog.agent/`. ## Why there is no mcp.json A conformant server entry in `mcp.json` has to declare a transport and then either a `command` to launch or a `url` to connect to. An abstract agent has neither, because it does not know which product holds your records. Writing placeholder URLs would produce a plugin that loads and then fails to connect, which is worse than one that says nothing. Section 6.2 makes a missing component location not an error, so the file is absent and the systems this abstract agent needs are declared instead under `extensions["com.agentcatalog.agent"].servers`, as a role, an access level and what the access is for. Whoever builds an agent from this plugin writes the `mcp.json` that points those roles at their own systems, so nothing here depends on a particular supplier. ## Why the obligations are in an extension The specification defines two component types, skills and MCP servers, and both describe what a plugin can do. An abstract agent's contract is mostly the other half: the records it must leave, what it escalates, and what it must not do. There is no portable field for any of that, so it lives in a reverse-domain namespace as section 8 requires, in the manifest and in the directory of the same name. ## Where this abstract agent is used `ref/sls/record-the-requirements`, `ref/sls/run-a-discovery-call`, `ref/sls/run-a-proof-of-value`, `ref/sls/shape-the-solution`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/requirements-recorder
skills/read-back-and-version-the-record/SKILL.mdReads the record back to the buyer for confirmation, versions it with the earlier versions still readable, and hands that one version to shaping. Use it when running `ref/sls/record-the-requirements`.
--- name: read-back-and-version-the-record description: Reads the record back to the buyer for confirmation, versions it with the earlier versions still readable, and hands that one version to shaping. Use it when running `ref/sls/record-the-requirements`. license: CC-BY-4.0 metadata: agent: requirements-recorder agent-version: "1" --- # Read back and version the record ## What it does Reads the record back to the buyer for confirmation, versions it with the earlier versions still readable, and hands that one version to shaping. The record does not go forward as confirmed on silence. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Hand the Record to Shaping** - `ref/sls/record-the-requirements`, activity 12 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Read the Record Back** - `ref/sls/record-the-requirements`, activity 10 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Version the Record** - `ref/sls/record-the-requirements`, activity 11 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) ## What to record One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked. The needs-and-wants split, with who drew the line. The contradictions found, and what came back when each went to the buyer. The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion. The requirements marked as unmeetable, each with its reason and the date it was marked. The read-back and the buyer's confirmation. The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly. The mapping of shape to record, showing each requirement met, deferred or refused. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/take-in-the-discovery-notes/SKILL.mdTakes the confirmed discovery notes in as the one source the record is written from, so what goes down is what the buyer said and not what was hoped for. Use it when running `ref/sls/record-the-requirements` and `ref/sls/run-a-discovery-call`.
--- name: take-in-the-discovery-notes description: Takes the confirmed discovery notes in as the one source the record is written from, so what goes down is what the buyer said and not what was hoped for. Use it when running `ref/sls/record-the-requirements` and `ref/sls/run-a-discovery-call`. license: CC-BY-4.0 metadata: agent: requirements-recorder agent-version: "1" --- # Take in the discovery notes ## What it does Takes the confirmed discovery notes in as the one source the record is written from, so what goes down is what the buyer said and not what was hoped for. ## Where it happens The agent does this in two activities across two reference processes. Each one names the activity as that process words it. - **Hand the Notes On** - `ref/sls/run-a-discovery-call`, activity 13 - [Run a Discovery Call](../../../../processes/sales/run-a-discovery-call.md) - **Take in the Discovery Notes** - `ref/sls/record-the-requirements`, activity 1 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) ## What to record One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked. The needs-and-wants split, with who drew the line. The contradictions found, and what came back when each went to the buyer. The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion. The requirements marked as unmeetable, each with its reason and the date it was marked. The read-back and the buyer's confirmation. The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly. The mapping of shape to record, showing each requirement met, deferred or refused. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/test-the-list-with-the-buyer/SKILL.mdFinds the pairs that cannot both be met and puts them back to the buyer rather than settling them on the buyer's behalf. Use it when running `ref/sls/record-the-requirements`.
--- name: test-the-list-with-the-buyer description: Finds the pairs that cannot both be met and puts them back to the buyer rather than settling them on the buyer's behalf. Use it when running `ref/sls/record-the-requirements`. license: CC-BY-4.0 metadata: agent: requirements-recorder agent-version: "1" --- # Test the list with the buyer ## What it does Finds the pairs that cannot both be met and puts them back to the buyer rather than settling them on the buyer's behalf. Has the buyer rank the list, and marks the requirements that cannot be met, each with its reason, before any shape is drawn. ## Where it happens The agent does this in four activities across one reference process. Each one names the activity as that process words it. - **Ask the Follow-Up Questions** - `ref/sls/record-the-requirements`, activity 6 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Find the Contradictions** - `ref/sls/record-the-requirements`, activity 5 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Have the Buyer Rank the List** - `ref/sls/record-the-requirements`, activity 8 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Mark What Cannot Be Met** - `ref/sls/record-the-requirements`, activity 9 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) ## What to record One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked. The needs-and-wants split, with who drew the line. The contradictions found, and what came back when each went to the buyer. The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion. The requirements marked as unmeetable, each with its reason and the date it was marked. The read-back and the buyer's confirmation. The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly. The mapping of shape to record, showing each requirement met, deferred or refused. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/watch-what-changes-after-the-handover/SKILL.mdWatches for the requirements that arrive after confirmation, and versions each one in rather than absorbing it quietly. Use it when running `ref/sls/record-the-requirements`, `ref/sls/run-a-proof-of-value` and `ref/sls/shape-the-solution`.
--- name: watch-what-changes-after-the-handover description: Watches for the requirements that arrive after confirmation, and versions each one in rather than absorbing it quietly. Use it when running `ref/sls/record-the-requirements`, `ref/sls/run-a-proof-of-value` and `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: requirements-recorder agent-version: "1" --- # Watch what changes after the handover ## What it does Watches for the requirements that arrive after confirmation, and versions each one in rather than absorbing it quietly. Reads the shape back against the record line by line, showing each requirement met, deferred or refused, and records what a trial and the run itself taught. ## Where it happens The agent does this in four activities across three reference processes. Each one names the activity as that process words it. - **Map the Shape to the Requirements** - `ref/sls/shape-the-solution`, activity 10 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Record What Was Learned** - `ref/sls/record-the-requirements`, activity 14 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Record the Result and What It Taught** - `ref/sls/run-a-proof-of-value`, activity 15 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Watch for Drift While Shaping** - `ref/sls/record-the-requirements`, activity 13 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) ## What to record One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked. The needs-and-wants split, with who drew the line. The contradictions found, and what came back when each went to the buyer. The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion. The requirements marked as unmeetable, each with its reason and the date it was marked. The read-back and the buyer's confirmation. The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly. The mapping of shape to record, showing each requirement met, deferred or refused. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
skills/write-each-requirement-down/SKILL.mdSplits what must be true from what was only wanted, and writes one line per requirement in the buyer's own words, with any paraphrase marked as a paraphrase. Use it when running `ref/sls/record-the-requirements`.
--- name: write-each-requirement-down description: Splits what must be true from what was only wanted, and writes one line per requirement in the buyer's own words, with any paraphrase marked as a paraphrase. Use it when running `ref/sls/record-the-requirements`. license: CC-BY-4.0 metadata: agent: requirements-recorder agent-version: "1" --- # Write each requirement down ## What it does Splits what must be true from what was only wanted, and writes one line per requirement in the buyer's own words, with any paraphrase marked as a paraphrase. Names the person who asked for each one and the date they asked. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Name Who Asked for Each One** - `ref/sls/record-the-requirements`, activity 4 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Split the Needs from the Wants** - `ref/sls/record-the-requirements`, activity 2 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Write Each One in the Buyer's Words** - `ref/sls/record-the-requirements`, activity 3 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) ## What to record One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked. The needs-and-wants split, with who drew the line. The contradictions found, and what came back when each went to the buyer. The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion. The requirements marked as unmeetable, each with its reason and the date it was marked. The read-back and the buyer's confirmation. The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly. The mapping of shape to record, showing each requirement met, deferred or refused. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
mcp.jsonNot in the package.
Every server entry in an mcp.json needs either a command to run or a url to connect to, and the package cannot know either of those until somebody points it at their own systems. So the file is left out, the systems the agent needs are named by role in plugin.json, and you write the mcp.json when you set it up.
Setting it up
Point it at your systems
To run an agent built from this package, write an mcp.json that says which of your systems fills each role. The package names these 4 roles, and the access level beside each one is the most the work needs.
requirement-record · writecrm · writenotes-store · readpolicy-register-and-the-product-roadmap · read
mcp.json
You write this file. It is not part of the package.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"requirement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/requirement-record"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"notes-store": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/notes-store"
},
"policy-register-and-the-product-roadmap": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/policy-register-and-the-product-roadmap"
}
}
}
The hostnames here are a placeholder for your own. Whichever product holds each of these systems, the agent you build is yours and nobody else has to be involved in running it.
Where it works
4 processes, 16 activities
The highlighted activities are the ones this abstract agent does. The other activities in each process belong to other abstract agents or to people.
Record the Requirementsref/sls/record-the-requirements · 14 activities
Take in the Discovery Notes · Split the Needs from the Wants · Write Each One in the Buyer's Words · Name Who Asked for Each One · Find the Contradictions · Ask the Follow-Up Questions · Have the Buyer Rank the List · Mark What Cannot Be Met · Read the Record Back · Version the Record · Hand the Record to Shaping · Watch for Drift While Shaping · Record What Was Learned
Run a Discovery Callref/sls/run-a-discovery-call · 14 activities
Hand the Notes On
Run a Proof of Valueref/sls/run-a-proof-of-value · 15 activities
Record the Result and What It Taught
Shape the Solutionref/sls/shape-the-solution · 15 activities
Map the Shape to the Requirements
The records it leaves
What it writes down
One line per requirement, quoted in the buyer's words, with any paraphrase marked as a paraphrase, the person who asked for it, and the date they asked. The needs-and-wants split, with who drew the line. The contradictions found, and what came back when each went to the buyer. The buyer's ranking, recorded as the buyer's, with any seller re-ranking kept beside it as a separate marked opinion. The requirements marked as unmeetable, each with its reason and the date it was marked. The read-back and the buyer's confirmation. The version number and its date, with earlier versions still readable, and every later requirement written, attributed and versioned in rather than absorbed quietly. The mapping of shape to record, showing each requirement met, deferred or refused.
Where it stops
What it will not do
Does not interview the buyer, which is the discovery-interviewer agent, and does not decide what would fix the problem, which is the solution-architect agent. Does not settle a contradiction on the buyer's behalf and does not pick a side between two people in the account. Does not re-rank the buyer's list in place.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
Agents built from this plugin
Who has built one, and how far each one got
Nobody has built one yet. The catalog says so rather than leaving the section off, because an empty list is a fact about the document.
declare it
implements: requirements-recorder v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
A guess, not a claim
The closest things in the catalog, by description
Nobody above has claimed any of these. This is the nearest match by wording between the job written above and what publishers wrote about their own listings, closest first, and wording is not evidence: some of these will be wrong, and a job with nothing suitable still gets whatever was nearest. The publishers have never heard of this abstract agent and have promised nothing about it. What a claim looks like is in the table above, and it is signed.
Might do the job
Things that could be the worker: an agent, a packaged product, a plugin.
- The Website Specification — A2A agent Agent · specification.website Read-only A2A agent that answers natural-language questions about The Website Specification and returns matching topics with status, canonical URL,…
Might be reached for
Not workers. These are capability that whatever does the job would use, which is a different relationship and kept in its own column for that reason.
- prd-spec-generator MCP server · cdeust.github.io · run it yourself · mirrored from the MCP registry Turns a feature description into a verified 9-file PRD — multi-judge consensus, 17 MCP tools.
- dot•requirements MCP server · dotrequirements.io · hosted · mirrored from the MCP registry Write product documentation to share with your whole team, including testable specifications.
- commonspecs MCP server · commonspecs.com · hosted · mirrored from the MCP registry Product and service specs with per-field confidence, plus dated price offers.