create-speclisted

# create-spec — 技術仕様書を書く このスキルは **技術仕様書 (Tech Spec / Design Doc / RFC) を 1 枚の HTML として生成** します。 完成物はブラウザでそのまま開ける自己完結ファイル + 共有アセットの組み合わせです。 --- ## 1. 進め方 (必ずこの順番で) 1. **対象ディレクトリの確認** - ユーザーが出力先を明示していなければ、現在の作業ディレクトリ直下に `docs/spec/` を提案し、合意を取る。 - 既存の spec ディレクトリがあれば、その命名規則 (例: `2026-05-event-bus.html`) に従う。 2. **必要情報を 1 メッセージにまとめて確認** ユーザーが既に提供している情報は二重に聞かない。不足分のみ次の項目をまとめて 1 度で質問する: - タイトル (簡潔に「何を作るか」) - Owner / Status (Draft / In Review / Approved / Implemented) - 解こうとしている問題 (Overview) - Goals / Non-Goals - 現状の仕組み・前提・制約 (Background) - 提案する設計 (主要なエンティティ、データフロー、コンポーネント分割) - API 仕様 (エンドポイント、リクエスト/レスポンス、エラー) - データモデル (主要テーブル / スキーマ / 関係) - 実装フェーズ (段階的ロールアウト計画) - 運用観点 (Observability / Reliability / Security) - リスクとトレードオフ - Open Questions / 関連リンク 3. **生成** - `${PLUGIN_ROOT}/shared-assets/templates/skeleton-spec.html` を雛形にする。 - 出力先 (例: `docs/spec/event-bus.html`) に書き出す。 - 同じディレクトリの `system/` サブディレクトリに共有アセットをコピー (§3)。 4. **報告** - 生成パスと未確定の Open Questions を 1 段落で報告。 - ブラウザで開いて確認するよう促す。 --- ## 2. 章立て (雛形から不要な節は削除可) ``` h1: タイトル + eyebrow (Technical Specification) → Status / Owner / Last updated h2: Overview … 何を解くか・何が変わるか h2: Goals … 達成したいこと h3: Non-Goals … 今回扱わないこと h2: Background … 現状の仕組み、前提、制約 h2: Proposed Design … 設計の全体像 (Mermaid 図やコード例) h2: API … エンドポイント・入出力・エラー h2: Data Model … エンティティ・関係・主要フィールド h2: Implementation Plan … 段階的なフェーズ h2: Opera