end-session

セッションを終了する

セッションを締めくくり、次のセッションが状況を再構築するのではなく、正確な把握から始められるようにします。セッションの永続的な成果は差分だけではありません。何を学んだか（メモリ）、何を動かしたか（課題とボード）、今後人間が行う必要のあること（フォローアップ）、現在の状態と食い違うドキュメント、そして残したもの（ワークスペース）も含まれます。この順に確認します。

開始時に伝える：「セッション終了スキルを使って、このセッションを締めくくります。」

シェルのスニペットは bash（Windows では Git Bash）で実行します。gh が使えない場合は、同等の GitHub MCP 操作を使います。CLI がない場合に変わるのはインターフェースであり、手順ではありません。

このスキルでは、リリース作業を ship スキルに任せます。バージョンの更新、変更履歴のセクション追加、ソースのプッシュ、PR の作成は行いません。完了したブランチは、まずリリースしてからこのスキルを実行します。作業途中のブランチはその状態のままとし、現在の状況を記録します。

全工程を通じて、次の3つのルールを守ります。

• 記憶ではなく、根拠を示します。 該当するものがなくても問題ありません。その旨を記して先に進みます。作り上げたメモリ、コメント、記録は、何も残さないことより悪い結果になります。
• 削除する前に一覧を示します。 ファイル、ブランチ、ワークツリー、コンテナーを削除する場合は、必ず一覧を提示して、承認を待ちます。
• コミットまたは破棄する前に確認します。 設定によってあらかじめ許可されている場合を除きます。

0. 設定

このスキルでは、docs/agents/workspace.md、docs/agents/issue-tracker.md、docs/agents/human-follow-up.md、docs/agents/docs.md を読みます。.agents/skills/end-session/settings/README.md に従ってそれらを読み、不足しているものがあれば補完します。定義ファイルはその隣にあります。各 discover: の値はここで一度だけ解決し、以下で再利用します。

ハンドオフから起動された場合： 引数に invoked by handoff; document at <path> とある場合、ハンドオフ文書はすでに作成され、登録されています。そのパスをレポートに引き継ぎ、ユーザーの作業はこのチェックアウトではなく、別のマシンで継続しているものとして扱います。

1. 現状を把握する

何かを書き込む前に、このセッションで行ったことを確認します。

git status --short --branch
git branch --show-current
git log --oneline origin/main..HEAD
gh pr list --author @me --state open --json number,title,headRefName

続いて、Workspace status command を実行します。このセッションで作成したものを以下のカテゴリに分類し、それぞれ後続の手順に振り分けます。

カテゴリ	手順
このリポジトリまたは環境での作業方法に関する永続的な事実	2. メモリ
開始、完了、ブロック、発見された作業、または理解が変わった内容	3. 課題
現時点で人間だけが実行できる操作	4. 人間のフォローアップ
ドキュメントに記録すべき決定事項、調査結果、状態の変更	5. ドキュメント
残したファイル、ブランチ、ワークツリー、コンテナー	6. ワークスペース

2. メモリ

メモリはリポジトリの外に、1ファイルにつき1つの事実を記録します。ハーネスの指示で指定されたメモリディレクトリを使用してください。指定されたパスをそのまま使います。チェックアウトの場所から導き出したパスは、マシンやツールによって異なります。誤った場所への書き込みはエラーにならず、二度と読み込まれません。ハーネスがメモリディレクトリを指定していない場合は、この手順を省略し、レポートにその旨を記します。そこにある MEMORY.md はインデックスです。各メモリにつき1行だけ記載し、内容は書きません。

ここで新しいセッションを始めた人が、そのメモなしでは誤った判断をする場合に限り、かつリポジトリ内にすでに記録されていない場合にのみ、候補を保存します。AGENTS.md、ドキュメント、課題トラッカー、変更履歴、Git の履歴は永続的な記録です。それらを言い換えたメモリは、内容が変更された時点で古くなります。メモリには、時間を浪費させた落とし穴、ユーザーが伝えた希望、結論が出ていない作業の状態など、どこにも書かれていないことを記録します。

• まず MEMORY.md を読み、似た内容のメモリを追加するのではなく、該当する既存メモリを更新します。
• このセッションで誤りが判明したメモリは訂正または削除します。
• 日付は絶対日付で記載し、関連するメモリは [[slug]] でリンクします。MEMORY.md の各参照先がファイルと一致するようにします。
• 未修正のセキュリティ上の弱点をメモリ本文に記録してはいけません。追跡されている場所を示します。

3. Issue とボード

作業内容は Issue に記録し、その状態は Board で管理します。ラベルには、リポジトリのトリアージ用ラベル語彙（docs/agents/triage-labels.md、またはそれを記載している docs/agents/issue-tracker.md のセクション）を使用します。

ボードへの書き込みには gh トークンの project スコープが必要で、スコープがない場合は何も表示されずに失敗します。gh auth status で project を確認してください（read:project だけでは不十分です）。スコープが不足している場合はその旨を報告し、ボードへの書き込みはスキップしてください。修正コマンド（gh auth refresh -h github.com -s project）の実行には実際のターミナルが必要です。

未完了の作業から始めます。Public repository と、存在する場合は Private issue repository の両方を、必ず -R で明示的に選択してください。

gh issue list -R <repository> --state open --json number,title,labels \
  --jq '[.[] | {number, title, labels: [.labels[].name]}]'

セッションで扱った各 Issue について、次の対応を行います。

• 完了 — 結果と、問題への理解がどう変わったかをコメントします。PR がマージされたら Issue をクローズします。PR がオープンの間は Issue をオープンのままにし、PR を明記します。
• 進展したが未完了 — 現状と次の具体的な手順を、初めて読む人にも分かるようにコメントします。
• ブロック中 — ブロッカーをコメントし、それを記録する Board fields を設定します。
• 理解が変わった — 本文を修正するか、修正内容をコメントします。誤った問題を記述した Issue は、Issue がない場合より大きな損失になります。
• 新たに見つかった作業 — New work の手順に従って記録します。Issue を作成してラベルを付け、Board に追加するか、Board のドラフト項目（gh project item-create）として残し、その作業を引き受ける段階で Issue にします。どちらの場合もボードのフィールドを設定します。ボードに記録されない作業は、次のセッションから見えません。

セキュリティ上の問題は Security findings の手順に従います。修正がリリースされる前に公開 Issue にしてはいけません。プライベートリポジトリへのリンクやその内容を、公開 Issue、PR、コミットに含めないでください。セッションで扱っていない Issue は triage スキルに任せます。

4. 人間によるフォローアップ

セッションで完了した作業によって必要となった、人間が行うべきアクションごとに、.agents/skills/end-session/settings/human-follow-up.md の ## Procedure を実行します。他のスキル（docs-updater、ship）がすでに着手したアクションも対象です。重複させず、それらを調整してください。

5. ドキュメント

セッションの作業に対して docs-updater スキルを実行します。ハーネスにサブエージェントがある場合は、そのサブエージェントに .agents/skills/docs-updater/SKILL.md に従うよう指示します。ない場合は自分で実行してください。サブエージェントはユーザーに質問できないため、まずここでステップ 0 に従って設定を完了させます。まだマージされていない作業には fix モードを、ship がすでに更新してマージされた作業には check モードを使用し、ステップ 3 のとおり、報告された差分は新しい作業として記録します。ship の報告で Wiki の検索が必要とされたマージ済み作業については、Wiki のみを対象に、fix モードでもう一度実行します。古い参照は修正し、起票はしません。

これが end-session であることを伝え、差分に加えて、セッションで見つかった変更（決定事項や調査結果）の一覧も渡します。それらは、各ドキュメントのマーカーを尊重し、when が合致する Doc map のドキュメントに反映します。返された人間によるアクションには、ステップ 4 の手順を実行します。編集内容はコミットされずに戻され、ステップ 6 の未コミット作業に関する確認の対象となります。

• Companion。 Private companion が設定されていて、そのチェックアウトが存在する場合は、Companion 自身のルートから確認します。外側のリポジトリでの git log、git show、git diff では、その中身を確認できません。チェックアウトが存在しない場合は、Companion のドキュメントを調整できなかったことを報告し、代わりのディレクトリは作成しません。Companion commit policy に従い、Companion の変更は Companion リポジトリで独立したコミットとして記録します。
• 変更履歴の未記載。 今回のセッションでコミットされた振る舞いの変更に Unreleased の項目がない場合は、報告すべき負債です。変更履歴は ship が記載します。
• トラッカーは 1 つ。 セッションで追加したバックログ、ロードマップ、または TODO ファイルは、Issue トラッカーと重複します。その内容を Issue に移すことを提案します。

6. ワークスペース

未コミットの作業を最初に確認します — クリーンアップによって完全に失われる可能性がある唯一のものです：

git status --short
git stash list

同じ作業を、存在する場合はコンパニオンでも実行します。変更ごとに、ブランチにコミットするか、名前付きメッセージでスタッシュするか、そのまま残すかを確認してください。そのまま残すのも有効な選択です。レポートにその旨を記載してください。

ブランチ。 ブランチのローカル先端と同じ位置、またはそれより後で PR がマージされていれば、そのブランチは完了です。これはスクワッシュマージでも同様です。この場合、git branch --merged ではスクワッシュされたブランチをすべて検出できません：

git fetch --prune origin
for branch in $(git for-each-ref --format='%(refname:short)' refs/heads | grep -vx main); do
  tip=$(git rev-parse "$branch")
  pr=$(gh pr list --state all --head "$branch" --json number,state,headRefOid \
    --jq 'sort_by(.number) | last | select(.) | "\(.number) \(.state) \(.headRefOid)"')
  read -r number state head <<< "$pr"
  verdict=unfinished
  if [ "$state" = MERGED ]; then
    git cat-file -e "$head^{commit}" 2>/dev/null || git fetch -q origin "pull/$number/head"
    git merge-base --is-ancestor "$tip" "$head" && verdict=finished
  elif [ -z "$number" ] && git merge-base --is-ancestor "$tip" origin/main; then
    verdict=finished
  fi
  echo "$branch ${number:-no-pr} ${state:-none} $verdict"
done
git worktree list

ユーザーの同意を得たら、完了したブランチを git branch -D で削除します（-d ではスクワッシュされたブランチを削除できません）。オープン中の PR があるブランチ、PR がなく独自のコミットがあるブランチ、またはマージ済みの先端より後にコミットがあるブランチには作業が残っています。そのまま保持し、準備ができている場合はレポートで ship と明記してください。プルーン後も一覧に残るリモートブランチも同様に確認してから、git push origin --delete を実行してください。完了したワークツリーは git worktree remove <path> で削除し、その後 git worktree prune を実行します。

最後に main に戻ります。以下の整理を済ませてから行ってください。ただし、追跡対象ファイルに未コミットの変更がある場合、またはユーザーがこのチェックアウトでこのブランチの作業を続ける場合は除きます。git switch main を実行し、続けて docs/agents/workspace.md の Sync with main、次に Hook: after sync を実行します。同期でファストフォワードが拒否された場合、ローカルの main に独自のコミットがあります。その旨を報告し、main はそのままにしてください。

ファイル。 Safe-to-remove paths と、セッション中にツリーに残された一時ファイルは、一覧を確認してからパスを指定して削除します。Never-remove paths は、ユーザーから明示的な依頼がない限り保持します。git clean -x のような一括削除ではこれらも削除されるため、パスを指定して個別に削除してください。

続いて：

• Dev stack — 実行中のものを報告し、停止する前に確認します。データベースの実行は意図的な可能性があります。ここでは Never run コマンドを決して実行しないでください。
• Generated-config check — 該当し、差分が報告された場合は再生成し、両方の変更をコミットします。
• docs/agents/workspace.md の Hook: end-session cleanup。
• 最後に Final portability check を実行します。チェックアウトが同期済みとだけ述べず、各リポジトリの正確な状態を記載してください。

7. レポート

簡潔で正直な報告で締めくくります：

• 追加、更新、削除したメモリと、それぞれの理由を一行ずつ。
• コメント、クローズ、ラベル付け、または作成した Issue の番号。
• 人によるフォローアップ：確認済みの Issue と wiki のリンク、未公開のものとその理由、または未対応事項がないこと。
• 更新したドキュメント、コンパニオンの変更とそのコミット状態、またはコンパニオンが存在しなかったこと。
• 手順 0 で書き込んだ設定ファイル。
• ワークスペース：削除したもの、意図的に残したものとその理由。
• 未対応： 未コミットの変更、未プッシュのブランチ、レビュー待ちの PR、実行中のコンテナー、ユーザーの判断が必要な事項、およびこのスキルが引き継ぎによって呼び出された場合は、引き継ぎドキュメントのパス。

実施しなかったことは明確に記載してください。「この 3 件がまだ未対応です」と正確に報告することが、このスキルの目的です。