gstack-openclaw-retro について
gstack-openclaw-retroは、リポジトリのコミット履歴やコード指標からエンジニアリングの振り返りを作成するスキルです。期間を指定して比較でき、スナップショットを保存して推移を追えます。
主な機能
- 01振り返り期間の指定
- 02コミットとコード指標の集計
- 03貢献者別の分析
- 04作業時間帯とセッションの分析
- 05履歴スナップショットと比較
活用シーン
- 01チームの最近の開発作業を振り返る
- 02期間ごとの活動を比較する
- 03コードとテストの推移を追う
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/gstack-openclaw-retroを入力して読み込まれたか確認します。
詳細
週間エンジニアリング振り返り
コミット履歴、作業パターン、コード品質メトリクスを分析し、包括的なエンジニアリング振り返りを生成します。チームを考慮し、コマンドを実行したユーザーを特定してから、貢献者全員を分析し、個人ごとの称賛点と成長の機会を示します。
引数
- デフォルト：直近7日間
24h：直近24時間14d：直近14日間30d：直近30日間compare：現在の期間と、同じ長さの直前の期間を比較します
手順
引数を解析して期間を決定します。デフォルトは7日間です。時刻はすべて、ユーザーのローカルタイムゾーンで報告してください。
午前0時を基準にした期間： 日単位の場合は、ローカルタイムゾーンの午前0時を基準に開始日を計算します。たとえば、今日が2026-03-18で、期間が7日間の場合、開始日は2026-03-11です。git log のクエリには --since="2026-03-11T00:00:00" を使用します。時間単位の場合は、--since="N hours ago" を使用します。
ステップ1：生データの収集
まず origin を取得し、現在のユーザーを特定します。
git fetch origin main --quiet
git config user.name
git config user.email
git config user.name が返す名前は**「あなた」**、つまりこの振り返りを読んでいる人です。それ以外の作者はすべてチームメイトです。
以下の git コマンドをすべて実行します（それぞれ独立しています）。
# All commits with timestamps, subject, hash, author, files changed
git log origin/main --since="<window>" --format="%H|%aN|%ae|%ai|%s" --shortstat
# Per-commit test vs total LOC breakdown with author
git log origin/main --since="<window>" --format="COMMIT:%H|%aN" --numstat
# Commit timestamps for session detection and hourly distribution
git log origin/main --since="<window>" --format="%at|%aN|%ai|%s" | sort -n
# Files most frequently changed (hotspot analysis)
git log origin/main --since="<window>" --format="" --name-only | grep -v '^$' | sort | uniq -c | sort -rn
# PR numbers from commit messages
git log origin/main --since="<window>" --format="%s" | grep -oE '[#!][0-9]+' | sort -t'#' -k1 | uniq
# Per-author file hotspots
git log origin/main --since="<window>" --format="AUTHOR:%aN" --name-only
# Per-author commit counts
git shortlog origin/main --since="<window>" -sn --no-merges
# Test file count
git ls-files 2>/dev/null | grep -E '(\.test\.|\.spec\.|_test\.|_spec\.)' | wc -l
# Test files changed in window
git log origin/main --since="<window>" --format="" --name-only | grep -E '\.(test|spec)\.' | sort -u | wc -l
ステップ2：メトリクスの算出
次のメトリクスを計算し、概要に表示します。
- main へのコミット数： N
- 貢献者数： N
- マージされた PR 数： N
- 追加された行の合計： N
- 削除された行の合計： N
- 純増 LOC： N
- テスト LOC（追加行）： N
- テスト LOC の比率： N%
- バージョン範囲： vX.Y.Z → vX.Y.Z
- 活動日数： N
- 検出されたセッション数： N
- セッション時間あたりの平均 LOC： N
続けて、そのすぐ下に作者別リーダーボードを表示します。
Contributor Commits +/- Top area
You (garry) 32 +2400/-300 browse/
alice 12 +800/-150 app/services/
bob 3 +120/-40 tests/
コミット数の降順で並べます。現在のユーザーは必ず先頭に表示し、「あなた（名前）」とラベル付けします。
ステップ3：コミット時刻の分布
ローカル時刻で時間別のヒストグラムを表示します。
Hour Commits ████████████████
00: 4 ████
07: 5 █████
...
以下を特定します。
- ピーク時間帯
- コミットがない時間帯
- 二峰性（朝と夜）か、連続的なパターンか
- 深夜のコーディング集中（午後10時以降）
ステップ4：作業セッションの検出
連続するコミット間の45分の間隔を閾値として、セッションを検出します。
セッションを次のように分類します。
- ディープセッション（50分以上）
- ミディアムセッション（20〜50分）
- マイクロセッション（20分未満、単一コミット）
以下を計算します。
- アクティブなコーディング時間の合計
- セッションの平均時間
- アクティブ時間あたりの LOC
ステップ5：コミット種別の内訳
Conventional Commits のプレフィックス（feat/fix/refactor/test/chore/docs）で分類します。割合バーで表示します。
feat: 20 (40%) ████████████████████
fix: 27 (54%) ███████████████████████████
refactor: 2 ( 4%) ██
fix の割合が50%を超える場合はフラグを立てます。これは「素早く出荷し、素早く修正する」パターンの兆候であり、レビューの抜けがある可能性を示します。
ステップ6：ホットスポット分析
変更頻度の高いファイルを上位10件表示します。次の項目にフラグを立てます。
- 5回以上変更されたファイル（変更頻度の高いホットスポット）
- ホットスポット一覧内のテストファイルと本番ファイル
- VERSION/CHANGELOG の更新頻度
ステップ7：PR サイズの分布
PR のサイズを推定し、次の区分に分類します。
- 小（100 LOC 未満）
- 中（100〜500 LOC）
- 大（500〜1500 LOC）
- 特大（1500 LOC 以上）
ステップ8：フォーカススコアと今週の出荷
フォーカススコア： 最も変更頻度の高いトップレベルディレクトリに触れたコミットの割合です。数値が高いほど作業への集中度が高く、低いほどコンテキスト切り替えが多いことを示します。
今週の出荷： 対象期間内で LOC が最も多い PR を1件取り上げます。PR 番号、変更 LOC 数、重要な理由を示します。
Step 9: チームメンバーの分析
各コントリビューター（現在のユーザーを含む）について、次の項目を算出します。
- コミット数とLOC ... コミット総数、追加行数、削除行数、純LOC
- 注力分野 ... 最も多く変更したディレクトリ／ファイル（上位3件）
- コミット種別の内訳 ... feat／fix／refactor／test の個人別内訳
- セッションの傾向 ... コーディングする時間帯（ピーク時間）、セッション数
- テストへの取り組み ... 個人のテストLOC比率
- 最大の成果 ... 最もインパクトの大きかった単一のコミットまたはPR
現在のユーザー（「あなた」）について： 最も詳しく分析します。すべてのセッション分析、時間帯の傾向、フォーカススコアを含めます。一人称で記述します。
各チームメイトについて： 何をリリースしたか、どのような傾向があるかを2～3文で説明します。その後、次の項目を記載します。
- 称賛（具体的な点を1～2件）：実際のコミットを根拠にします。「素晴らしい仕事」ではなく、何が良かったかを具体的に述べます。
- 成長の機会（具体的な点を1件）：批判ではなく、次のレベルへ進むための機会として示します。実際のデータを根拠にします。
個人リポジトリの場合： チームの内訳は省略します。
AI との共同作業： コミットに Co-Authored-By の AI トレーラーがある場合、「AI 支援コミット」を別指標として追跡します。
Step 10: 週ごとの傾向（対象期間が14日以上の場合）
週ごとに分け、次の傾向を示します。
- 週ごとのコミット数（合計および著者別）
- 週ごとのLOC
- 週ごとのテスト比率
- 週ごとの修正比率
- 週ごとのセッション数
Step 11: 連続記録の追跡
今日からさかのぼり、1日1件以上のコミットがある連続日数を数えます。
# Team streak
git log origin/main --format="%ad" --date=format:"%Y-%m-%d" | sort -u
# Personal streak
git log origin/main --author="<user_name>" --format="%ad" --date=format:"%Y-%m-%d" | sort -u
次の両方を表示します。
- 「チームの連続リリース記録：47日連続」
- 「あなたの連続リリース記録：32日連続」
Step 12: 履歴の読み込みと比較
memory/ に過去のレトロスペクティブ履歴があるか確認します。
過去のレトロスペクティブがある場合は、最も新しいものを読み込み、差分を算出します。
Last Now Delta
Test ratio: 22% → 41% ↑19pp
Sessions: 10 → 14 ↑4
LOC/hour: 200 → 350 ↑75%
Fix ratio: 54% → 30% ↓24pp (improving)
過去のレトロスペクティブがない場合は、「初回のレトロスペクティブを記録しました。傾向を確認するには、来週もう一度実行してください。」と記載します。
Step 13: レトロスペクティブ履歴の保存
指標、著者、バージョン範囲、連続記録、投稿に使える要約を含むJSONスナップショットを memory/retro-YYYY-MM-DD.json に保存します。
Step 14: レポートの作成
Telegram 向けの形式（箇条書き、太字を使用し、最終出力ではMarkdownの表を使わない）。
構成：
投稿用の要約（1行目）：
3月1日の週：47コミット（コントリビューター3人）、3.2k LOC、テスト38％、PR 12件、ピーク：午後10時 | 連続記録：47日
続いて、次のセクションを記載します。
- 概要 ... 主な指標
- 前回のレトロスペクティブとの傾向比較 ... 差分（初回の場合は省略）
- 時間帯とセッションの傾向 ... チームがコーディングする時間帯、セッションの長さ、集中型か短時間型か
- リリースの速度 ... コミット種別、PRの規模、修正の連鎖の検出
- コード品質の兆候 ... テスト比率、ホットスポット、変更量
- 注力分野とハイライト ... フォーカススコア、今週の成果
- あなたの1週間 ... 現在のユーザーの詳細な分析
- チームの内訳 ... 称賛と成長の機会を含む、チームメイトごとの分析（個人リポジトリの場合は省略）
- チームの主な成果3件 ... インパクトが最も大きかったリリース
- 改善点3つ ... 具体的で実行可能、コミットを根拠とする
- 来週に向けた習慣3つ ... 小さく、実践的で、無理なく続けられるもの（取り入れるのに5分未満）
比較モード
ユーザーが「compare」と言った場合：
- 現在の期間のレトロスペクティブを実行します
- 同じ長さの直前の期間のレトロスペクティブを実行します
- 指標を横並びで提示し、改善／悪化を矢印で示します
- 最も大きな変化について簡潔に説明します
重要なルール
- 時刻はすべてローカルタイムゾーンで扱います。
TZは絶対に設定しないでください。 - Telegram 向けの形式にします。 箇条書きと太字を使用し、最終出力ではMarkdownの表を避けます。
- 称賛はコミットを根拠にします。 何が良かったかを具体的に述べずに「素晴らしい仕事」と言ってはいけません。
- 成長の機会はデータを根拠にします。 根拠なしに批判してはいけません。
- 履歴を保存します。 傾向を追跡できるよう、レトロスペクティブを実行するたびに
memory/に保存します。 - 完了ステータス：
- DONE ... レトロスペクティブを生成し、履歴を保存しました
- DONE_WITH_CONCERNS ... 生成しましたが、比較対象となる過去のレトロスペクティブがないなど、データに不足があります
- BLOCKED ... Gitリポジトリではない、または対象期間内にコミットがありません