Route Skill 🗺️

Route Skill 🗺️

Routeは、Issue から目的地（マージ・リリース）までの 最適な path を探索 するためのスキルです。

基本姿勢: グルーブを忘れない 🎵

Route のすべての選択の土台となる姿勢です。

「最適なパスを探すんじゃない。気持ちよく走れるパスを探すんだ。」

• 気持ちよさ優先 - 最短 30 秒でも心がざわつく path より、5 分余計でも スッと走れる path を選ぶ
• 走りのリズム - Survey → Plot → Compare → Choose の流れ自体が一定のテンポ。 飛ばすと転ぶ
• 同乗者の気分 - ユーザーも一緒に旅する。独走しない
• 迷い道も学び - 「このパスはダメだった」も Log に残せば次の地図になる

NGなグルーブ

• 独り善がりな最短路（ユーザー置き去り）
• ルールに縛られて apply しない（スキルが重荷になる）
• 他人の path を否定（「B の方がいいって言ったのに」的マウント）

OKなグルーブ

• 「これがハマる道だな〜」という直感を言語化する遊び
• 「意外と C（放棄）もアリかも」という脱力
• 「FSC-22 のときは 45 分で済んだんだけど」のケースネタ

コア姿勢

「Issue は地図。path は一本じゃない。最短・最安全を選ぶ。」

大きな Issue を受け取ったとき、書かれた「やること」リストを鵜呑みに全部着手するのではなく、既に舗装された道（実装済み）と 迂回すべき脇道（YAGNI 領域）を見極めて、真に必要な一本の path を選び取ります。

• 地図を読む - コードと Issue の両方を読み、現状を把握
• 候補を描く - 複数の path を想定（最短／遠回り／放棄）
• 採点する - コスト・安全性・後続影響で比較
• 選ぶ - 最適 path を提示、ユーザー承認を得る
• 走る - 選んだ path を実装・PR・マージ
• 記録する - 走行ログを次の探索のために残す

6 フェーズ（+ 1 ゲート）

Survey → Plot → Compare → Choose → 🚦 [HARD GATE] → Travel → Log

番号は使いません。依存は矢印のみで表現します。HARD GATE 以外のフェーズは単方向で流れます。

🗺 Survey（地図確認）

コードベース・Issue・関連メモリを読み、現状の地形を把握する。

• Inventory: Issue 本文の「やること」のうち、既に実装されている項目を特定
• Dependencies: 上流・下流・並行タスクとの関係を確認
• Unknowns: 何が未知かを明示（推測で path を描かないため）

NG: 地図を読まずに走り出す。Issue 本文の項目数を見て「大きそう」と判断して諦める／丸呑みする。

🛣 Plot（経路候補の列挙）

ゴールに至る 複数の path を描く。

• 最短 path: 真の差分だけ触る最小構成
• 安全 path: 多少遠回りでも破壊リスクが低い
• 拡張 path: 将来機能も巻き込む（通常は却下候補）
• 放棄 path: そもそもやらない選択肢

少なくとも 2 本は描く。1 本しか見えていないときは視野が狭い可能性を疑う。

NG: いきなり 1 本に決め打ち。

⚖️ Compare（採点）

各 path を評価軸で比較する。

評価軸	意味
Cost	実装時間、PR サイズ、レビュー負荷
Safety	破壊影響、ロールバック容易性
Unblock	後続タスクをどれだけ解放するか
YAGNI risk	未使用の抽象を先に作っていないか

採点は厳密な数値でなくてよい。相対比較で「こっちの方が明らかに短い・安全」と言えれば十分。

NG: 「なんとなく良さそう」で選ぶ。評価軸を言語化しない。

✅ Choose（選択）

最適 path を選ぶ。脇道は 別 Issue に切り出す。

• 選ばれなかった path の要素で価値があるものは、フォローアップ Issue として明示的に残す
• YAGNI になりそうな要素は defer（今は手を出さない、必要になったら別 Issue）

NG: 全部やろうとする。脇道を黙って放棄する（後で「やるはずだった」が見失われる）。

🚦 HARD GATE: User Confirm

選んだ path を **ユーザーに提示して明示的な GO をもらう** まで走り出さない。

どんなに「これしかない」と思えても、path の選択には判断が含まれる。 ユーザーが別の path を選ぶ権利を尊重する。 提示は短くてよい（3 候補 + 推奨 1 行でも可）。だが、必ず確認を取る。

🏃 Travel（走行）

選んだ path を実装する。

• ブランチ作成 → 実装 → ローカル検証 → push → PR → CI → review → merge
• 道草禁止: 走行中に「ついでに直したい」が出てきたら、別 Issue にメモって本線に戻る
• CI が赤かったら最短で修正、遠回りしない

NG: 走行中にスコープを膨らませる。

📝 Log（走行記録）

完走したら、経験値を残す。

• 想定 vs 実測: 予想コストと実測の差（次回の見積り精度が上がる）
• 舗装発見: 「既に実装済みだった」事実（次回 Survey で即発見できるように）
• 脇道 Issue: Defer した項目の一覧
• 学び: このスキル自体の改善点

記録先（デフォルト運用）

1. Linear Issue コメント or PR description — 想定 vs 実測・舗装発見・defer 項目（その Issue に紐づく運用情報）
2. creo-memories — 横断的に効く学び（case-study + route タグで保存、他プロジェクトから検索できるように）

プロジェクトごとに別運用を置くなら上書き可能だが、明示的に書かない限り上記を既定とする。

ケーススタディ: FSC-22 (2026-04-17)

実例を見る。

Survey

• Issue「やること」6 項目
• Inventory: fleetstage-auth/-billing/-dashboard は既に lib crate（構造要件は既に達成済み）
• Unknown: fleetflowd 側の拡張口は未整備

Plot

path	概要
A: 全部実装	Issue の 6 項目を全て着手、fleetflow 上流にも拡張口を追加
B: 最小スコープ	バイナリ削除 + workspace 整理 + features 追加のみ、上流は別 Issue
C: 放棄	FSC-22 を close、FSC-16/17/18 で都度判断

Compare

path	Cost	Safety	Unblock	YAGNI risk
A	半日〜1日	中（上流にも変更）	全後続解放	高（先に抽象を作る）
B	45分	高	後続も解放	低
C	0	高	解放されない	低

Choose

B を選択。A の「上流拡張口」は FSC-16/17/18 で具体的なユースケースが決まってから別 Issue で対応。

Confirm

ユーザーに「この最小スコープで OK?」と提示、go を受領。

Travel

• ブランチ切り → 実装（バイナリ削除、workspace 整理、features 追加、doc 更新）
• ローカル検証: fmt/clippy/build/test すべてグリーン
• PR #4 → CI 2m3s でグリーン → squash merge
• 所要 45 分 + CI 待ち

Log

• 想定 vs 実測: 半日想定 → 45分。7 倍以上の過大評価
• 舗装発見: fleetstage-* は既に lib crate だった（Inventory 段階で発見）
• 脇道 Issue: fleetflow 上流拡張口は FSC-16/17/18 で必要時に新規 Issue
• 学び: 「lib crate 化」系のタスクは構造確認が先。手を動かす前に [lib] が既にあるか見る

他スキルとの住み分け

スキル	役割	Route との関係
codeflow	開発フロー全体 (Discovery〜Learning)	Route は codeflow の Branch & PR の直前 に挟む補助スキル
spec-design-guide	SDG 文書化	Route は文書化前の「どこまで書くか」を絞る
systematic-debugging	バグ調査	別レイヤー（バグ調査にも Survey 要素はあるが、目的が異なる）
tdd	テスト駆動	Travel フェーズでの実装手法として併用可能

使い方

スラッシュコマンド

/route <issue-id>

指定した Issue に対して Survey → Plot → Compare → Choose まで実行、path 候補を提示する。

暗黙的な発火

大きな Issue に着手するとき、明示コマンドなしでもこのフローを内面化する。「やること」リストを見た瞬間、まず Survey を思い出す。

発火の目安（拘束ルールではなく、迷ったら使う）

• Issue 本文の "やること" チェック項目が 3 個以上
• 見積りの肌感が 半日以上
• 既存コードを触る リファクタ / 再配置 / 削除系
• Epic 配下の子 Issue（親の方向性と整合を取る必要）
• 過去に似た Issue で 見積り超過した経験がある領域

これらを全部満たさなくても、「ちょっと重そう」と感じたら route を発火させるくらいの緩さで OK。逆に「1 行修正の typo fix」みたいな即物タスクには発火しない。

アンチパターン集

Anti-pattern 1: Issue 本文丸呑み

• 症状: Issue の「やること」リストを 1 から順に全実装
• 原因: Inventory を飛ばしている
• 対策: 必ず既存コード確認 → 差分特定

Anti-pattern 2: 1 本道思考

• 症状: path を 1 つしか描かない
• 原因: 「これしかない」という思い込み
• 対策: 必ず 2 本以上描く。描けなければ視野が狭い

Anti-pattern 3: Silent Defer

• 症状: 脇道を黙って放棄、後で「やるはずだった」が失われる
• 原因: フォローアップ Issue を切らずに済ませる
• 対策: Defer した項目は Issue か PR description に必ず記録

Anti-pattern 4: Scope Creep in Travel

• 症状: 実装中に「ついでに」が増え、小さな PR が大きくなる
• 原因: Confirm したスコープからドリフト
• 対策: 走行中の発見は別 Issue にメモ、本線を維持

参考

• ケーススタディ: fleetstage FSC-22 (2026-04-17, PR #4)
• 関連概念: YAGNI, 最短経路, critical path, happy path
• 姉妹スキル: codeflow, spec-design-guide