【必須】現在のアクティビティを完了にする、または完了にせず中断して寝かせる。「/af」「この作業完了」「クローズして」「一旦ここまで」「今日はここで止める」「いったん置いておく」など終える・中断する意図で発動。このスキルを経由せずにupdate_activityでcompleted・pending・snoozed・shelvedにしない。
postmortem
完了したアクティビティの行動を1ステップずつ振り返り、教訓を永続化する。「ポストモーテムやろう」「振り返りしたい」「反省会」などで発動。
実行スコア 未検証
インストール方法を見る含まれるファイル(1)
- SKILL.md5.6 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
ポストモーテム
completedアクティビティの行動を時系列で振り返り、ユーザーと対話しながら教訓を抽出・永続化する。
関連skillとの境界
- 「この作業を振り返りたい」のような、完了した作業の振り返りの依頼で使う
- 完了操作そのもの(activity-finish)と記録の同期(sync-memory)では発動しない
1. 対象アクティビティの選択
- 引数で
activity_idが指定されていればそのまま使う - 指定されていなければ
get_activities(status="completed", limit=15)で一覧を表示し、ユーザーに選んでもらう - 一覧はタイトルのみで提示し、内部IDは表示しない
2. ポストモーテムアクティビティの作成
対象が決まったら:
- 新しいアクティビティを作成:
- タイトル:
[振り返り] {元アクティビティ名}のポストモーテム - タグ:
intent:discuss,振り返り, + 元アクティビティのdomain:タグを引き継ぐ related: 元アクティビティとリレーションを張る([{"type": "activity", "ids": [元アクティビティID]}])
- タイトル:
- check-in する
3. データ収集とステップ分解
対象アクティビティに関連するデータを収集する:
- check-in結果の
related_topicsからtopic_idを取得する。related_topicsが空の場合は、アクティビティのタグでsearchするか、ユーザーに関連トピックを確認する get_logs(entity_type="topic", entity_id=topic_id)でログを取得get_decisions(entity_type="topic", entity_id=topic_id)で決定事項を取得get_map(entity_type="activity", entity_id=...)で関連エンティティを探索し、追加の情報源がないか確認するsearch(entity_type="material")/get_materialで資材を確認
データ不足の判定
ログが2件以下、かつdecisionも1件以下の場合:
データが少なくて、ステップ分解が難しいかも。
ログ: {N}件 / decision: {N}件
このまま進める?(ユーザーが口頭で補足しながらやることもできる)
ユーザーが続行を選んだ場合は、ユーザーに「何をやったか」を聞きながら手動でステップを組み立てる。
ステップ一覧の作成
ログを時系列で読み、行動の切れ目でステップに分解する。以下のフォーマットで全ステップの一覧を先に提示する:
## ステップ一覧
1. {ステップ名} — {1行の概要}
2. {ステップ名} — {1行の概要}
3. ...
この分け方で進める?追加・統合・分割があれば言って。
ユーザーの確認を待ってから次に進む。
4. ステップごとのレビュー
エージェントは材料を並べる係に徹し、評価はユーザーに先に出してもらう。1ステップずつ、以下の構成で提示する:
### ステップ {N}: {ステップ名}
**何があったか**:
{ログから読み取れる事実を時系列で要約}
**補足コンテキスト**:
{検討した代替案、関連decision、当時の制約条件など。なければ省略}
ここ振り返ってみてどう?
- エージェントは事実と文脈を提示するが、よかった/悪かったの評価は書かない
- ユーザーが意見を述べ始めたら、エージェントも自分の見解を出してよい
- 「ここは別のやり方もあった?」「この判断の背景って何だった?」など、振り返りを深める問いかけを使う
ユーザーの発言は次ステップに進む前にログとして記録する。
5. 反省ポイントまとめ
全ステップのレビューが終わったら、反省ポイントを一覧で出す:
## 反省ポイントまとめ
### よかったこと
- ...
### 改善したいこと
- ...(各項目に「なぜ起きたか」の1行分析を添える)
この一覧を add_material でポストモーテムアクティビティに保存する。
6. 教訓の永続化
最後に、改善したいことの中から次に活かせる教訓をどう永続化するか議論する。
永続化の手段はケースバイケース。以下は選択肢の例:
- tag notes: 特定のintentやdomainに遭遇したときに自動注入されるルール
- decision: トピックに紐づく合意事項
- auto memory (feedback): Claude Codeのセッション横断で適用される行動ルール
- CLAUDE.md: プロジェクト全体に適用されるルール
- 新しいintentタグ: 行動パターンが根本的に異なる場合
エージェントは選択肢を提示するが、何をどこに落とすかはユーザーが決める。
永続化が完了したら、ポストモーテムアクティビティの description に結論を追記し、ステータスを completed にする。
注意事項
- 急がない。1ステップずつ丁寧に。ユーザーが「次」と言うまで進まない
- エージェントの評価を押し付けない。「ここは問題だった」ではなく「ここ気になったんだけど、どう思う?」
- ユーザーの発言はできるだけ原文に近い形でログに残す
- セッション跨ぎの可能性があるので、進捗はこまめにログ記録する
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
コメント
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
同じリポジトリのスキル
【必須】新しいアクティビティを作成してcheck-inする。「/as」「新しい作業始める」「アクティビティ作って」「これやる」など新規作業の開始で発動。このスキルを経由せずにadd_activityを呼ばない(orchの起票はorch skillに従う)。
【必須】open askを1件ずつ人間に提示し、回答をanswer_askで記録する。「askに答える」「open ask消化して」「溜まってるask片付けたい」などで発動。このスキルを経由せずにanswer_askを呼ばない。
【必須】add_askでaskを起票する前に、question/contextをテンプレートで組み立てる。離席中・セッション跨ぎでしか答えられない判断が出たときや、「これ聞いといて」「判断委譲しといて」「後で確認して」などで発動。このスキルを経由せずにaskの文面を書かない(メタaskを除く)。
add_askの応答のsimilar_asksを見て、同型の問いが繰り返され裁定が一貫していると気づいたとき、判例をまとめてメタask(kind="meta")を起票する。
人間の判断待ちaskの受け箱をMonitorで監視し、判断構造が同じopen askが溜まっていればメタaskを起票する。「ask storeを監視して」「asksを見張って」「open askの滞留をチェックして」などで発動。