steering

name	steering
description	作業指示毎の作業計画、タスクリストをドキュメントに記録するためのスキル。ユーザーからの指示をトリガーとした作業計画時、実装時、検証時に読み込む。
user-invocable	false

Steering スキル

ステアリングファイル（.steering/）に基づいた実装を支援し、 tasklist.mdの進捗管理を確実に行うスキル。

スキルの目的

• ステアリングファイル（requirements.md, design.md, tasklist.md）の作成支援
• tasklist.mdに基づいた段階的な実装管理
• 進捗の自動追跡とtasklist.md更新の強制
• 実装完了後の振り返り記録

使用タイミング

このスキルは以下のタイミングで使用すること：

1. 作業計画時: ステアリングファイルを作成する時
2. 実装時: tasklist.mdに従って実装する時
3. 検証時: 実装完了後の振り返りを記録する時

モード1: ステアリングファイル作成

目的

新しい機能や変更のためのステアリングファイルを作成する。

手順

1. ステアリングディレクトリの確認

   現在の日付を取得し、`.steering/[YYYYMMDD]-[機能名]/`
   の形式でディレクトリを作成
   

2. 永続ドキュメントの確認

   この手順は現状スキップする。

3. テンプレートからファイル作成

   このSKILL.mdと同じディレクトリのassets/配下にある 以下のテンプレートをファイル読み込みツールで読み込み、 プレースホルダーを具体的な内容に置き換えてファイルを作成:

   • assets/requirements.md → .steering/[日付]-[機能名]/requirements.md
   • assets/design.md → .steering/[日付]-[機能名]/design.md
   • assets/tasklist.md → .steering/[日付]-[機能名]/tasklist.md

4. requirements.md, design.md, tasklist.mdの内容生成

   .docsディレクトリのその機能のideasディレクトリ配下の ファイルの内容を読み取り、 それをもとにrequirements.mdやdesign.mdの内容を生成する。 その際、生成したものをユーザに確認してもらい、 必要に応じてユーザと議論しながら完成させる。 なお、ideasディレクトリ内のファイルはメモベースであり 完全な仕様となっているとは限らないので、 実装のために必要な検討事項があったり より明確化する必要がある箇所がある、 テストや検証用の実行コマンドが不明などがもしあれば、 ユーザに確認や決定を依頼しながら、 実装に必要な情報が揃うまでブラッシュアップを続けること。 requirements.mdとdesign.mdが出来たら、 それらに基づいてtasklist.mdを詳細化:

   • 各フェーズのタスクを具体的に記述
   • サブタスクも明確に
   • 実装の順序を明記
   • 実装タスクについては /tdd-workflow に基づき、 TDDプロセスを意識したタスクにすること
   • 実装タスクの単位はクラスごととかメソッドごととかで 考えるのではなく、1つの意思決定単位とする （結果的にそうなるのは良い）
   • コミットは1つの意思決定単位のタスクごとに、 ユーザがコードを確認したあと問題なければ ユーザ自身が行う。その際、コミットメッセージについては ユーザに提案する。

   tasklist.mdについても、出来たらユーザと対話しながら ブラッシュアップして完成させる。

モード2: 実装（最重要）

目的

tasklist.mdに従って実装を進め、 進捗を確実にドキュメントに記録する。

重要な原則

MUST（必須）:

• tasklist.mdを常に開いた状態で実装
• タスク開始時に必ずファイル編集ツールで[ ]→[-]に更新し 仕掛中と分かるようにする
• タスク完了時にはユーザに承認を求める。 承認を得られたら、必ずファイル編集ツールで[-]→[x]に更新し 完了を記録する
• tasklist.mdの全タスクが完了するまで作業を継続する
• NEVER: tasklist.mdを更新せずに次のタスクに進まない
• NEVER: ユーザの承認の無いまま勝手にタスクを完了にしない

NEVER（禁止）:

• tasklist.mdを見ずに実装を進める
• タスク管理ツールだけで進捗管理する （タスク管理ツールは補助、tasklist.mdが正式）
• 複数タスクをまとめて更新する（リアルタイムに更新する）
• 「時間の都合により」「別タスクとして実施予定」などの 理由でタスクをスキップする
• 未完了タスク（[ ]）を残したまま作業を終了する

タスク完全完了の原則

絶対に守るべきルール:

1. tasklist.mdの全タスクが完了するまで作業を継続すること

   • 全てのタスクが[x]になるまで実装を継続
   • 「時間がかかりすぎる」「難しい」などの理由で スキップしない
   • 未完了タスクがある状態で振り返りを書かない

2. タスクスキップは原則禁止

   • 「時間の都合により別タスクとして実施予定」は禁止
   • 「実装が複雑すぎるため後回し」は禁止
   • 「難しいから後で」「テストが面倒」などの理由は禁止
   • スキップが許可されるのは技術的な理由のみ（下記参照）

3. タスクが大きすぎる場合の対処法

   • タスクを小さなサブタスクに分割する
   • 分割したサブタスクをtasklist.mdに追加
   • サブタスクを1つずつ完了させる

4. 技術的な理由でタスクが不要になった場合のみスキップ許可

   以下の技術的理由に該当する場合のみスキップ可能:

   • 実装方針の変更により、機能自体が不要になった
   • アーキテクチャ変更により、別の実装方法に置き換わった
   • 依存関係の変更により、タスクが実行不可能になった

   スキップ手順:

   • tasklist.mdに技術的な理由を明記して スキップマークを付ける
   • 例: - [x] ~~タスク名~~（実装方針変更により不要: アーキテクチャをXからYに変更したため、 このレイヤーが不要になった）
   • 振り返りセクションに変更理由を詳細に記録

5. 未完了タスクが残っている場合のNG例

   ## 実装後の振り返り
   
   **実装しなかったタスク**:
   
   - テストの実装（時間の都合により別タスクとして
     実施予定） ← 絶対にダメ
   

6. 正しい完了の形

   • 全タスクが[x]
   • 振り返りセクションに 「実装しなかったタスク」の記述がない
   • 実装方針の変更があれば、その理由が明記されている

実装フロー

ステップ1: tasklist.mdを読み込む

ファイル読み込みツールで '.steering/[日付]-[機能名]/tasklist.md' を読み込む

全体のタスク構造を把握し、次に着手すべきタスクを特定する。

ステップ2: タスク管理ツールで管理開始

tasklist.mdの内容に基づいてタスク管理ツールで タスクリストを作成:

• これはAIエージェント内部の補助的なメモ
• tasklist.mdこそが正式なドキュメント

ステップ3: タスクループ（各タスクで繰り返す）

3-1. 次のタスクを確認

tasklist.mdを読み、次の未完了タスク（`[ ]`）を特定

3-2. タスク開始をtasklist.mdに記録（必須）

ファイル編集ツールを使って、tasklist.mdの該当行を
仕掛中に更新(`[ ]`→`[-]`)

例:
old_string: "- [ ] StorageServiceを実装"
new_string: "- [-] StorageServiceを実装"

重要: ファイル編集ツールを実行した直後に、 更新が成功したことを確認する。

3-3. タスク管理ツールでもステータス更新

タスク管理ツールで該当タスクを"in_progress"に変更

3-4. 実装を実行

開発ガイドライン（docs/development-guidelines.md）に
従って実装（存在しない場合も現状気にしない）

3-5. タスク完了をtasklist.mdに記録（必須）

実装完了後、ユーザに確認を依頼する。
承認されれば、必ずファイル編集ツールでtasklist.mdの
当該タスクを仕掛中から完了に更新する(`[-]`→`[x]`)

例:
old_string: "- [-] StorageServiceを実装"
new_string: "- [x] StorageServiceを実装"

サブタスクがある場合はサブタスクも個別に更新する。

3-6. タスク管理ツールでもステータス更新

タスク管理ツールで該当タスクを"completed"に変更

3-7. タスク完了後、更新した方が良いドキュメントがあれば更新

タスクを実行時にユーザとの対話の結果などで、
design.md, requirements.md, tasklist.mdの内容を
更新した方が良い場合は、忘れずに更新しておくこと。

3-8. 次のタスクへ

ステップ3-1に戻る

ステップ4: フェーズ完了時の確認

各フェーズ（例: フェーズ1、フェーズ2）が完了したら:

1. tasklist.mdを読み込んで進捗確認

   ファイル読み込みツールで '.steering/[日付]-[機能名]/tasklist.md'
   を読み込む
   

2. 完了したタスクを確認

   • すべてのタスクが[x]になっているか
   • 見落としたタスクがないか

3. ユーザーに報告

   「フェーズ1が完了しました。
   tasklist.mdの進捗を確認してください。」
   

ステップ4.5: 全タスク完了チェック（必須）

全フェーズの実装完了後、振り返りを書く前に必ず実行:

1. tasklist.mdを読み込む

   ファイル読み込みツールで '.steering/[日付]-[機能名]/tasklist.md'
   を読み込む
   

2. 未完了タスク（[ ]）がないか確認

   • 全てのタスクが[x]になっているか？
   • 1つでも[ ]が残っていないか？

3. 未完了タスクが見つかった場合

   やってはいけないこと:

   • 「時間の都合により別タスクとして実施予定」と 振り返りに書く
   • 未完了タスクを無視して次のステップに進む

   正しい対処法:

   パターンA: タスクを実装する

   ステップ3（タスクループ）に戻り、
   未完了タスクを実装する
   

   パターンB: タスクが大きすぎる場合

   1. タスクを小さなサブタスクに分割
   2. tasklist.mdに分割したサブタスクを追加
   3. サブタスクを1つずつ完了させる
   

   パターンC: 技術的な理由でタスクが不要になった場合のみ

   以下の技術的理由に該当する場合のみスキップ可能:

   • 実装方針の変更により、機能自体が不要になった
   • アーキテクチャ変更により、別の実装方法に置き換わった
   • 依存関係の変更により、タスクが実行不可能になった

   スキップ手順:

   1. tasklist.mdに技術的な理由を明記:
      「- [x] ~~タスク名~~（実装方針変更により不要:
      具体的な技術的理由を詳細に記述）」
   2. 振り返りセクションに変更理由を詳細に記録
   3. なぜこのタスクが不要になったのか、
      何に置き換わったのかを明確に記述
   

4. 全タスク完了を確認できた場合のみ次へ

   全てのタスクが`[x]`になっていることを確認してから
   ステップ5へ進む
   

ステップ5: 全タスク完了後

1. 最終確認

   ファイル読み込みツールで '.steering/[日付]-[機能名]/tasklist.md'
   を読み込む
   

   すべてのタスクが[x]になっていることを確認

2. 振り返りセクションに記録

   ファイル編集ツールでtasklist.mdの
   「実装後の振り返り」セクションを更新:
   - 実装完了日
   - 計画と実績の差分
   - 学んだこと
   - 次回への改善提案
   

実装中のセルフチェック

5タスクごとに以下を確認:

• tasklist.mdを最近更新したか？ （最後の更新から5タスク以内）
• 進捗がドキュメントに反映されているか？ （ファイル読み込みツールで確認）
• ユーザーがtasklist.mdを見て進捗が分かるか？

モード3: 振り返り

目的

実装完了後、tasklist.mdに振り返りを記録する。

手順

1. tasklist.mdを読み込む

   ファイル読み込みツールで '.steering/[日付]-[機能名]/tasklist.md'
   を読み込む
   

2. 振り返り内容を作成

   • 実装完了日
   • 計画と実績の差分（計画と異なった点）
   • 学んだこと（技術的な学び、プロセス上の改善点）
   • 次回への改善提案

3. ファイル編集ツールで更新

   tasklist.mdの「実装後の振り返り」セクションを更新
   

4. ユーザーに報告

   「振り返りをtasklist.mdに記録しました。
   内容を確認してください。」
   

トラブルシューティング

tasklist.mdの更新を忘れた場合

もし実装中にtasklist.mdの更新を忘れていることに 気づいたら:

1. 即座に更新を実行

   ファイル読み込みツールで '.steering/[日付]-[機能名]/tasklist.md'
   を読み込む
   完了したタスクを特定し、
   すべてファイル編集ツールで`[x]`に更新
   

2. ユーザーに報告

   「tasklist.mdの更新が遅れていたため、
   現在の進捗を反映しました。」
   

3. 再発防止

   • 次のタスクから確実に更新する
   • 5タスクごとのセルフチェックを徹底

tasklist.mdと実装の乖離

計画と実装が大きく異なる場合:

1. tasklist.mdに注釈を追加

   ファイル編集ツールで該当タスクに注釈を追加:
   「- [x] タスク名（実装方法を変更: 理由）」
   

2. 必要に応じて新しいタスクを追加

   ファイル編集ツールで新しいタスクを追加
   

3. design.mdも更新

   設計の変更が大きい場合はdesign.mdも更新
   

チェックリスト（最重要）

実装前に必ず確認:

• tasklist.mdを読み込んだか？
• 次のタスクを特定したか？
• タスク開始時にファイル編集ツールで更新したか？

実装後に必ず確認:

• タスク完了時にファイル編集ツールで更新したか？
• tasklist.mdの進捗を確認したか？
• ユーザーが見て進捗が分かる状態か？

スキルの効果

このスキルを正しく使用すると:

• tasklist.mdが常に最新の進捗を反映
• ユーザーが進捗を一目で把握できる
• ドキュメントと実装の乖離がなくなる
• 振り返りが容易になり、次回の改善につながる
• プロジェクト履歴として価値がある記録が残る

重要なリマインダー

このスキルの最も重要な役割は、 tasklist.mdの進捗管理を確実に行うことである。

• タスク管理ツールは揮発的なメモ （ユーザーには見えない）
• tasklist.mdこそが永続的なドキュメント （ユーザーが見る）

実装中は常に「ユーザーがtasklist.mdを見たときに 進捗が分かるか？」を自問すること。