What it does
This skill takes a questionnaire and your approved answer library and drafts the response the way a careful proposal manager would if they had nine days and no other job: one answer per question, in the buyer's numbering, each carrying the library entry or document section it came from and the date someone last checked it. It is an rfp response template in the practical sense, the structure every answer follows, rather than a Word document with blanks. The job it replaces is the ritual of opening the last RFP, copying answers written for a different buyer, and hoping the security section is still true. The skill reads the library first, the approved documents second, and stops there. Anything it cannot source becomes a named exception for a human instead of a plausible paragraph.
The difference between a good and a bad version of this comes down to one behavior: what happens when the source is missing. A bad version fills the gap with fluent, reasonable-sounding text, and that text gets pasted into a portal, and six months later a customer's auditor asks where the SCIM support went. A good version writes NEEDS A HUMAN, names the owner, and says in one sentence what the answer has to establish. The second behavior feels slower on the day and is the whole reason a legal or security team will let a model near a questionnaire at all. The skill also tags freshness: an answer whose source is past its verification window ships in the draft, but flagged, so the reviewer sees exactly which nine answers need a phone call.
It beats the manual method in three places. Speed on the boring 80 percent: the questions the library already answers come back in under an hour, in the buyer's form, so the AE's nine days go to the twenty questions that need a person. Consistency: every answer follows the same two-to-five-sentence shape with no adjectives, so the response reads like one company wrote it instead of four teams over three years. And compounding: the skill proposes a library entry for every new or improved answer, so the library gets better with each RFP instead of decaying. A team that runs it on a security portal the week after an RFP typically finds most of the answers are reuse.
Where it does not help. It cannot verify anything; it reports what the library and documents say and when they were last checked, and a stale library produces a stale draft with honest flags. It does not negotiate: when a buyer asks for a 99.99 percent SLA and the approved answer is 99.9, the skill states the approved figure and routes the conflict to Legal rather than splitting the difference. And it is not a knowledge base builder. If you have no library yet, start with the paired use case, which walks through building the answer library from your last three RFPs and the security documents, then bring the skill in to run against it.
The RFP response template for one library entry
The skill only drafts from entries shaped like this. Copy it once per canonical question into a Notion database or a spreadsheet, or paste it as the format instruction and let the skill propose new entries in the same shape after every RFP. The fields that matter are the ones people skip: scope notes, the verification window, and the source list.
ANSWER LIBRARY ENTRY, {{LIB-000}}
CANONICAL QUESTION
{{One sentence, phrased the way buyers ask it. One real question per entry.}}
ALSO ASKED AS
- {{variant wording 1}}
- {{variant wording 2}}
APPROVED ANSWER
{{Two to five plain sentences. First person plural. No adjectives about the product. Every number, certification, region, and integration in this answer appears in a source below.}}
SCOPE NOTES (what this answer does NOT cover)
- {{e.g. covers EU hosting, not EU-only data residency}}
SOURCES
- {{document, section, or URL}}
- {{document, section, or URL}}
OWNER: {{name, function}}
LAST VERIFIED: {{YYYY-MM-DD}} WINDOW: {{90 / 180 / 365 days}}
STATUS: {{Approved / Proposed / Stale / Retired}}
USED IN: {{RFP or portal name, date}} / {{...}}
An entry with no LAST VERIFIED date is a rumor. The skill treats a missing date as stale and flags it, which is the right default: the cost of a wrong security answer is the deal, the cost of a flag is one Slack message to the owner.
Inputs & outputs
Inputs
- The questionnaire, with the buyer's numbering intact (required): pasted text, a spreadsheet export, or a file
- The answer library (required): entries with canonical question, approved answer, sources, owner, last-verified date, status
- Approved documents you name explicitly: security overview, architecture doc, product docs, DPA, SLA
- Optional: buyer context such as industry, region, deployment under evaluation, and any non-standard terms already agreed
- Optional: your own verification windows by answer type, if they differ from the defaults (90 / 180 / 365 days)
Outputs
- A summary block first: counts by status, exceptions grouped by owner, stale answers, and any buyer asks that conflict with approved terms
- One answer per question in the buyer's exact numbering and wording, each tagged SOURCED or STALE with the entry id or document section and the verified date
- NEEDS A HUMAN exceptions with a suggested owner (Security, Legal, Product, Finance, IT) and a one-line note on what the answer must establish
- Proposed library entries for every new or improved answer, in the entry template shape, status Proposed
- A reuse count on repeat runs, so you can see how much of a security portal the library already covered
How to set it up
Decide where the skill lives
Two options. (1) For a team that answers a questionnaire a month, create a Claude Project named "RFP Responder", paste the SKILL.md body below into its custom instructions, and add the answer library export plus the approved documents to the Project's knowledge. Every RFP is then a new chat with the questionnaire attached. (2) For a team running a portal a week, save the content as skills/rfp-responder/SKILL.md for Claude Code, keep the library as a CSV or a Notion database Claude can read over MCP, and run it from the terminal so the draft lands as a file in the buyer's format. Both paths use the same rules; the Code path is the one that scales to writing proposed entries back to the library automatically.
Name the approved sources, and nothing else
The skill treats only the documents you name as approved. Attach the security overview, the architecture doc, the current DPA and SLA, and the product docs you would hand a customer today. Do not attach old RFPs as sources; those are exactly the stale, buyer-specific answers the library exists to replace. If a document is in the folder but not on the approved list, the skill will not draft from it, which is the behavior you want when someone drops last year's deck in the wrong place.
Use the RFP response template shape for every library entry
The skill matches on meaning, so entries need a canonical question and the variant wordings buyers use, plus scope notes for what the answer does not cover. Entries missing a last-verified date are treated as stale. Before the first run, spend an hour tagging owners and dates on your top fifty entries; the skill will surface the rest as stale on the first draft, which doubles as a library audit you would never otherwise schedule.
Run it the day the RFP lands, then work the exceptions list
Send: "Run rfp-responder on the attached questionnaire for Northwind Freight, region EU, evaluating the Enterprise plan." Read the summary block first: the exception count tells you how many humans you need and which ones. Post the exceptions by owner in Slack the same afternoon so Security and Legal have the full nine days, not the last two. When the answers come back, paste them into the chat and ask the skill to fold them into the draft and finalize the proposed entries. Then approve the proposed entries into the library, because that step is what makes the next RFP faster.
The SKILL.md
Save this as SKILL.md in a folder named rfp-responder, or paste the body into a Claude Project's custom instructions. Attach the questionnaire and the answer library, name the approved documents, and run it.
---
name: rfp-responder
description: Use when an RFP, RFI, security questionnaire, or vendor portal lands and answers must come from approved sources only. Drafts every answer from the answer library or approved docs with a source and last-verified date, marks unsourced questions Needs a human with an owner, and proposes new library entries. Never invents a capability, certification, or number.
---
# RFP Responder
You draft questionnaire answers for a B2B sales team. Every answer must trace to an approved library entry or a passage in an approved document. No source, no answer; it becomes an exception for a human.
## Inputs
- The questionnaire (required), with the buyer's numbering intact.
- The answer library (required): canonical question, approved answer, sources, owner, last-verified date, status.
- Approved documents (optional). Only documents the user names are approved.
- Buyer context (optional): industry, region, plan under evaluation, agreed non-standard terms.
## Method
1. Parse into one row per question. Keep the buyer's numbering and wording exactly; never merge or reorder.
2. Search the library first, matching on meaning. Draft from the matching entry; if several apply, combine and cite each.
3. If no entry matches, search the approved documents and paraphrase closely, citing document and section.
4. If neither answers it, write NEEDS A HUMAN, suggest an owner (Security, Legal, Product, Finance, IT), and state in one sentence what the answer must establish. Never draft a guess.
5. Adapt to buyer context only where a source supports it. Never promise a feature, region, certification, integration, or SLA figure that is not in a source.
6. Check freshness: security/compliance 90 days, product/integrations 180, company facts 365, or the user's windows. Past the window, keep the answer but mark STALE.
7. Propose library entries for every new or improved answer, status Proposed.
8. Write the summary first: counts by status, exceptions by owner, stale answers, conflicts with approved terms.
## Hard rules
- "We support", "we are certified", "we comply", and any number appear only when a cited source says so.
- Cite an entry id or document section on every answer.
- Plain answers, two to five sentences, no adjectives about the product.
- A fact read from a source is Confirmed. Anything reasoned is Inferred and belongs in an exception note, never in an answer.
## Output template
**RFP Draft: <Buyer>, <today's date>**
Sources: <library and export date; documents read>
**Summary**
- Questions: <n>. Sourced <n>. Stale <n>. Needs a human <n>.
- Exceptions by owner: <function> <n>, ...
- Conflicts with approved terms: <list or none>
**Answers** (buyer's numbering)
<#> <question as written>
Answer: <draft>
Source: <entry id or document, section> | Verified: <date> | Status: SOURCED / STALE
<#> <question as written>
Answer: NEEDS A HUMAN
Owner: <function> | Note: <what the answer must establish>
**Proposed library entries**
- Q: <canonical question> | A: <draft> | Sources: <...> | Status: Proposed
Run it from the terminal
Example run
An AE runs the skill on a 184-question logistics RFP the afternoon it lands, with a library of 212 approved entries and three named documents.
Prompt: rfp-responder. Buyer: Northwind Freight, EU, evaluating Enterprise. Questionnaire attached (184 questions, buyer numbering). Library: answer-library.csv. Approved docs: security-overview-v7.pdf, architecture.md, sla.md.
Output:
RFP Draft: Northwind Freight, 2026-09-08
Sources: answer-library.csv (exported 2026-09-08, 212 entries); security-overview-v7.pdf; architecture.md
Summary
- Questions: 184 total. Sourced 151. Stale 9. Needs a human 24.
- Exceptions by owner: Security 11, Legal 6, Product 4, Finance 2, IT 1.
- Conflicts with approved terms: 2 (Q 7.3 asks for a 99.99% SLA; approved SLA is 99.9%. Q 9.1 asks for EU-only data residency; library covers EU hosting, not residency guarantee).
Answers (buyer's numbering)
2.4 Describe how customer data is encrypted at rest and in transit.
Answer: Data at rest is encrypted with AES-256 using provider-managed keys, rotated annually. Data in transit uses TLS 1.2 or higher. Customer-managed keys are available on the Enterprise plan.
Source: LIB-041 | Verified: 2026-07-14 | Status: SOURCED
2.9 Provide your most recent penetration test summary and remediation status.
Answer: An independent penetration test is performed annually by a third party. The most recent summary and remediation status are provided under NDA on request.
Source: LIB-058 | Verified: 2026-04-02 | Status: STALE (security window 90 days)
5.2 Does the platform support SCIM provisioning for Okta?
Answer: NEEDS A HUMAN
Owner: Product | Note: Library covers SAML SSO with Okta (LIB-102) but has no entry on SCIM. Confirm whether SCIM is generally available or roadmap, and the plan it ships on.
7.3 Confirm a 99.99% uptime SLA with service credits.
Answer: Our standard SLA is 99.9% monthly uptime with service credits as defined in the Service Level Agreement.
Source: sla.md, section 2 | Verified: 2026-08-20 | Status: SOURCED
Flag: buyer requested 99.99%; conflict routed to Legal.
Proposed library entries
- Q: Does the platform support SCIM user provisioning? | A: (pending Product) | Sources: none yet | Status: Proposed
- Q: Where is the security overview document's current version? | A: (fold into LIB-058 on re-verify) | Status: Proposed
Related plays
- AI RFP Response with Provenance: A Claude Answer Library That Cites Its Sources →The full build: how to assemble the answer library this skill reads from, and the agent that writes new entries back.
- Security Questionnaire Template →The security-portal cousin of the RFP; same rule, every answer sourced.
- Claude + Notion integration guide →Keeping the answer library in a Notion database Claude reads over MCP.
- Claude Projects: persistent, context-rich workspaces →The lightest way to host the library and the skill for a small team.