Menü
提案戦略書・チェックリストに基づき、提案書のMarkdownスライド設計書を生成・更新するスキル。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | proposal-writer |
| description | 提案戦略書・チェックリストに基づき、提案書のMarkdownスライド設計書を生成・更新するスキル。 |
| user-invocable | true |
| argument-hint | <対象Vol番号またはall> [出力形式: md|outline] |
| allowed-tools | Read, Grep, Glob, Write, Task |
本スキルは、提案書作成の3層構造に基づき、スライド設計書（Markdown形式）を生成・更新する。 提案戦略からスライド1枚1枚のメッセージまでを一貫した論理で繋ぎ、抜け漏れのない提案書構成を実現する。
提案戦略書（Why: なぜ勝てるか）
↓ Win Strategy / 差別化の柱を反映
チェックリスト（What: 何を書くか）
↓ 章立て・必須項目を網羅
スライド設計書（How: どう伝えるか）
→ 各スライドのメッセージ・内容・スピーカーノート
プロジェクトルートの DESIGN.md を読み込む。Phase 2.5 で確定されたデザイン規約（色・タイポ・コンポーネント・Slide-Specific Rules）を抽出し、以降のスライド設計書・per-volume design.md 生成時に必ず反映する。
DESIGN.md が存在しない場合はエラーを返し、/auto-run 2.5 または Phase 2.5 (Design System) の実行を促す2. Color Palette & Roles の意味名トークンのみを使用し、独自の色を追加しない7. Slide-Specific Rules のスライドマスター仕様（ヘッダー/フッター、表紙・章扉）を全ボリュームで統一するarcadia/org-data/ 配下の自社固有データを読み込み、提案書に活用可能な自社情報を把握する:
company-profile.md: 会社概要、認証・資格、パートナーシップ、導入実績（実績IDで引用）service-catalog.md: 自社サービスの仕様・差別化ポイント（サービスIDで引用）whitepapers/index.md: 引用可能なホワイトペーパー（タグ別・章別の引用推奨マップ）org-data が未整備の場合でもスライド設計書の生成は可能だが、 会社紹介・実績・差別化セクションの内容が汎用的になるため、整備を推奨する。
提案戦略書（output/plan/proposal-strategy.md 等）を読み込み、以下を把握する:
提案書作成チェックリスト（output/plan/proposal-items-checklist.md 等）を読み込み、以下を把握する:
1スライド1メッセージ原則に基づき、各スライドを設計する:
以下のフォーマットで出力する:
# [提案書タイトル]
## メタ情報
- **想定スライド数**: XX枚
- **対象チェックリスト項目**: [項目ID一覧]
- **キーメッセージ**: [提案書全体で最も伝えたいこと]
---
## スライド一覧
### Slide 1: [スライドタイトル]
- **メッセージ**: [このスライドで伝えたい1つのこと]
- **内容**:
- [箇条書きで記載内容を列挙]
- [図表がある場合はその概要も記載]
- **スピーカーノート**: [プレゼン時の補足説明・強調ポイント]
- **対応チェックリスト**: [項目ID]
### Slide 2: [スライドタイトル]
...
生成したスライド設計書とチェックリストを突合し、以下を確認する:
突合結果をスライド設計書の末尾に付記する:
## チェックリスト突合結果
| チェック項目ID | 対応スライド | 状態 |
|--------------|------------|------|
| E-1-1 | Vol.1 Slide 3 | カバー済 |
| E-1-2 | - | 未対応（要追加） |
提案書の章構成は以下をデフォルトとする。RFPが章構成を指定している場合はRFP指定に従う。 各章のスライド枚数はRFPの要求内容・配点に応じて傾斜配分する。
| 章 | タイトル | 主な内容 | 枚数目安 |
|---|---|---|---|
| 1 | エグゼクティブ・サマリー | 提案全体の要約、キーメッセージ、差別化ポイント。本章のみ他章との内容重複を許容 | 1 |
| 2 | 会社概要・実績 | 会社紹介、関連プロジェクト実績、認証・資格、パートナー体制 | 1-2 |
| 3 | 提案コンセプト | 現状課題（As-Is）→ 目指す姿（To-Be）、提案の全体像 | 2-3 |
| 4 | システム構成・アーキテクチャ | 論理構成図、技術スタック、機能要件対応、データ連携・移行方式 | 3-5 |
| 5 | 移行計画 | 移行方式、移行スケジュール、リスク対策、テスト計画 | 2-3 |
| 6 | プロジェクト計画 | 体制図、スケジュール、開発方法論、品質管理、教育・内製化支援 | 2-3 |
| 7 | 運用・保守 | SLA/SLO、監視、障害対応、運用体制、継続改善 | 1-2 |
| 8 | 費用 | イニシャル/ランニング費用、TCO、費用内訳、価格の考え方 | 1-2 |
| 9 | Appendix | 追加訴求ポイント、デモアプリ概要・スクリーンショット、制約事項、補足資料 | 2-3 |
基本は全体で約20枚。枚数目安は参考値であり、RFPの物量・配点に応じてスケールする。重点項目には傾斜配分する。
提案書は原則として1冊（Single Volume）で構成する。 分冊はデフォルトではなく、必要に迫られた場合の例外措置である。
提案書全体を通じて MECE（Mutually Exclusive, Collectively Exhaustive） を徹底する:
以下の場合に限り、ユーザーに確認の上で分冊を行う:
RFPが分冊を要求している場合はその指定に従う:
AIがスライド設計書を一貫性を保って生成・レビューできるサイズを超える場合:
| 成果物 | パス | 説明 |
|---|---|---|
| スライド骨子 MD | output/slides/slides.md（分冊時: vol{N}-{topic}/slides.md） | 本スキルの主出力 |
| デザイン指示 MD | output/slides/design.md（分冊時: vol{N}-{topic}/design.md） | NanoBanana用のビジュアルデザイン指示（DESIGN.md を継承） |
| スライド画像 | output/slides/slide-{NN}.png（分冊時: vol{N}-{topic}/slide-{NN}.png） | NanoBananaスキルが生成 |
| 全体結合 PDF | output/proposal-all.pdf | document-skills プラグインが画像を結合して生成 |
design.md と DESIGN.md の関係DESIGN.md（プロジェクトルート）: 全ボリューム横断の規約（色・タイポ・コンポーネント・スライドマスター）output/slides/vol{N}-{topic}/design.md（ボリューム別）: ボリューム固有のビジュアル指示（各スライドの構図・アイコン・図解スタイル等）per-volume design.md 生成時は冒頭で DESIGN.md を明示的に参照し、「本書は DESIGN.md を継承する。以下は本ボリューム固有の指示のみ記載する」と宣言する。色・フォント・radius 等の基本トークンを重複記述しない。
デフォルト（単冊）:
output/slides/直下に骨子・デザイン・画像を配置する。 分冊時: Volume別サブフォルダ（vol{N}-{topic}/）に集約。{topic}は kebab-case。PDF生成: NanoBananaモードでスライド画像を生成した後、
document-skillsプラグインを使用してスライド画像を結合した PDF（output/proposal-all.pdf）を自動生成する。
上記Step 4のフルフォーマットで出力する。スライド制作担当者がそのまま作業に使える詳細度。
簡易アウトライン形式で出力する。構成レビュー用。
# [提案書タイトル]（XX枚）
1. [スライドタイトル] - [メッセージ]
2. [スライドタイトル] - [メッセージ]
3. ...
REF-XXX / SVC-XXX の内部IDそのものは出さず、社名・案件名・サービス正式名称で表現する（追跡用のIDはスライド設計書のコメントに留める）以下の ARCADIA 内部用語は顧客向け成果物（slides.md 本文、スピーカーノート、PPTX、画像、PDF、回答シート）には出さない。architecture-policy.md 等の内部ドキュメントから内容を転記する際は必ず言い換える。
| 内部用語 | 置換表現の例 |
|---|---|
ADR / ADR-NNN / 「アーキテクチャ決定記録」 | 「主要な設計判断」「アーキテクチャ選定の考え方」「技術選定の根拠」 |
[AUTO] / [AUTO][要確認] マーク | 削除（内部ドラフト専用マーク） |
REF-XXX / SVC-XXX / TASK-N 等の内部ID | 削除または正式名称・一般表現に置換 |
理由: ADR 等は日本の顧客・現場には馴染みのない用語で、提案書に出るとノイズになる。トレーサビリティのためのID類は内部ドキュメント（
output/plan/）内に留め、顧客成果物（output/slides/、output/直下の PPTX/PDF/XLSX）には表出させない。
見積方針書に基づき、工程別見積の草案作成・数値整合性チェックを行うスキル。
CLAUDE.md のデモ仕様とヒアリング結果に基づき、Next.js デモアプリの画面・コンポーネント・モックデータをゼロから生成するスキル。
自社（提案主体）と提案先（クライアント）の会社情報をWebから自動取得し、org-data/company-profile.md および source/client-profile.md を充実させるスキル。フルオートモードでは必須。
溜まったタスクの一覧確認・優先度トリアージ・対話的な方針決定と処理を行うスキル。
提案策定中のタスク・検討事項・課題を tasks.md に起票するスキル。人間が直接呼び出すほか、Claudeが会話中に検討事項を発見した際にも使用する。
プロジェクト進行中に追加資料を取り込むスキル。input/配下のファイルを自動分類し、source/ または org-data/ の適切な場所に配置する。docs-catalogの差分更新も実施。