菜单
作業をふりかえって改善案を引き出し、記録する。セッション内のすべてのストーリーが完了したとき、依頼者の終わり発話 (作業を区切る発話) を観測したとき、または依頼者が「ふりかえろう」「retrospective」と明示したときに発火。同セッション内で 1 度 skip された場合は再発火しない。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 セッションのふりかえりを区切る