lets-work

lets-work

作業セッションを始めるための儀式です。このプロジェクトに関するユーザー個人の状態を読み込み、前回の訪問以降に生じた変化を説明し、セッションの終わり方を整えます。

儀式の重さは、変化の量に比例させる必要があります。 このスキルが役立つのは、しばらく離れていた後に再開するときです。毎回のセッションで、ユーザーが待たされる関門になってはいけません。前回の訪問からほとんど、あるいはまったく変化がなければ、開始時の案内は「昨日から変わったことはありません。今日は何に取り組みますか？」の1行だけにして、すぐに作業を始めます。以下の詳細なブリーフィングは、実際にしばらく離れていた場合のものです。

個人の状態（痕跡を残さない契約）

状態はすべて、対象プロジェクトの外部にある、ユーザーが所有するディレクトリに保存します。その一部も、このスキルパックへの参照も、対象プロジェクトのファイル、コミット、PR、Issue に書き込んではいけません。

• ルート：${XDG_DATA_HOME:-$HOME/.local/share}/identity16-skills/projects/<repo-id>/
• repo-id：正規化した origin リモート URL をスラッグ化したものです。プロトコル、認証情報、.git を削除し、/ と : を __ に置き換えます（例：github.com__rust-lang__rust）。リポジトリにリモートがない場合は、リポジトリの絶対パスを同じ方法でスラッグ化します。
• ファイル（初回使用時に作成）：
  • state.json — { "last_visit": { "commit": "<sha>", "date": "<ISO date>", "branch": "<name>" } }
  • dossier.md — プロジェクトに関するユーザーのメンタルモデルです。アーキテクチャのメモ、重要な不変条件、注意点、プロジェクトのツールスタック（議論を行う場所、作業を追跡する場所、リリース方法）、リポジトリ内でコンテキストを確認できる場所へのポインターを記録します。リポジトリ自体に保存先がない情報だけを記録します。リポジトリのドキュメントを複製するのではなく、あくまで補助として使います。
  • journal.md — 追記専用のセッションログです。日付、学んだこと、未解決の質問、作業中の状態を記録します。

手順

1. 現在のリポジトリから repo-id を導き出し、その状態ディレクトリを探します。
2. 再訪の場合（状態が存在する場合）：
   • state.json、dossier.md、および journal.md の最近の項目を読みます。
   • 現状と保存済みモデルを比較します：git log --oneline <last_visit.commit>..HEAD と git diff --stat <last_visit.commit>..HEAD を実行します。記録されたコミットが存在しなくなっている場合（rebase、gc）は、git log --since=<last_visit.date> に切り替えます。
   • まず差分の大きさを見極めます。 ほとんど差分がない（最近の訪問で、他の人によるコミットがほとんど、またはまったくなく、dossier が扱う領域に触れたものもない）場合は、差分がないことを確認し、未解決の WIP メモがあれば触れてから、ステップ 5 に進むことを一行で伝えます。それ以外の場合：
   • ユーザーのメモに沿って、一般的な変更履歴のようにならない形で説明します。どの dossier の項目が古くなった、または矛盾するようになったか、新しいコミットが journal のどの未解決の疑問に答えたか、新たに調査が必要な領域はどこかを伝えます。簡潔にまとめ、根拠としてコミットや PR を挙げます。
   • journal にある、依然として未解決の疑問や WIP メモを提示します。
3. 初回訪問の場合（状態がない場合）：
   • 初回訪問であることを伝え、簡潔な初期 dossier を作成します。エントリーポイント、モジュールマップ、確認可能な不変条件、ツールスタックを記録し、リポジトリからはわからないことについてはユーザーに尋ねます。リポジトリ内のドキュメントですでに明らかなことは記録しません。
   • 現在のコミットを記録した state.json を書き込みます。
4. ユーザーがまだ目的を伝えていない場合は、何をしに来たのか尋ねます。タスクが示されていて、かつ dossier で不確か、または不明とされている領域に関わる場合は、depth-check がインストールされていれば実行します。インストールされていなければ、まず何を調べるべきかを簡潔に伝えます。領域が既知なら、余計な意見は加えず、そのまま取りかかります。
5. セッションの基本方針を定めます。 このセッションの残りの間、ユーザーの方針に従って作業します。
   • ユーザーが理解している決定だけを反映します。 コードベースに重大な決定を反映する前に、その決定を提示します。採用した選択肢、退けた代替案、判断が誤っていた場合に何が壊れるかを説明し、ユーザーがただ受け入れるのではなく、納得して承認できるようにします。判断を要する決定を大きな差分の中に埋もれさせてはいけません。
   • 理解が最も長く残る場所に記録します。 優先順位は、まず直感的に理解できるコードと構成、次にコードを複雑なままにする必要がある場合の簡潔な「理由」コメント、続いて整理されたコミットメッセージと PR の説明、最後にリポジトリ内に記録場所がないものに限り個人用ストアです。最後だけでなく、作業中ずっとこれを実践します。
   • 適切なタイミングで pack のツールを使います（インストールされているものに限ります）。問題やアイデアをチケットにする必要がある場合は make-ticket を使います（チケットにするのは問題であり、解決策ではありません）。既存コードがそのようになっている理由をユーザーが尋ねた場合は why を使います（記録を掘り起こし、理由を推測してはいけません）。ブランチの履歴をレビュー前に整理する必要がある場合は organize-commits を提案します。ユーザーが理解していない差分をレビュー、承認、またはリリースしようとしている場合（他の人の PR や、エージェントが作成した規模の大きい差分など）は explain を使います（記録からモデルを組み立て、理由を捏造してはいけません）。自然なタイミングで一度だけ提案し、ユーザーは自由に断れます。
   • 終了時の儀式を用意し、そのタイミングは自分で判断します。 決まり文句を待たず、セッションの流れから自然な区切りを見つけて /checkpoint を提案します。目安となるサインは、強い順に次のとおりです。開始時に示されたタスクが完了し、新たな作業に移っていないこと、作業の一区切りがついたこと（PR の作成、ブランチのプッシュ、マージの完了）、明示的な締めくくりの言葉（「今日はここまで」「これで完了です」など）や別れを思わせる口調です。実質的な学びが積み重なったセッションでは、別れの言葉を待ち続けるより、作業を終えた直後の区切りを優先します。セッションは、別れの言葉なしに終わることがよくあるためです。checkpoint に実際に何が記録されるかも考慮します。学びがなかったセッションでは、提案する必要はありません。一度提案し、断られたらそれ以上は勧めません。ユーザーはいつでも自分で /checkpoint を実行できます。

ガードレール

• ブリーフィングは単に読む時間を短縮するだけでなく、理解を深めるものでなければなりません。変更内容は常に、ユーザーが記録したモデルに結び付けて説明してください。
• セッションの枠組みは講義ではなく、行動に表れます。作業中は黙って適用し、ユーザーに繰り返し説明しないでください。
• 儀式的なやり取りでユーザーを待たせてはいけません。ずれがなければブリーフィングは不要で、タスクが明確に指定されていれば質問も不要です。