Agent Skills: RFP (Request for Proposal) Creator

RFP (Request for Proposal) Creator

Overview

This skill guides the creation of professional, comprehensive RFP documents that enable vendors to produce accurate estimates and proposals. A well-crafted RFP is the foundation of successful vendor selection — incomplete or ambiguous RFPs lead to poor proposals, mismatched expectations, and project failure.

Core Principle

An RFP must contain enough information for a vendor to produce a credible estimate. Every section should be written with this goal in mind. If a vendor cannot estimate cost, timeline, or effort from the RFP alone, the document is incomplete.

Workflow

Step 1: Understand the User's Context

Before writing anything, gather the following from the user through conversation. Do not assume — ask.

Mandatory context (the RFP cannot be written without these):

• What is being procured? (system, service, product, construction, consulting, etc.)
• What is the business problem or objective?
• Who is the target audience for this RFP? (type of vendor, industry, geography)
• What is the approximate budget range? (even a rough range helps vendors propose appropriate solutions)
• What is the desired timeline? (both for RFP process and for project delivery)

Highly recommended context (the RFP will be significantly better with these):

• Current state / as-is situation (existing systems, processes, pain points)
• Volume and scale information (users, transactions, data volumes, locations)
• Integration requirements (what existing systems must the solution connect to)
• Organizational constraints (regulatory, security, technology stack preferences)

Step 2: Determine the RFP Type and Tailor the Structure

Read references/rfp-sections.md for the detailed section-by-section guidance. The core sections are universal, but emphasis varies by domain.

For IT / System RFPs, emphasize: functional requirements, non-functional requirements (performance, availability, security), integration architecture, data migration volumes, and licensing model.

For Service / Consulting RFPs, emphasize: scope of work, deliverables, team composition requirements, methodology, and success criteria.

For Construction / Physical RFPs, emphasize: specifications, site details, materials, regulatory compliance, insurance/bonds, and safety standards.

For Product / Procurement RFPs, emphasize: specifications, quantities, delivery schedule, quality standards, and warranty terms.

Step 3: Draft the RFP

Write the RFP as a Markdown document.

• Use numbered sections (1, 1.1, 1.1.1) so vendors can reference them precisely
• Use tables for structured data (requirements matrices, evaluation criteria, timeline milestones)
• Keep the language clear, unambiguous, and free of jargon unless the audience is domain-specific

If the user asks for a Word document, convert it with the docx skill, adding a cover page (project name, issuing organization, date, confidentiality notice) and a table of contents.

Step 4: Review Checklist

Before finalizing, verify the RFP against this checklist:

Estimability check — Can a vendor produce an estimate from this document?

• [ ] Scope is clearly bounded (what is in scope AND what is out of scope)
• [ ] Volume/scale information is provided (or placeholders are clearly marked as TBD)
• [ ] Timeline expectations are stated
• [ ] Budget range or constraints are communicated
• [ ] Evaluation criteria and weightings are disclosed
• [ ] Required proposal format/structure is specified

Completeness check — Are all necessary sections present?

• [ ] Company/project background provides sufficient context
• [ ] Requirements are stated as testable, unambiguous statements
• [ ] Non-functional requirements are included (for system/IT RFPs)
• [ ] Proposal submission process and timeline are clear
• [ ] Contact information for questions is provided
• [ ] Legal/contractual terms or references are included

Clarity check — Will the vendor understand what you need?

• [ ] No compound requirements (one requirement per statement)
• [ ] No undefined acronyms or internal jargon
• [ ] Assumptions are explicitly stated
• [ ] Diagrams or visuals are included where they add clarity

Section Reference

For detailed guidance on each RFP section, including what to include, common mistakes, and examples, read: references/rfp-sections.md

Important Notes

• If the user provides reference materials (existing documents, specifications, etc.), incorporate them into the appropriate sections
• If the user's input is insufficient for a complete RFP, produce a draft with clearly marked [TBD] placeholders and explain what information is still needed
• For Japanese-language RFPs, follow the same structure but adapt formatting conventions (e.g., use 「」 for emphasis, 御中 for addressing, and appropriate keigo)
• The RFP structure in references/rfp-sections.md is a superset — not every section is needed for every RFP. Use judgment to include only relevant sections.