メニュー
dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/skanehira/dotfiles --skill workflow-design-notesコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
実装ループ。/dev-spec が作成した GitHub issue (ゴール / 設計参照 / DoD / 非スコープ / 依存の thin 構成) を入力に、依存順に 1 件ずつ「implementer subagent → 統合レビュー → 修正 ≤2 ラウンド → PR → DoD ローカル実行 → merge → close」で自律実装するオーケストレーター。進捗は issue コメントに残し、詰まった issue は needs-human で駐車して次へ進む。人間の介入はエスカレーション時のみ。issue 作成後にユーザーが直接起動し、エスカレーション回答後の再開も本スキルの再実行で行う。「実装ループを開始」「issue を順に実装して」「残りタスクを自動で実装」などで起動。
設計ループ。ユーザーストーリー → UI スケッチ → ユースケース → 実現可能性検証 → PoC 検証 → 横断設計 (docs/design/DESIGN.md) → 機能設計 (docs/design/features/) → 設計チェック → issue ドラフトチェック → GitHub issue 生成 (親子構造) までを対話的に実行し、人間が issue を確認して実装ループへ引き渡す。 「設計フェーズを開始」「要件を整理したい」「計画を立てたい」「ユーザーストーリーを書きたい」 「技術的に実現できるか確認したい」「機能設計を書きたい」「issue に落としたい」などで起動。 docs/design/ の状態から途中再開・特定フェーズの部分実行も可能。 `cli` / `webapp` のプロダクトモード指定で CLI ツール開発時は UI スケッチ等を軽量化できる。 issue 作成後、/dev-impl がそれを 1 件ずつ実装する。
ローカルの git 差分を統合レビュワー review-impl subagent (テスト品質 / 設計準拠 / コード品質 / E2E 実行の 4 項目) で fresh context レビューする薄い orchestrator。「差分検出 → review-impl 起動 → 結果の整形表示 → 修正アクション選択」を担当。セキュリティレビューは security-guidance プラグイン (Stop hook の LLM diff review + Edit 時の pattern 検知) に委譲しており本 skill の対象外。「レビューして」「この差分を見て」「コミット前にチェック」などで起動。
SKILL.md を表示中
| name | workflow-design-notes |
| description | dev-spec を使わず議論しながら設計を固めるときの進行様式。議論中は決定台帳 (DESIGN_NOTES.md) だけを追記し、節目に dev-spec 互換の DESIGN.md (1 枚) + docs/design/features/ へゼロから落とし込む。「議論しながら設計したい」「設計の壁打ちを文書に残したい」「台帳に記録して」「設計書に落とし込んで」「一旦まとめて」などで起動。 |
議論駆動の設計セッションで、完成文書への継ぎ足し編集を構造的に排除する。アーティファクトを 2 つに分離する:
docs/DESIGN_NOTES.md: 追記専用の作業記憶。議論中はこれだけを更新するdocs/design/DESIGN.md + docs/design/features/<機能名>.md: 台帳からの再生成物。議論中に直接 Edit しない継ぎ足しで文書が劣化する根本原因は「議論の作業記憶」と「レビュー用の完成文書」を同じファイルに兼ねさせることにある。台帳は形式が緩く追記の害がなく、設計書は毎回ゼロから生成されるため常に全体整合した状態で読める。
docs/DESIGN_NOTES.md（プロジェクトに既存の慣例パスがあればそちらを優先）。セッション・compaction を跨ぐ記憶を兼ねるため、tmp 等の揮発する場所に置かない- [決定] 提案の集約先は S3 1 バケット + userid プレフィックス — IAM ポリシー 1 本で偽装防止が成立するため
- [棄却] ユーザーごとバケット — バケット数が人数に比例し Terraform 管理が肥大するため
- [保留] EC2 の TZ — installer の前提検証で実機確認してから timer の OnCalendar を確定
→ 撤回 を付記し、新しい決定行を追記するトリガー: ユーザーの「まとめて」「落とし込んで」指示。議論が節目（アーキテクチャ確定・レビュー依頼前）に達したと判断したら自分から提案してよい。
rules/core/documentation.md の手順どおり依拠事実を rg で再検証するrules/core/references/doc-formats/design-doc.md（構造規範）と ../dev-spec/references/design-doc.md（DESIGN.md テンプレートの正本）・../dev-spec/references/feature-doc.md（機能設計書テンプレート）を Read するdocs/design/DESIGN.md + docs/design/features/ を毎回ゼロから生成する（前回生成物への差分編集をしない）。生成物の冒頭に <!-- generated-from: docs/DESIGN_NOTES.md --> を入れる（直接編集への注意標識）/utility-doc-audit を設計書 2 ファイル + 決定台帳付きでフル監査として起動する（ゼロから全文再生成した直後のため、スコープ監査ではなく観点 1〜6 全体を検査させる。決定カバレッジ観点が台帳→文書の取りこぼし・棄却案の生き残りを検査する）落とし込み後に実装へ進む場合: /dev-spec のフェーズ 9〜10（issue ドラフト + ドラフトチェック → issue 作成）を実行してから /dev-impl を起動する。本スキルの成果物は dev-spec の成果物（DESIGN.md + features/）と同形なので、そのまま接続できる。
/dev-spec を使う）rules/core/documentation.md — ドキュメント作業ルールの正本rules/core/references/doc-formats/design-doc.md — 設計書の構造規範（機械ゲート含む）../utility-doc-audit/SKILL.md — 落とし込み後の監査