elite-rfc-writer

编写具有严格模板执行的决策导向工程 RFC。当用户请求 RFC、架构决策提案或结构化决策文档时使用，这些文档必须遵循确切的标题：Zusammenfassung、Motivation、Ziele、Nicht-Ziele、Vorschlag、Anhang。

# Elite RFC Writer

Produce precise, decision-enabling RFCs for engineering and architecture decisions.

## Skill contract

- **Name:** `elite-rfc-writer`
- **Problem solved:** Convert ambiguous requests into clear, decision-oriented RFCs with explicit scope and trade-offs.
- **Required input categories (must collect before drafting):**
  1. Problem to solve
  2. Stakeholders affected
  3. Constraints (technical/organizational/regulatory/financial)
  4. Alternatives considered
  5. Risks and open questions
- **Output:** RFC in exact mandatory structure and headings (German)
- **Safety boundaries:**
  - Never deviate from mandatory headings/order.
  - Never hide uncertainties; state assumptions explicitly.
  - Never omit risks/trade-offs.
  - Never use marketing language or vague claims.

## Mandatory workflow

Use references as needed:
- Read `references/rfc-intake-checklist.md` during intake.
- Read `references/decision-guardrails.md` before finalizing.

### 1) Intake validation (hard gate)

Before writing, verify all five required input categories are present.

If data is missing:
- Ask concise clarifying questions.
- Do not draft a final RFC yet.

### 2) Drafting rules

- Use short paragraphs.
- Prefer bullet points.
- Keep tone neutral and analytical.
- Avoid unnecessary implementation details.
- Ensure statements are testable/falsifiable where possible.
- Explicitly state assumptions and uncertainty.
- Add concrete success criteria for each goal when possible.
- Keep content decision-oriented; remove educational filler.

### 3) Template enforcement (no deviation)

Always output RFCs with this exact structure and headings:

# Zusammenfassung
[ Absatz 1: Problemzusammenfassung ]
[ Absatz 2: Zusammenfassung des Lösungsvorschlags ]

# Motivation
[ Welches Problem müssen wir adressieren? ]

# Ziele
* [ Ziel ]: [ Erläuterung (welche Ziele sollte der Lösungsvorschlag unterstützen?) ]

# Nicht-Ziele
* [ Nicht-Ziel ]: [ Erläuterung (Nebenpfade / Zeitfresser / No-Go-Bereiche / Scope Creep vermeiden) ]

# Vorschlag
[ Wie lösen wir das oben beschriebene Problem? ]

# Anhang
[ Alles Weitere, einschließlich FAQ, betrachtete Alternativen, Nachteile, Daten, Referenzen, ... ]

### 4) Decision guardrails (Project-Syn inspired)

Keep the mandatory heading structure unchanged, but enforce these guardrails inside the sections:

- In **Zusammenfassung**:
  - State decision status (`speculative`, `draft`, `accepted`, `rejected`, `implemented`, `obsolete`).
  - State decision owner and decision date.
- In **Motivation**:
  - Add measurable evidence that the problem exists.
  - List assumptions explicitly.
- In **Ziele**:
  - Add measurable success criteria for each goal.
- In **Nicht-Ziele**:
  - Explicitly mark out-of-scope work and no-go areas.
- In **Vorschlag**:
  - Include migration path and rollback strategy when operationally relevant.
  - List key constraints (technical, organizational, regulatory, financial).
- In **Anhang**:
  - Include alternatives considered and why rejected.
  - Include drawbacks/risks with mitigations.
  - Include open questions with owner and due date.
  - Include references to tickets/PRs/docs used as evidence.

### 5) Quality gate before finalizing

Confirm all checks:
- Problem clearly defined and measurable
- Goals and non-goals reduce scope creep
- Proposal actionable and realistic
- Risks and alternatives documented
- Assumptions explicit and testable
- Migration/rollback defined when relevant
- Document supports a concrete decision

If any check fails, revise before final output.

## Response style requirements

Use descriptive language with precise terminology and concrete trade-off statements.

---

## 中文说明

# Elite RFC Writer

为工程和架构决策编写精确、可支撑决策的 RFC。

## 技能契约

- **名称：** `elite-rfc-writer`
- **解决的问题：** 将含糊的请求转化为清晰、以决策为导向的 RFC，明确范围和权衡。
- **必需的输入类别（起草前必须收集）：**
  1. 需要解决的问题
  2. 受影响的利益相关者
  3. 约束条件（技术/组织/监管/财务）
  4. 已考虑的备选方案
  5. 风险和未决问题
- **输出：** 采用严格强制结构和标题（德语）的 RFC
- **安全边界：**
  - 绝不偏离强制标题/顺序。
  - 绝不隐藏不确定性；明确陈述假设。
  - 绝不省略风险/权衡。
  - 绝不使用营销语言或含糊的主张。

## 强制工作流

按需使用参考文件：
- 在接收阶段阅读 `references/rfc-intake-checklist.md`。
- 在定稿前阅读 `references/decision-guardrails.md`。

### 1) 接收验证（硬性门禁）

在撰写之前，确认所有五个必需的输入类别都已具备。

如果数据缺失：
- 提出简洁的澄清问题。
- 暂不起草最终 RFC。

### 2) 起草规则

- 使用短段落。
- 优先使用要点列表。
- 保持中立和分析性的语气。
- 避免不必要的实现细节。
- 尽可能确保陈述是可测试/可证伪的。
- 明确陈述假设和不确定性。
- 尽可能为每个目标添加具体的成功标准。
- 保持内容以决策为导向；删除教学性填充内容。

### 3) 模板执行（不得偏离）

始终以这一严格的结构和标题输出 RFC：

# Zusammenfassung
[ Absatz 1: Problemzusammenfassung ]
[ Absatz 2: Zusammenfassung des Lösungsvorschlags ]

# Motivation
[ Welches Problem müssen wir adressieren? ]

# Ziele
* [ Ziel ]: [ Erläuterung (welche Ziele sollte der Lösungsvorschlag unterstützen?) ]

# Nicht-Ziele
* [ Nicht-Ziel ]: [ Erläuterung (Nebenpfade / Zeitfresser / No-Go-Bereiche / Scope Creep vermeiden) ]

# Vorschlag
[ Wie lösen wir das oben beschriebene Problem? ]

# Anhang
[ Alles Weitere, einschließlich FAQ, betrachtete Alternativen, Nachteile, Daten, Referenzen, ... ]

### 4) 决策护栏（受 Project-Syn 启发）

保持强制标题结构不变，但在各节内部执行这些护栏：

- 在 **Zusammenfassung** 中：
  - 说明决策状态（`speculative`、`draft`、`accepted`、`rejected`、`implemented`、`obsolete`）。
  - 说明决策负责人和决策日期。
- 在 **Motivation** 中：
  - 添加问题确实存在的可衡量证据。
  - 明确列出假设。
- 在 **Ziele** 中：
  - 为每个目标添加可衡量的成功标准。
- 在 **Nicht-Ziele** 中：
  - 明确标注超出范围的工作和禁区。
- 在 **Vorschlag** 中：
  - 在运营相关时包含迁移路径和回滚策略。
  - 列出关键约束（技术、组织、监管、财务）。
- 在 **Anhang** 中：
  - 包含已考虑的备选方案及被拒绝的原因。
  - 包含缺点/风险及缓解措施。
  - 包含未决问题及其负责人和截止日期。
  - 包含作为证据所引用的工单/PR/文档的引用。

### 5) 定稿前的质量门禁

确认所有检查项：
- 问题定义清晰且可衡量
- 目标和非目标可减少范围蔓延
- 提案可执行且现实
- 风险和备选方案已记录
- 假设明确且可测试
- 在相关时已定义迁移/回滚
- 文档可支撑一个具体决策

如果任何检查项不通过，在最终输出前进行修订。

## 响应风格要求

使用描述性语言，配以精确的术语和具体的权衡陈述。