85 lines
2.4 KiB
Markdown
85 lines
2.4 KiB
Markdown
---
|
|
name: proposal-rfp-writer
|
|
description: Create structured, client-ready proposal and RFP response drafts that map requirements to solutions, differentiate clearly, and stay easy for evaluators to review. Use this whenever users ask to respond to an RFP, RFQ, bid request, tender, vendor questionnaire, procurement questionnaire, 提案書, bid response, or tender response; use it for evaluator-facing requirement mapping, not for quotes, SOWs, or delivery acceptance terms.
|
|
---
|
|
|
|
# Proposal RFP Writer
|
|
|
|
## Overview
|
|
|
|
Draft proposal and RFP response content that is organized, requirement-aware, and easy for evaluators to review.
|
|
|
|
This skill is for:
|
|
- Formal RFP responses
|
|
- Proposal outlines
|
|
- Requirement-by-requirement answers
|
|
- Executive summaries for bids
|
|
- Differentiation and win-theme drafting
|
|
|
|
## Triggering Cues
|
|
|
|
Use this skill when user messages include:
|
|
|
|
- write an RFP response
|
|
- draft a proposal
|
|
- respond to bid requirements
|
|
- tender submission draft
|
|
- requirement mapping
|
|
- procurement response
|
|
|
|
## Input Requirements
|
|
|
|
Ask for or infer:
|
|
|
|
1. Client request or requirement list
|
|
2. Product/service scope
|
|
3. Key differentiators
|
|
4. Constraints, assumptions, or exclusions
|
|
5. Desired tone and level of formality
|
|
|
|
## Output Format
|
|
|
|
Always output:
|
|
|
|
1. **Executive Summary**
|
|
2. **Requirement-to-Solution Mapping**
|
|
3. **Delivery Approach**
|
|
4. **Differentiators**
|
|
5. **Assumptions and Risks**
|
|
6. **Next-Step Ask**
|
|
|
|
## Workflow
|
|
|
|
1. Extract explicit requirements first.
|
|
2. Group them into a clear response structure.
|
|
3. Map each requirement to a concrete capability or approach.
|
|
4. Highlight differentiators without overclaiming.
|
|
5. Surface assumptions, dependencies, and open questions clearly.
|
|
|
|
## Examples
|
|
|
|
### Example 1
|
|
Input:
|
|
- A client asks for a proposal for multilingual customer support automation across three regions.
|
|
|
|
Output style:
|
|
- Structured for procurement review
|
|
- Clear requirement mapping
|
|
- Strong but credible differentiation
|
|
|
|
### Example 2
|
|
Input:
|
|
- We need to answer a vendor questionnaire with product fit, implementation plan, and support model.
|
|
|
|
Output style:
|
|
- Crisp sectioning
|
|
- Explicit assumptions and scope boundaries
|
|
- Reviewer-friendly wording
|
|
|
|
## Guidelines
|
|
|
|
- Prioritize clarity over marketing language.
|
|
- Answer what was asked before adding extra value points.
|
|
- Flag unknowns and assumptions explicitly.
|
|
- Do not fabricate certifications, case studies, or guarantees.
|