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
Use the docx skill (/mnt/skills/public/docx/SKILL.md) to produce a professional Word document. RFPs should be delivered as .docx files because:
- They are the industry standard for procurement documents
- Vendors need to be able to reference specific sections
- Internal stakeholders need to review and comment using tracked changes
Document formatting guidelines:
- Include a cover page with project name, issuing organization, date, and confidentiality notice
- Include a table of contents
- Use numbered sections (1, 1.1, 1.1.1) for precise cross-referencing
- 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
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
- Always produce the RFP as a .docx file using the docx skill
- 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.mdis a superset — not every section is needed for every RFP. Use judgment to include only relevant sections.