朝の確定エンジン: retrospective の提案を「今日のコミットメント」に変換する

[nakagam3]

痛み

「今日何やるといいか分からない状態で仕事を開始すること」が苦痛。
retrospective が前夜にゴールを提案するが、翌朝にそれを確認・確定するステップがない。
提案は一晩で陳腐化する可能性があり、確認しないまま走り出すと反応的な一日になる。

仮説

retrospective の出力（sprint-log のゴール提案）を入力にして、朝の時点で：

• 前夜の提案を思い出す（「思い出す」効果はバカにできない）
• overnight の変化（Slack, カレンダー等）を踏まえて有効性を確認する
• 「今日はこれでいく」と確定する

全体との接続

retrospective が夜の C→A→P なら、これは朝の P→D 接続。
PDCA のフラクタル構造における日次スケールの「P の確定」にあたる。
retrospective の出力 → このスキル → 実行開始、でサイクルが閉じる。

データフロー（想定）

[前夜] retrospective → sprint-log/YYYY-MM-DD.yml (goals: proposed)
[翌朝] このスキル → sprint-log/YYYY-MM-DD.yml (goals: committed)

設計上の知見

• カレンダーが統合ビュー: タスクソースは分散（Jira, Google Tasks, 個人依頼, 長期物）しているが、全て最終的にカレンダーに射影される。週次ルーティン: PDCA フラクタルの週次スケール（ふりかえり + 計画 + タスク配置） #3 の P フェーズが週次でタスクを時間軸に配置するため、朝の確定時点ではカレンダーを読むだけで全タスクソースをカバーできる可能性がある（要検証）
• タスクシュートの思想: 人は時間軸に沿って仕事をしているので、時間軸上でタスクを管理すべき

関連

• 着手変換: タスク全体像の中から「今これ」を選び最初の一手を明確にする #2（着手変換）と密結合の可能性あり。1スキルにするか2スキルにするかは設計時に判断
• 週次ルーティン: PDCA フラクタルの週次スケール（ふりかえり + 計画 + タスク配置） #3（週次ルーティン）が存在すれば、週の配分を参照して日次のコミットメント精度が上がる