# Steering

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

- Skill: `majiayu000/steering-3` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/steering-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/steering-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/steering-3

---


# Steering スキル

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

## スキルの目的

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

## 使用タイミング

このスキルは以下のタイミングで使用してください：

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

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

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

### 手順

1. **ステアリングディレクトリの確認**
   ```
   現在の日付を取得し、`.steering/[YYYYMMDD]-[機能名]/` の形式でディレクトリを作成
   ```

2. **永続ドキュメントの確認**
   - `docs/product-requirements.md`
   - `docs/functional-design.md`
   - `docs/architecture.md`
   - `docs/repository-structure.md`
   - `docs/development-guidelines.md`

   これらを読んで、プロジェクトの方針を理解する

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

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

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

4. **tasklist.mdの詳細化**

   requirements.mdとdesign.mdに基づいて、tasklist.mdを詳細化:
   - 各フェーズのタスクを具体的に記述
   - サブタスクも明確に
   - 実装の順序を明記

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

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

### 🚨 重要な原則

**MUST（必須）**:
- tasklist.mdを常に開いた状態で実装
- タスク開始時に必ずEditツールで`[ ]`→`[x]`に更新
- タスク完了時に必ずEditツールで完了を記録
- **tasklist.mdの全タスクが完了するまで作業を継続する**
- NEVER: tasklist.mdを更新せずに次のタスクに進まない

**NEVER（禁止）**:
- tasklist.mdを見ずに実装を進める
- TodoWriteツールだけで進捗管理する（TodoWriteは補助、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を読み込む

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

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

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

tasklist.mdの内容に基づいてTodoWriteツールでタスクリストを作成:
- これはClaude Code内部の補助的なメモ
- **tasklist.mdこそが正式なドキュメント**

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

**3-1. 次のタスクを確認**
```
tasklist.mdを読み、次の未完了タスク（`[ ]`）を特定
```

**3-2. タスク開始をtasklist.mdに記録（必須）**
```
Editツールを使って、tasklist.mdの該当行を`[ ]`→`[x]`に更新

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

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

**3-3. TodoWriteでもステータス更新**
```
TodoWriteツールで該当タスクを"in_progress"に変更
```

**3-4. 実装を実行**
```
開発ガイドライン（docs/development-guidelines.md）に従って実装
```

**3-5. タスク完了をtasklist.mdに記録（必須）**
```
実装完了後、必ずEditツールでtasklist.mdを更新して完了を記録

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

**3-6. TodoWriteでもステータス更新**
```
TodoWriteツールで該当タスクを"completed"に変更
```

**3-7. 次のタスクへ**
```
ステップ3-1に戻る
```

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

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

1. **tasklist.mdを読み込んで進捗確認**
   ```
   Read('.steering/[日付]-[機能名]/tasklist.md')
   ```

2. **完了したタスクを確認**
   - すべてのタスクが`[x]`になっているか
   - 見落としたタスクがないか

3. **ユーザーに報告**
   ```
   「フェーズ1が完了しました。tasklist.mdの進捗を確認してください。」
   ```

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

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

1. **tasklist.mdを読み込む**
   ```
   Read('.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. **最終確認**
   ```
   Read('.steering/[日付]-[機能名]/tasklist.md')
   ```

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

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

### 実装中のセルフチェック

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

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

## モード3: 振り返り

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

### 手順

1. **tasklist.mdを読み込む**
   ```
   Read('.steering/[日付]-[機能名]/tasklist.md')
   ```

2. **振り返り内容を作成**
   - 実装完了日
   - 計画と実績の差分（計画と異なった点）
   - 学んだこと（技術的な学び、プロセス上の改善点）
   - 次回への改善提案

3. **Editツールで更新**
   ```
   tasklist.mdの「実装後の振り返り」セクションを更新
   ```

4. **ユーザーに報告**
   ```
   「振り返りをtasklist.mdに記録しました。内容を確認してください。」
   ```

## トラブルシューティング

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

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

1. **即座に更新を実行**
   ```
   Read('.steering/[日付]-[機能名]/tasklist.md')
   完了したタスクを特定し、すべてEditツールで`[x]`に更新
   ```

2. **ユーザーに報告**
   ```
   「tasklist.mdの更新が遅れていたため、現在の進捗を反映しました。」
   ```

3. **再発防止**
   - 次のタスクから確実に更新する
   - 5タスクごとのセルフチェックを徹底

### tasklist.mdと実装の乖離

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

1. **tasklist.mdに注釈を追加**
   ```
   Editツールで該当タスクに注釈を追加:
   「- [x] タスク名（実装方法を変更: 理由）」
   ```

2. **必要に応じて新しいタスクを追加**
   ```
   Editツールで新しいタスクを追加
   ```

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

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

実装前に必ず確認:

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

実装後に必ず確認:

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

## スキルの効果

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

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

## 重要なリマインダー

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

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

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