workflow-design-notes

name	workflow-design-notes
description	dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。

/workflow-design-notes

議論駆動の設計セッションで、完成文書への継ぎ足し編集を構造的に排除する。アーティファクトを 2 つに分離する:

• 決定台帳 docs/DESIGN_NOTES.md: 追記専用の作業記憶。議論中はこれだけを更新する
• 設計書 docs/design/DESIGN.md + docs/design/features/<機能名>.md: 台帳からの再生成物。議論中に直接 Edit しない

継ぎ足しで文書が劣化する根本原因は「議論の作業記憶」と「レビュー用の完成文書」を同じファイルに兼ねさせることにある。台帳は形式が緩く追記の害がなく、設計書は毎回ゼロから生成されるため常に全体整合した状態で読める。

議論フェーズ（台帳の運用）

• パスは docs/DESIGN_NOTES.md（プロジェクトに既存の慣例パスがあればそちらを優先）。セッション・compaction を跨ぐ記憶を兼ねるため、tmp 等の揮発する場所に置かない
• 決定・棄却・保留が出るたびに 1 項目 1 行で追記する:

- [決定] 提案の集約先は S3 1 バケット + userid プレフィックス — IAM ポリシー 1 本で偽装防止が成立するため
- [棄却] ユーザーごとバケット — バケット数が人数に比例し Terraform 管理が肥大するため
- [保留] EC2 の TZ — installer の前提検証で実機確認してから timer の OnCalendar を確定

• 追記専用（過去行の削除・書き換え禁止）。決定を覆すときは旧行の末尾に → 撤回 を付記し、新しい決定行を追記する
• 棄却行は再生成時の「再提案しない」根拠になるため、理由 1 文を必ず添える
• 議論中に設計書を直接 Edit しそうになったら、まず台帳に決定として追記する（設計書への反映は落とし込みで行う）

落とし込みフェーズ（設計書の再生成）

トリガー: ユーザーの「まとめて」「落とし込んで」指示。議論が節目（アーキテクチャ確定・レビュー依頼前）に達したと判断したら自分から提案してよい。

1. rules/core/documentation.md の手順どおり依拠事実を rg で再検証する
2. rules/core/references/doc-formats/design-doc.md（構造規範）と ../dev-spec/references/design-doc.md（DESIGN.md テンプレートの正本）・../dev-spec/references/feature-doc.md（機能設計書テンプレート）を Read する
3. 台帳全体から docs/design/DESIGN.md + docs/design/features/ を毎回ゼロから生成する（前回生成物への差分編集をしない）。生成物の冒頭に <!-- generated-from: docs/DESIGN_NOTES.md --> を入れる（直接編集への注意標識）
4. design-doc.md の「機械ゲート」判定コマンド（POC_NEEDED blocker=true 残存）を自分で実行し、通らなければ生成をやり直す
5. /utility-doc-audit を設計書 2 ファイル + 決定台帳付きでフル監査として起動する（ゼロから全文再生成した直後のため、スコープ監査ではなく観点 1〜6 全体を検査させる。決定カバレッジ観点が台帳→文書の取りこぼし・棄却案の生き残りを検査する）
6. 監査指摘のうち決定に関わるものは台帳に反映してから再生成する（文書だけを直すと台帳と文書が乖離する）。字句レベルの指摘は文書の直接修正でよい

下流への接続

落とし込み後に実装へ進む場合: /dev-spec のフェーズ 9〜10（issue ドラフト + ドラフトチェック → issue 作成）を実行してから /dev-impl を起動する。本スキルの成果物は dev-spec の成果物（DESIGN.md + features/）と同形なので、そのまま接続できる。

境界（対象外）

• dev-spec の代替ではない。インタビュー・DDD モデリング・PoC 検証・承認ゲートはやらない（それらが必要な規模なら /dev-spec を使う）
• dev-spec で生成済みの設計書の更新には使わない（dev-spec の更新モードを使う）
• 台帳は成果物ではなく作業記憶。整形・監査の対象にしない

関連

• rules/core/documentation.md — ドキュメント作業ルールの正本
• rules/core/references/doc-formats/design-doc.md — 設計書の構造規範（機械ゲート含む）
• ../utility-doc-audit/SKILL.md — 落とし込み後の監査