Rfp Writing

Technical RFP Writing & Review

Review or draft technical RFP documents. Enforces clear structure, eliminates redundancy, and maintains formal plain-language style (Traditional Chinese).

Output Language

Match the language of the user's request, and apply it to all user-facing output — option labels, generated-document headings, table column names — not just prose. If the user explicitly asks for another language, that wins.

Language follows the request, not the source material. When the user writes in Chinese but the uploaded document, code, or reference is in English, output stays Chinese.

If the request is in Chinese, use Traditional Chinese (Taiwan business usage) and keep established technical terms in English.

The English in this file is structural labelling for you, not literal output. Never mirror this file's language into your response.

When to Use

Trigger only when the user's request explicitly names one of these artifacts:

• RFP (Request for Proposal) — reviewing, drafting, or section editing
• 需求規格書 / 需求規劃書 / 招標規格書 / 招標文件
• Vendor requirement specification being sent out for bidding

When NOT to Use

The following are adjacent but distinct — each has its own conventions that conflict with RFP rules:

• Migration plans, test plans, deployment plans
• Runbooks, SOPs, operational procedures
• ADR / ARB / architecture decision records
• Design docs, technical specifications (internal)
• Meeting minutes, decision memos, stakeholder pre-reads
• General technical documentation (README, onboarding, API docs)
• Vendor-side bid proposals or RFP responses (投標提案) — this skill is for the RFP issuer, not the responder

For general formal Chinese writing discipline (avoiding AI-isms), invoke humanizer-zh instead. That skill applies broadly; this one does not.

Review Checklist

Audit the document in this order. Fix issues top-down: structural problems first, then language.

1. Section Placement

Each section must sit under the parent that owns its concern. Common misplacements:

Action: If a section's content belongs to 2+ other sections, it should not exist as a standalone section. Split and merge into the correct owners.

2. Redundancy Elimination

Before writing any requirement, check if it is already covered elsewhere:

• Cross-cutting concerns (signing, scanning, audit logging) are typically covered by a general deployment/release section. Do not repeat them in domain-specific sections.
• Cross-references (e.g., "see 3.1.5.1") are acceptable. Restating the same requirement in both places is not.
• When deleting a section, grep the entire document for its section number and update all references (tables, cross-references, footnotes).

3. Pain Point Filter

Every requirement must address a real pain point. Ask:

• Is this specific to the domain (e.g., artifacts are 100GB+ -- genuinely different from typical deployments)?
• Or is this standard practice already covered by general infrastructure (e.g., checksum verification -- any package manager does this)?

If it's standard practice, delete it. Only keep domain-specific requirements that would not be met by the general process.

Infrastructure standard practice test: If a section could appear verbatim in any K8s/cloud platform RFP with zero modification (e.g., secret management, HA control plane, CPU sizing, backup/restore), it is infrastructure boilerplate, not a domain-specific requirement. Either delete it or move it to the infrastructure layer where it belongs — do not give it a standalone section in the application layer.

3b. Cross-Section Consistency

After editing a section, check that its content does not contradict design principles stated elsewhere in the document. Common violations:

• One section says "不依賴本地儲存" while another section's design requires local storage
• Appendix defines baselines as "由廠商提出" while main body references those baselines as acceptance criteria

Action: Grep for key terms (design principles, architecture choices) and verify all sections align.

3c. Appendix Bloat

An appendix earns its place only if it adds concrete, quantifiable information not already in the main body. Kill appendices where:

• Most rows say "由廠商提出" or equivalent — that is not a baseline, it is punting the requirement
• The concrete values (e.g., 99.9% uptime, RPO/RTO numbers) are generic enterprise standards already implied by main-body sections
• The appendix merely restates requirements from the main body in table form

Action: Move any concrete numbers worth keeping into their parent sections, update all references, then delete the appendix.

3d. Thin Section Consolidation

A section with only 1-2 bullet points and no opening context explaining why it matters is a sign it does not justify standalone existence. Merge it into the nearest parent or sibling section as additional bullets or a short paragraph.

Test: If removing the section header and indenting its content under a neighbor loses zero information, the section should not exist independently.

4. Section Justification

A section earns its place by meeting both criteria:

1. Has a concrete use case in the current or next phase
2. Has enough substance to warrant standalone treatment (opening context + 3+ requirements)

Decision tree:

• Has first-phase use case + sufficient substance: Keep as a full section with requirements.
• Has first-phase use case but thin (1-2 bullets): Merge into the nearest related section.
• Has second-phase use case with clear scope: Keep as a subsection or remark (blockquote) under the related first-phase section.
• No concrete use case, only "might need later": Demote to a one-sentence remark. Do not create a standalone section for speculative needs.

5. Reference Integrity

After any structural change (section move, delete, renumber):

1. grep the full document for the old section number
2. Update every reference: tables, cross-references, blockquotes, appendices
3. Verify zero remaining references to deleted sections

Language Rules

Mandatory: Complete Sentences

Every bullet point must be a complete sentence that explains what and why. Reject:

BAD:  - 持久卷（PV/PVC）
BAD:  - HA（控制面與關鍵服務）
BAD:  - 備份/還原（設定、資料、索引）

GOOD: - 所有儲存須透過 CSI 驅動掛載為持久卷（PV/PVC），不依賴節點本地磁碟。
GOOD: - 控制面與關鍵服務須部署為高可用架構，單節點故障不中斷服務。

Mandatory: Section Context

Each section must open with 1-2 sentences explaining why this matters before listing requirements. The reader needs to understand the problem before reading the solution.

BAD:
#### 3.3.2 儲存
- PV/PVC 支援
- 高吞吐
- 分層儲存

GOOD:
#### 3.3.2 儲存
本平台的儲存需求與一般應用不同：核心檔案動輒數十 GB，索引需要持續高吞吐讀寫，稽核日誌須長期保留且不可竄改。

**需求：**
- 所有儲存須透過 CSI 驅動掛載...

Prohibited Patterns

Allowed Patterns (do not flag)

Workflow

Reviewing an existing RFP

1. Read the full document first
2. Run structural checks (placement, redundancy, pain point filter, justification)
3. Propose structural changes as a table: section, problem, proposed action
4. Get user confirmation before editing
5. After structural edits, run language audit (grep for prohibited patterns)
6. Fix language issues
7. Final grep to verify no prohibited patterns remain
8. Offer humanizer-zh as a deep de-AI pass over the final draft; run it only if the user agrees

Drafting a new section

1. Start with 1-2 sentences of context (why this section exists)
2. Add **Requirements:** header
3. Write each requirement as a complete sentence
4. Cross-check against existing sections for redundancy
5. Run language audit before presenting to user
6. Offer humanizer-zh as a deep de-AI pass before presenting; run it only if the user agrees