AgentSkillsCN

steering

为每项作业计划与任务清单建立文档记录的技能。在接收到用户指令后，于作业计划、实现与验证阶段及时加载相关文档。

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

Steering スキル

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

スキルの目的

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

使用タイミング

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

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

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

目的

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

手順

  1. •

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

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

    永続ドキュメントの確認

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

  3. •

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

    以下のテンプレートを読み込み、プレースホルダーを具体的な内容に置き換えてファイルを作成:

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

    ※ リポジトリ内で見つけられない場合はホームディレクトリの.geminiディレクトリ配下にある可能性がある。

  4. •

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

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

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

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

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

目的

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

🚨 重要な原則

MUST（必須）:

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

NEVER（禁止）:

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

🚨 タスク完全完了の原則

絶対に守るべきルール:

  1. •

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

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

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

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

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

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

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

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

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

    スキップ手順:

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

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

    markdown
    ## 実装後の振り返り

**実装しなかったタスク**:

- テストの実装（時間の都合により別タスクとして実施予定） ❌ 絶対にダメ
  6. •

    正しい完了の形

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

実装フロー

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

code
read_file('.steering/[日付]-[機能名]/tasklist.md')

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

ステップ2: write_todosでタスク管理開始

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

  • •これはGemini CLI内部の補助的なメモ
  • •tasklist.mdこそが正式なドキュメント

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

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

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

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

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

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

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

3-3. write_todosでもステータス更新

code
write_todosツールで該当タスクを"in_progress"に変更

3-4. 実装を実行

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

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

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

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

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

3-6. write_todosでもステータス更新

code
write_todosツールで該当タスクを"completed"に変更

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

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

3-8. 次のタスクへ

code
ステップ3-1に戻る

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

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

  1. •

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

    code
    read_file('.steering/[日付]-[機能名]/tasklist.md')
  2. •

    完了したタスクを確認

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

    ユーザーに報告

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

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

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

  1. •

    tasklist.mdを読み込む

    code
    read_file('.steering/[日付]-[機能名]/tasklist.md')
  2. •

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

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

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

    ❌ やってはいけないこと:

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

    ✅ 正しい対処法:

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

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

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

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

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

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

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

    スキップ手順:

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

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

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

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

  1. •

    最終確認

    code
    read_file('.steering/[日付]-[機能名]/tasklist.md')

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

  2. •

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

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

実装中のセルフチェック

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

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

モード3: 振り返り

目的

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

手順

  1. •

    tasklist.mdを読み込む

    code
    read_file('.steering/[日付]-[機能名]/tasklist.md')
  2. •

    振り返り内容を作成

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

    replaceツールで更新

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

    ユーザーに報告

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

トラブルシューティング

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

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

  1. •

    即座に更新を実行

    code
    read_file('.steering/[日付]-[機能名]/tasklist.md')
完了したタスクを特定し、すべてreplaceツールで`[x]`に更新
  2. •

    ユーザーに報告

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

    再発防止

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

tasklist.mdと実装の乖離

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

  1. •

    tasklist.mdに注釈を追加

    code
    replaceツールで該当タスクに注釈を追加:
「- [x] タスク名（実装方法を変更: 理由）」
  2. •

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

    code
    replaceツールで新しいタスクを追加
  3. •

    design.mdも更新

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

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

実装前に必ず確認:

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

実装後に必ず確認:

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

スキルの効果

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

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

重要なリマインダー

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

  • •write_todosは揮発的なメモ（ユーザーには見えない）
  • •tasklist.mdこそが永続的なドキュメント（ユーザーが見る）

実装中は常に「ユーザーがtasklist.mdを見たときに進捗が分かるか？」を自問してください。