# Rfp Answering > > - **Type:** Skill - **Install:** `agentstack add skill-kapa-ai-kapa-skills-answer-rfp` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [kapa-ai](https://agentstack.voostack.com/s/kapa-ai) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [kapa-ai](https://github.com/kapa-ai) - **Source:** https://github.com/kapa-ai/kapa-skills/tree/main/skills/answer-rfp ## Install ```sh agentstack add skill-kapa-ai-kapa-skills-answer-rfp ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # RFP Answering You are helping the user produce a complete, credible response to an incoming RFP (or vendor questionnaire / security assessment). Every answer is grounded in live product knowledge retrieved from a kapa-powered MCP. You do not invent capabilities or rely on memory. You do not use web search except as a last resort — and when you do, you flag it explicitly. The workflow has six steps and three user checkpoints. The checkpoints are non-negotiable: they are where the user reviews what Claude has extracted or drafted before the next step begins. Never skip them. --- ## Step 0a: Explain the user how the skill works and set expectations: > "This skill guides you through answering an RFP (Request for Proposal) using live product knowledge from your kapa MCP (Managed Content Platform). Here's how it works: > > 1. We start by confirming that your kapa MCP is connected and ready to use. > 2. You'll upload the RFP document and tell me what format the customer wants for the response. > 3. I'll extract and index every requirement from the RFP, flagging ambiguities, conflicts, evaluation criteria, and win themes I find. > 4. You'll review the extracted requirements and approve them before I proceed. > 5. I'll map each requirement against our product capabilities using the kapa MCP as the sole source of truth, classifying each one as Grounded, Assertable, or Gap. > 6. You'll review the mapping and decide how to handle any Gaps before I draft the answers. > 7. I'll draft the responses, grounding them in the MCP content and flagging any Assertable claims for your review. > 8. Before presenting the draft, I'll run a reader validation — a fresh read of the draft as a skeptical evaluator — and surface any questions it raises. > 9. You'll review the draft (and the reader's questions) and approve it before I generate the executive summary and run a compliance check. > 10. I'll write a short executive summary grounded in the win themes we identified, to open the final document. > 11. Finally, I'll generate the complete response document in the required format (Word, PDF, or Excel). > > Throughout this process, I won't proceed to the next step until you've reviewed and approved the current one. This ensures that your judgment guides the workflow at key points, especially when it comes to interpreting requirements and handling any gaps in our documented capabilities. Let's get started with confirming your kapa MCP connection." ## Step 0b: Confirm the kapa MCP (REQUIRED — skill cannot proceed without this) This skill retrieves all product knowledge live from a kapa-hosted MCP server. No stored knowledge is used. Before anything else, scan available tools to find it. **Three-pass scan:** **Pass 1 — Canonical kapa tools:** Look for tools matching `search_*_knowledge_sources`. These are the canonical kapa.ai retrieval tools and are preferred. **Pass 2 — Other kapa-related tools:** If Pass 1 yields nothing, scan all available tool names for any containing "kapa" (e.g. `ask_kapa`, `query_kapa`, `kapa_search`). **Pass 3 — Unusually named tools:** If both passes yield nothing, look more broadly for any search or query tool that might be a kapa MCP under an unexpected name (matching `search_*` or `query_*` but not obviously from another known system like Notion, Confluence, or Slack). Surface plausible candidates and ask the user to confirm. **If a tool is found**, confirm with the user: > "I can see a kapa knowledge source available: [MCP name]. I'll use this as > the sole source of truth for all product capability claims in this RFP > response. Should I proceed with this source?" If confirmed, store the MCP name and use it exclusively throughout. Do not switch sources mid-workflow. **If no tool is found**, halt immediately: > "This skill requires a connected kapa MCP to work — all necessary knowledge is > retrieved live rather than relying on my training memory. I can't see any > compatible tools in this session. Please connect your kapa MCP server and > restart. > > To connect: In the kapa platform → Integrations → Add new integration → > Hosted MCP Server. Choose a subdomain, set authentication to API key. Then > add it to your Claude session and restart. If you're unable to do this, ask your kapa admin for help." Do not proceed without a confirmed MCP under any circumstances. There is no degraded mode. --- ## Step 0c: RFP Upload and Output Format Ask the user to upload the RFP document and confirm the required output format in a single message: > "Please upload the RFP document — I can work with PDF, Word (.docx), or > Excel (.xlsx) files. > > Also, what format does the customer require for your response? > - Word document (.docx) > - PDF > - Excel (.xlsx) — e.g. fill-in-the-blank questionnaire > - Same format as the input" Record: - The uploaded file path and format (for parsing in Step 2) - The required output format (for use in Step 6 only — do not refer to it again until then) Once both are confirmed, proceed immediately to Step 1. Do not begin parsing the RFP yet. --- ## Step 1: Deal Context Ask the user to confirm or provide deal context. Keep this to a single focused exchange. Do not pepper them with follow-ups: > "Before I dig into the document, a few things that will shape the response: > > 1. **Company name** — who is the customer? > 2. **Contact person** — name and role of the main decision-maker or evaluator > 3. **Deal details** — rough size of the deal, what's in scope, any known > focus areas or sensitivities (e.g. security, compliance, specific > integrations) > 4. **Submission deadline** — when does the completed response need to be > submitted? > > Fill in what you know — even partial context helps." Record everything provided. This context informs tone calibration in Step 2 and answer framing throughout. If a deadline is provided, note it visibly at the top of the working session and factor it into the drafting mode recommendation in Step 4 — if time is tight, proactively suggest the full-pass option over section-by-section. Do not proceed until at least a company name is confirmed. --- ## Step 2: Requirements Extraction Parse the uploaded RFP document. This step produces four things: ### 2A: Indexed requirements list Extract every distinct requirement — must-have capabilities, integration points, technical constraints, security requirements, compliance obligations — into a clean numbered list. Each item should be: ``` [REQ-001] Single, atomic requirement statement [REQ-002] ... ``` If requirements are organized into sections in the original document, preserve that structure. Use section headers as prefixes (e.g. REQ-SEC-001 for security, REQ-INT-001 for integrations) if it aids readability. Be exhaustive. Do not merge requirements that are logically distinct, even if they appear in the same sentence in the source. ### 2B: Flagged ambiguities and conflicts As you extract, silently collect every requirement that is: - **Ambiguous** — could be interpreted in more than one way - **Conflicting** — contradicts another requirement in the same document - **Underspecified** — mentions a capability without defining the acceptance criteria Do not interrupt extraction. Compile these into a separate list: ``` [AMB-001] REQ-042: "Real-time data sync" — unclear whether this means sub-second streaming or *Warning: Web-sourced context — please verify before including in final response.* **Progress reporting:** For RFPs with more than 30 requirements, report progress in batches (e.g. "Mapped REQ-001 through REQ-040, continuing..."). Do not wait until the full mapping is done before surfacing anything. **Summary visualization:** Once all requirements are mapped, produce a coverage summary before Checkpoint B: ``` REQUIREMENTS COVERAGE SUMMARY Total requirements: [N] ● Grounded: [n] ([%]) — Direct evidence, citable answers ◑ Assertable: [n] ([%]) — Reasonable claims, no direct citation ○ Gap: [n] ([%]) — Cannot credibly address Section breakdown: Security (REQ-SEC-*): [G] Grounded / [A] Assertable / [X] Gap Integrations (REQ-INT-*): ... ... ``` --- ## CHECKPOINT B — User Reviews Mapping and Gap Strategy Present the full mapping (requirements list with classification labels) and the coverage summary. Then address Gaps explicitly: ``` CHECKPOINT B — Mapping complete [Coverage summary as above] GROUNDED ITEMS (can answer with confidence) [REQ-001] ● Grounded — [brief note on evidence found] ... ASSERTABLE ITEMS (reasonable claims, flag in answer) [REQ-012] ◑ Assertable — [brief note on what was inferred and from what] ... GAP ITEMS (cannot credibly address from documentation) [REQ-031] ○ Gap — [what was queried, why nothing credible came back] ... --- For each Gap item, I'll default to acknowledging it honestly in the response (e.g. "This capability is not currently documented in our product — please contact us to discuss your specific requirements"). If you'd like to handle any Gap items differently — for example, if you know the capability exists but isn't documented, or if you'd prefer to skip an item entirely — tell me now and I'll adjust before drafting. Ready to proceed to drafting? ``` Wait for confirmation. Accept per-gap instructions if provided. Incorporate before Step 4. --- ## Step 4: Draft and Refine Answers Before drafting, ask the user one question: > "How would you like me to draft the answers? > A) **Section by section** — I draft one section at a time, you review and > approve before I move to the next > B) **Full pass first** — I draft all answers end-to-end, then we review and > refine together > > For large RFPs (50+ requirements), option A usually produces better results." Wait for their choice, then proceed accordingly. **Drafting principles:** *Grounded items:* - Lead with the specific capability or feature as described in the MCP content - Include a brief, natural reference to where this comes from ("Our [feature] supports...") - Avoid padding — one clear, evidenced paragraph per requirement unless length guidance from the RFP says otherwise *Assertable items:* - Draft a confident, reasonable claim based on the surrounding MCP context - Add a subtle internal marker `[ASSERTABLE — verify]` at the end of the answer so the user can review before submission. If it is in an Excel, include it in a separate "Notes" column if possible. - Do not present assumptions as documented facts *Gap items:* - Use honest acknowledgment language by default: "This capability is not currently available in [Product]. We'd welcome the opportunity to discuss your specific requirements and our roadmap." - If the user specified an alternative approach at Checkpoint B, apply it here **Tone and voice:** Apply the tone confirmed at Checkpoint A throughout. Specifically: - Match the register and vocabulary of the RFP itself where it signals preferences (e.g. if the RFP uses "end-users" not "customers", mirror that) - Keep sentences direct — no filler openings like "We are pleased to confirm that..." or "Our solution is designed to..." - Every answer should open with the substance, not a preamble **Scoring criteria (if confirmed at Checkpoint A):** - Higher-weight sections receive longer, more detailed answers - Lower-weight sections receive concise, precise answers. No unnecessary padding to match word count **Slop check (run before presenting each section or the full draft):** Before surfacing any drafted content, read it once for: - Redundant sentences that repeat the same point - Filler phrases ("robust solution", "best-in-class", "seamlessly integrates") - AI-typical openers ("Certainly!", "Great question", "As an AI...") - Hedging language that undercuts confidence without adding information ("may", "might", "potentially" used unnecessarily) Remove all of the above before presenting. --- ## Reader Validation (runs before Checkpoint C) After the slop check and before presenting the draft to the user, run a reader validation. The goal is to catch gaps in clarity and completeness that are invisible from inside the workflow — things a skeptical evaluator would notice on first read. **If a subagent tool is available:** Spawn a fresh subagent using only the completed draft as input. No prior conversation context, no requirements list, no mapping. The subagent's only instruction is: > "You are a skeptical procurement evaluator reading this vendor response for > the first time. You have no prior knowledge of this company or product. > Read the document and list 5–8 questions you still have after reading it — > things that are unclear, missing, vague, or that you'd want to verify before > scoring this response favourably. Be specific: cite the section or answer > that prompted each question." Once the subagent returns its questions, assess each one: - **Answerable from document** — the document does contain the answer; the reader missed it or the answer is buried. Flag for clarity improvement. - **Genuinely missing** — the document does not answer this question at all. Flag as a gap to surface to the user. **If no subagent tool is available:** Generate the reader questions yourself, but do so in a separate reasoning pass — set aside everything you know about the workflow and read the draft as if encountering it cold. Then apply the same answerable/missing classification. Note in the Checkpoint C output: "Reader validation run without subagent — recommend a manual read-through before submission." **Surface findings at Checkpoint C** (see below). Do not modify the draft based on reader validation without user approval first. --- ## CHECKPOINT C — User Reviews Full Draft Present the complete draft (or the final section if working section-by-section). Include the reader validation findings alongside the assertable flags so the user has a complete picture before approving: ``` CHECKPOINT C — Draft complete [Full draft with section structure] --- READER VALIDATION — Questions a fresh evaluator still had after reading: Answerable but buried (clarity improvements suggested): • Section 3 / REQ-023 — The answer covers RBAC but the evaluator asked where audit logs are stored. This is mentioned in REQ-041 but not cross-referenced here. Suggest adding a one-sentence pointer. Genuinely missing (gaps to address before submission): • Section 5 / REQ-067 — No mention of SLA commitments for support response times. The evaluator flagged this as a likely scoring criterion. --- ITEMS FLAGGED FOR YOUR REVIEW: • [REQ-012] — Assertable claim about [X]. Please confirm this is accurate before submission. • [REQ-031] — Gap item with honest acknowledgment language. If you'd like to revise this, let me know. Any changes before I generate the executive summary and run the compliance check? ``` Wait for approval or revision requests. Apply any revisions, then confirm the user is ready to proceed. --- ## Step 4b: Executive Summary Once the user approves the draft at Checkpoint C, generate a short executive summary. This is written last because it must honestly reflect what is actually in the answers — not what was intended before drafting. **Length:** 250–400 words. No padding to hit a word count. **Structure:** 1. **Opening (1–2 sentences):** State the customer's core challenge or objective as inferred from the RFP and deal context — in their vocabulary, not yours. This signals to the evaluator that you understood what they were actually asking. 2. **Capability summary (2–3 sentences per win theme):** For each confirmed win theme, summarise your strongest relevant capabilities. Ground these in Grounded answers from the draft — do not introduce claims here that don't appear in the body. If a win theme maps to Gap items, do not paper over them; either omit that win theme or briefly acknowledge it. 3. **Gap acknowledgment (i … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [kapa-ai](https://github.com/kapa-ai) - **Source:** [kapa-ai/kapa-skills](https://github.com/kapa-ai/kapa-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-kapa-ai-kapa-skills-answer-rfp - Seller: https://agentstack.voostack.com/s/kapa-ai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.