progress-summary について
progress-summaryは、明快なPR説明のような会話調の進捗報告や作業の振り返りを書くスキルです。動機、判断の経緯、現状、残作業を軸にし、新規参加者向けのアーキテクチャ説明にはnotebook-explanation形式を使います。
主な機能
- 01動機を先に示す進捗報告
- 02判断と残作業を含む振り返り
- 03会話調で正確な文章の指針
- 04アーキテクチャ説明向けnotebook-explanation形式
活用シーン
- 01作業中の状況を簡潔に共有
- 02セッション終了時の判断事項の整理
- 03新規参加者への複雑な変更の説明
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/progress-summaryを入力して読み込まれたか確認します。
詳細
進捗サマリー
進行中の作業について、丁寧に書かれた PR 説明と同じスタイルで、会話形式のサマリーを生成します。
新規参加者にわかりやすいアーキテクチャの説明には、notebook-explanation をフォーマットとして使用してください。短い作業メモ、小さな定義、ASCII 図、具体的な例、圧縮されたルールを扱います。
基本原則
まず動機
すべてのサマリーは WHY から始まります。どのファイルが変更されたかでも、どのように動作するかでもありません。この作業がなぜ重要なのかです。
良い書き出し:
アップロードの途中でユーザーがログアウトしてしまうセッションタイムアウトの問題に取り組んできました。根本原因は、セッションのリフレッシュがナビゲーション時にしか発火せず、バックグラウンドの処理中には発火していなかったことでした。
悪い書き出し:
アップロードハンドラーに keepalive 呼び出しを追加し、セッションリフレッシュのロジックを更新しました。
読者は SOLUTION を見る前に PROBLEM を理解できるべきです。
思考を見せる
サマリーは意思決定のプロセスを明らかにするべきです。
- 「X を検討しましたが、Y のほうが理にかなっていました。なぜなら…」
- 「最初に A を試し、そこから B が見えて、C にたどり着きました」
- 「難しかったのは、既存のフローにどこでフックするかを見極めることでした」
会話的だが正確に
コーヒーを飲みながら同僚に説明するように書きます。直接的で正直に。
- 「これは大変でした」であって「これは課題を提示しました」ではない
- 「〜で壁にぶつかりました」であって「〜で困難に遭遇しました」ではない
- 共同作業には「私たち」、個人的な所見には「私」を使います
サマリーの種類
クイックステータス（口頭での確認）
「何に取り組んでいますか」や短い進捗報告に:
Working on the auth timeout issue. Found the root cause: session refresh
only fires on navigation, not background activity. Currently implementing
a keepalive mechanism in the upload handler.
2〜4 文。問題、発見、現在のアクション。
セッションの振り返り（作業セッションの終わりに）
「やったことをまとめて」や締めくくりに:
構成:
- 取り組んだ問題
- 行った主要な決定（およびその理由）
- 今動いているもの
- 残っていること
例:
We tackled the nested reactivity problem in state management. Users found
it cumbersome to create deeply reactive state with manual get/set properties.
After exploring several approaches, we landed on proxy-based reactivity
because it lets you write idiomatic JavaScript while we get the performance
benefits of immutability under the hood.
The core implementation is working. Still need to optimize for large arrays
and update the migration guide.
アーキテクチャの概要（複雑な変更の説明）
より大きな作業について「ここで何が起きているか説明して」という場合には、notebook-explanation を使用してください。メンタルモデルと図の文法、すなわち所有権、境界、フロー、良い例と悪い例、持続的なルール、図の形の分類を担います。
progress-summary は引き続きその周囲で振り返りを組み立てます。何が変わったか、なぜ変わったか、そして何がまだ未解決かです。
避けるべきこと
- 変更されたファイルの列挙: 「auth.ts、session.ts、upload.ts を更新しました」 : 何をなぜ行ったかを説明するだけにします
- 企業的な話し方: 「この機能強化は既存のインフラストラクチャを活用します」
- マーケティング的な言葉: 「画期的な」「革新的な」「シームレスな」
- 大げさな誇張: 「耐え難いほどの痛み」 : 事実に徹します
- 何でも箇条書きにする: 可能な場合は流れるような段落を使います
- 単純な変更を説明しすぎる: 説明の深さを複雑さに合わせます
サマリーのためのコンテキストの収集
サマリーを生成するには、関連するコンテキストを収集します。
# Current branch state
git status
git log --oneline -10
# What changed from main
git diff main...HEAD --stat
git log main..HEAD --oneline
# Recent activity
git log --oneline --since="1 hour ago"
環境が専用の workspace-diff ツールを提供している場合は、それを使用してください。そうでなければ、git diff --stat、git diff、および対象を絞ったファイル読み取りを使用します。
変更の本質を理解するために、変更された主要なファイルを読みます。diff の統計だけでなく、内容を把握してください。