---
name: rfp-first-draft
description: Turn a new RFP into a full draft from your past-response library, validated section by section. Use this skill when: New RFP received — Logged against a Salesforce opportunity or dropped in the drive folder.
---

# Draft the RFP from your past answers

Goal: draft an RFP response from the past-response library and validate every section before it goes to the team.

Connected tools this skill uses: drive, notion, salesforce, slack.

## When to use

- New RFP received — Logged against a Salesforce opportunity or dropped in the drive folder.
- Or when the user asks directly to draft an RFP response from the past-response library and validate every section before it goes to the team.

## Method

Draft the RFP response for {{account}}.

1. Read {{rfp_file}} and map its sections to the standard response outline
   stored in memory.
2. For each section, search {{response_library}} for the closest past
   answer to a similar RFP. Draft an adapted response and cite the past
   deal it came from.
3. For any section with no close match, draft from {{policy_docs}} or
   {{product_docs}} only, and mark it "new content" so a human reviews it
   first.
4. Re-read every drafted section against its cited source. Flag any
   sentence that isn't backed by the library or a named source doc.
5. Compile the draft in the RFP's required format and save it to
   documents/rfps/{{account}}-{{date}}.md.
6. Post a section-by-section summary to {{delivery_channel}}: sections
   reused, sections new, sections flagged for review.

Never submit the response to the prospect or the RFP portal — it is a
draft for the proposal lead to review, edit, and submit.

## Past-response library

Reuse the closest prior RFP answer per section so no section starts from a blank page.

## Method
1. Keep the library indexed by section topic, not by individual RFP.
2. For each new section, search the library for the closest topic match from a past deal.
3. Adapt the matched answer to the new RFP's exact wording and scope — do not paste it unchanged.
4. Cite the past deal the answer came from in an inline note.
5. When no close match exists, draft from the policy docs or product docs only, and mark the section "new content."
6. After the RFP closes, add any newly written section back to the library under its topic.

## Rules
- Adapt, never paste verbatim — every reused section must fit the new RFP's exact question.
- A section with no library match is marked "new content" and reviewed by a human before it ships.
- Index the library by topic, not recency, so the search finds the closest match.
- Refresh sections older than (set on first run, then stored in memory) months before reuse.

## Output
Each section drafted with its source noted: reused-and-adapted, with the past deal cited, or new content flagged for review.

## Section validation

Check every drafted section against its cited source before the draft goes to the team.

## Method
1. Re-read each section after drafting, sentence by sentence.
2. Trace each sentence back to its source: a library answer, a policy doc, or a product doc.
3. Flag any sentence that makes a claim its cited source does not actually support.
4. Flag any sentence carrying no citation at all.
5. Leave flagged sentences in place with a visible flag — never silently delete or soften them.
6. Summarize flags by section in the delivery post: reused, new, flagged.

## Rules
- Every sentence in the draft traces to a named source or carries a flag.
- Never force-fit a citation to a sentence it does not actually support.
- New-content sections always carry at least one review flag, even if well written.
- Report flagged sections separately from reused ones so review starts in the right place.

## Output
A section-by-section validation summary: reused, new, or flagged, with the reason for each flag.

## Proposal voice

Match the team's established tone and formatting standard across every drafted section.

## Method
1. Read the standard response outline and formatting rules stored in memory.
2. Match sentence length, formality, and terminology to the team's past submitted RFPs.
3. Use the product's approved feature and plan names — never an internal codename.
4. Keep section headers and numbering in the format the RFP itself requests.
5. Run a final pass across the full draft to smooth tone gaps between reused and new sections.

## Rules
- Match the RFP's required structure exactly — section order, numbering, page limits.
- Use only approved product and company terminology, never internal shorthand.
- Keep reused and newly drafted sections indistinguishable in tone after the final pass.
- Log any team style correction as a lasting formatting rule in memory, not a one-off fix.

## Output
A fully formatted draft in the RFP's required structure, saved to documents/rfps/{{account}}-{{date}}.md.

## Recurring jobs

This skill pairs with scheduled jobs. Offer to set each one up; only create the ones the user approves:

- RFP inbox watch (Every 30 minutes on weekdays) — https://eluu.ai/cookbook/rfp-first-draft/jobs-setup/rfp-inbox-watch.md