retrospective

Hikyaku Retrospective

セッション全体を振り返り、改善提案を分類・記録する。

このスキルは hikyaku:planner / hikyaku:architect / hikyaku:builder からモデル呼び出しで使用される内部スキルです。 ユーザーが直接呼び出すことは想定していません。hikyaku ワークフロー以外のコンテキストから呼び出された場合は、その旨をユーザーに伝えて終了してください。

引数

• $ARGUMENTS[0]: DOC_ROOT — ワークフロードキュメントのルートパス
• $ARGUMENTS[1]: SUB_DIR — 振り返りファイルを出力するサブディレクトリ（planning, architecture, build-{NN}）

出力先: $ARGUMENTS[0]/$ARGUMENTS[1]/retrospective.md

作業ステップ

Step 0: 設定の確認

• リポジトリルートの .hikyaku.config を読み込む（存在する場合のみ）
  • retrospective の設定値を取得する（未設定の場合は prompt）

設定値に応じて動作を決定する:

• skip: 振り返りをスキップし、呼び出し元に制御を返す
• auto: ユーザーへの確認をスキップして Step 2 へ進む
• prompt（デフォルト）: Step 1 へ進む

Step 1: ユーザーに振り返りの実施を確認

• ユーザーに振り返りを実施するか確認する

振り返りを実施しますか？（y/n）
振り返りではセッション中のスキル外指示を分析し、スキルやインストラクションの改善提案を作成します。

→ 実施する場合は Step 2 へ。不要な場合は振り返りをスキップし、呼び出し元に制御を返す。

Step 2: コンテキストの把握

• SUB_DIR からどのフェーズの振り返りかを判定する
  • planning → 企画フェーズ（ヘッダー: 企画フェーズ 振り返り）
  • architecture → 設計フェーズ（ヘッダー: 設計フェーズ 振り返り）
  • build-{NN} → 実装フェーズ（ヘッダー: Build {NN}: {ビルド名} 振り返り、issue.md からビルド名を取得）
• 出力先に既に retrospective.md が存在するか確認する（存在する場合は追記モード）

→ Step 3 へ。

Step 3: 会話履歴の分析

• 会話履歴を見直し、以下を洗い出す:
  • スキルの手順に含まれていないが、ユーザーから受けた指示・修正・補足
  • スキルの手順通りに進めたが、うまくいかなかった点
  • 実装フェーズの場合: PRレビューで指摘された設計・実装上の見落とし

→ Step 4 へ。

Step 4: 改善提案の作成と対象の分類

• Step 3 で洗い出した内容から改善提案を作成する
• 各提案について、以下の判断フローに従って対象を分類する

判断フロー:

Q1: この改善は、Hikyaku を別のリポジトリで使っても同じく必要か？
  → Yes → 対象: skill:{該当スキル名}
  → No ↓
Q2: この改善は、Hikyaku 以外の AI 作業（通常のコーディング等）にも適用されるか？
  → Yes → 対象: repo:{ファイル名}
  → No ↓
Q3: この改善は、このリポジトリの Hikyaku ワークフロー全体（複数フェーズ）に適用されるか？
  → Yes → 対象: workflow:instruction.md
  → No ↓
Q4: 今後、同様の状況が再発する可能性があるか？
  → Yes → Q1〜Q3 を再検討（スコープの見誤りの可能性がある）
  → No → 対象: 記録のみ

各分類の詳細:

対象	意味	具体案の記述内容
skill:{スキル名}	Hikyaku スキル自体の修正	修正対象のスキル名とファイルパス（SKILL.md / references/ 等）を明記し、変更内容の文面案を書く
repo:{ファイル名}	リポジトリのインストラクション修正	対象ファイル名（CLAUDE.md, AGENTS.md 等）を明記し、追記内容の文面案を書く
workflow:instruction.md	ワークフロー固有のインストラクション修正	instruction.md に追記する内容の文面案を書く
記録のみ	一回限りの事象で一般化できない	記録理由を簡潔に書く

判断に迷ったときの指針:

• コーディング規約・テスト方針・PR作成ルールなど → 多くの場合 repo:
• 特定の技術スタック・ドメイン知識 → 多くの場合 workflow:
• ワークフローの手順・テンプレート・判断基準 → 多くの場合 skill:

→ Step 5 へ。

Step 5: retrospective.md の書き込み

• retrospective.md を以下のテンプレートに従って作成する

新規作成の場合:

# {フェーズヘッダー}

## セッション中にスキル外で受けた指示

（スキルの手順に含まれていないが、ユーザーから受けた指示・修正・補足を列挙する。
　スキル外の指示がなかった場合は「なし」）

## 改善提案

### R-1: （改善タイトル）
- **状況**: （どのステップで、どんな状態のときに発生したか）
- **指示内容**: （ユーザーからどんな指示・修正・補足があったか）
- **提案**: （何をどう改善すべきか）
- **優先度**: Must / Should / Could
- **対象**: （分類から選択）
- **具体案**: （対象ファイルに追記・修正する内容の文面案）

### R-2: ...

フェーズヘッダーは Step 2 で判定したものを使う（例: 企画フェーズ 振り返り, Build 01: {ビルド名} 振り返り）。

追記モードの場合（PRレビュー対応）: 既存の末尾に以下のセクションを追加する。R-N の番号は既存の改善提案の続きから採番する。

## PRレビュー対応の振り返り

### セッション中にスキル外で受けた指示

（なければ「なし」）

### 改善提案

#### R-N: （改善タイトル）
- **状況**: （どのステップで、どんな状態のときに発生したか）
- **指示内容**: （ユーザーからどんな指示・修正・補足があったか）
- **提案**: （何をどう改善すべきか）
- **優先度**: Must / Should / Could
- **対象**: （分類から選択）
- **具体案**: （対象ファイルに追記・修正する内容の文面案）

• 振り返りをユーザーに提示し、呼び出し元に制御を返す

記載ガイドライン

• スキルの手順通りに進んだ部分は書かない。差分だけを記録する
• 「スキル外で受けた指示」が最重要のインプット。ユーザーが追加で指示したことは、スキルに欠けている情報の証拠
• 具体案は、そのまま適用できるレベルの具体性で書く
• 改善提案がなければ「改善提案なし」と記載する