Menu
作業をふりかえって改善案を引き出し、記録する。セッション内のすべてのストーリーが完了したとき、依頼者の終わり発話 (作業を区切る発話) を観測したとき、または依頼者が「ふりかえろう」「retrospective」と明示したときに発火。同セッション内で 1 度 skip された場合は再発火しない。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
xp-harness の skill / subagent が意図どおり振る舞えているか (発火するか・あるべき振る舞いができているか) を transcript で事実確認する手順。skill / subagent を改修した後に sandbox で動作検証したいとき、または本番の実運用セッションを「あるべき振る舞い」に照らして分析したいとき、「検証したい」「発火するか確かめたい」「このセッションを分析したい」と言われたときに発火させる。核は発火・振る舞いができたかの事実確認で、本番セッションでは自走の良し悪し (止まり方・判断の質など) も見る。
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。
Git 運用の規律 (branch / worktree 運用、commit / push / pull / rebase / conflict 解決、remote 同期、完了時の統合) を一元的に担う skill。コード変更を伴う依頼・セッション開始・Git 操作の話題のいずれかに該当したら、他より先に必ず最初に使う。ファイルを 1 行でも書き換える依頼なら Git に無関係に見えても発火し、セッション開始・作業再開 (「前回の続き」「何から始めよう」等) でも必ず発火する。発火しないのはコードを読むだけの質問、Git の概念学習質問、doc のサマリ依頼。project 固有ルールでの部分上書きに対応する。
設計判断・ライブラリ選定・アーキ判断・実装アプローチが 2 つ以上ありえる場面で必ず発火させる、「複数案＋メリデメ＋推奨」を提示する横断スキル。「どっちがいい？」「これでいい？」「方針を相談したい」と聞かれたとき、ライブラリ選定・ディレクトリ構成・API 設計・テスト戦略のように選択肢が複数ある相談を受けたとき、要件定義 / 設計 / 実装の中で「複数アプローチがありそう」と感じたときに必ず使う。一案だけポンと出さない。
| name | retrospective |
| description | 作業をふりかえって改善案を引き出し、記録する。セッション内のすべてのストーリーが完了したとき、依頼者の終わり発話 (作業を区切る発話) を観測したとき、または依頼者が「ふりかえろう」「retrospective」と明示したときに発火。同セッション内で 1 度 skip された場合は再発火しない。 |
作業中に気付く改善点を、気付いた時に拾えるサイクルが回っていないと、改善が言語化されないまま流れていく。気づきを引き出して、改善案や取り決めへ書き戻すべき知識・手順を残すまでがこの skill の責務。改善実装そのものは別 skill / 人間判断に委ねる (= 「気づきを出して残す場」であって「直す場」ではない)。
コーディングエージェントのふりかえりでは、人間のふりかえりと違って次の 3 つが効く。これがこの skill の作りを決めている:
進行は対話駆動で dialogue-principles skill のルールに従う。以下は特定の Step でなく、ふりかえり全体を通じて効かせる構え。
skill が呼ばれたら以下を順に回す。各段で上の「構え」を効かせる。
「よかった点 / 伸びしろ」を出す (発散なので短く並べる、深掘りは後段)。main session が先に会話履歴・観察からリストを出し、依頼者が追加 / 削除 / 修正する (= 依頼者は main session の出力に引きずられず、自分の実感を優先して書き換えてよい)。軸は基本「よかった点 / 伸びしろ」の 2 軸、依頼者が「KPT で」「3 軸で」等と指示してきたら柔軟に変える。
表面の出来事だけでなく、働き方を規定する取り決め (skill / subagent / CLAUDE.md・ルール) が適切に働いたか を必ず見る (= エージェントの働き方はそこに刻まれているので、見ないと表面の伸びしろしか拾えない)。観測の幅と深さ:
define-requirements を呼ばなかった」と書く)。当てる観点: 明示的に発火・起動したもの / 「必ず発火」と書かれているのに発火しなかったもの / 呼ぶべきタイミングで呼ばなかったもの / 順序・タイミングのミス / 暗黙適用で済ませたもの / CLAUDE.md・ルールがその場面を導けたか評価の 2 軸と併せて、「取り決めへの書き戻し候補」を第 3 の一覧として出す。よかった点 / 伸びしろが評価のレンズなのに対し、これは収穫のレンズ (= 次セッションに残すべき知識・手順を拾う)。依頼者に「スキルに反映することはないか」と聞かれるのを待たず、観測の一部として必ず出す (= 依頼者の聞き忘れで知識が消えるのを防ぐ):
観測リストの中から、依頼者が深掘りしたいトピックを選ぶ。
選んだトピックに「なんで?」を投げて根本原因を引き出す。ここで「構え」の正直さを強く効かせる。
深掘りの結果として改善案を出す、または分析だけで終わる。
改善案は docs/working/<title>/ふりかえり.md に記録する。
<title> ディレクトリ = 1 ファイル<title> は要件定義 / 基本設計と同じディレクトリ規約 (= 機能を表すケバブケース)# <title> ふりかえり
## YYYY-MM-DD: [このふりかえりのタイトル]
### サマリ
[1-3 行、今回のふりかえりの位置付け]
### トピック一覧
よかった点:
- ...
伸びしろ:
- ...
取り決めへの書き戻し候補:
- [どの取り決め (どの skill / subagent / ルール)] に [何を書き戻すか]
[0 件なら (なし)]
### 深掘り 1: [深掘りしたトピックの名前]
#### 経緯
[作業 / 議論の流れ]
#### 分析
[原因 / 課題 / 構造的問題]
#### アクション
[次に試すこと、0 件なら (なし)]
### 深掘り 2: [別のトピックの名前]
...
## YYYY-MM-DD: [タイトル] で 1 セッションのふりかえりを区切る