weekly-setup-improvements

/weekly-setup-improvements -- 週次セルフ改善監査

フォルダー内の過去7日間の作業を監査し、構造化された改善レポートを作成します。これは日記ではなく、状態の振り返りです。出力は具体的で、実行可能で、忙しい実務担当者が実際に読むのに十分な短さにしてください。

基本原則

毎週、パターンが生まれます。多くのパターンが、次に行うべき明白なステップを示します。更新が必要なコンテキストファイル、用意すべきスラッシュコマンド、整理が必要なディレクトリなどです。このスキルを実行するコストは数分ですが、実行しないコストは、何カ月にもわたってセットアップに気づかれないズレが蓄積することです。

このスキルの対象（対象外）

	このスキル	このスキルの対象外
範囲	1つのフォルダー	マシン全体
期間	直近7日間	全期間
出力	今後に向けたアクション	過去を振り返る日記
関連スキル	/vault-audit（スナップショット、期間指定なし）、/claude-md-audit（CLAUDE.md のズレのみ）

引数

• 引数1（任意）： 作業フォルダーへのパス。デフォルトは pwd です。

手順

フェーズ1：範囲の指定

1. 作業フォルダーを特定します。
   • 引数が渡された場合は、パスが存在し、ディレクトリであることを確認します。そうでない場合は、明確なエラーを表示して中止します。
   • それ以外の場合は pwd を使用します。
2. 対象期間を計算します。移植性のあるシェルコマンドのみを使用してください。

   TODAY=$(date +%Y-%m-%d)
   # 7-day boundary as ISO date (portable):
   START=$(python3 -c "from datetime import date,timedelta; print(date.today()-timedelta(days=7))")
   

   date -v-7d（macOS 専用）や date -d（GNU 専用）は使用しないでください。
3. 続行する前に、対象範囲をユーザーに表示します。 Auditing <folder> for the period <START> to <TODAY>.

フェーズ2：調査

未加工の情報を収集します。可能な場合は、以下を並行して実行します。

WORKING_FOLDER="$1"

# Files modified in the last 7 days (skip dotdirs and dependency dirs)
find "$WORKING_FOLDER" -type f -mtime -7 \
  -not -path '*/.*' -not -path '*/node_modules/*' \
  -not -path '*/.venv/*' -not -path '*/dist/*' -not -path '*/target/*' \
  | head -150

# Git activity if folder is a repo (use --since= flag, portable across platforms)
git -C "$WORKING_FOLDER" log --since="7 days ago" --oneline 2>/dev/null
git -C "$WORKING_FOLDER" log --since="7 days ago" --stat --no-merges 2>/dev/null | head -300
git -C "$WORKING_FOLDER" status --porcelain 2>/dev/null

# Recently touched directories (signals new work areas)
find "$WORKING_FOLDER" -type d -mtime -7 -not -path '*/.*' | head -30

# File-type distribution (signals task type: code, prose, config, data)
find "$WORKING_FOLDER" -type f -mtime -7 -not -path '*/.*' \
  | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -10

フォルダーが git リポジトリでない場合は、git コマンドを通知なしでスキップし、find -mtime のみを使用します。

フェーズ3：読み込み

以下のうち存在するものを探して読み込みます（存在しないファイルは問題なくスキップします）。

• CLAUDE.md（Claude Code のプロジェクトコンテキスト）
• MEMORY.md（メモリーのインデックス）
• AGENTS.md（エージェントのコンテキスト）
• about-me.md、voice-and-style.md、working-rules.md（Karpathy スタイルのコンテキストアンカー）
• ルート付近の memory/、context/、docs/ サブディレクトリにある任意の *.md
• （V2）最新の過去の weekly-setup-improvements-*.md（アーカイブされた前回のレポート）。アクション項目を読み込み、新しいセクション0の完了確認に反映します。
• （V3）存在する場合は _drafts/ ディレクトリ。その中の各サブディレクトリは、過去の週に作成されたスキルのドラフトです。ドラフトの状態（更新されたか、削除されたか、メインのスキルディレクトリに昇格したか）自体がシグナルです。以下の観点6を参照してください。

これらはセクション1（コンテキストファイルの更新）の対象です。

Phase 4: 分析

Phase 2 のシグナルを、以下の観点からこの順に確認します。次の観点に進む前に、それぞれの調査結果を書き留めてください。

1. 繰り返し。 変更されたファイルの一覧と Git ログを名前順に並べ、2 回以上現れるベース名のパターンに印を付けます（linkedin-*-draft.md、同じ動詞を使ったコミットの繰り返し、同類のフィクスチャ）。繰り返しはすべて、スキルの候補です。
2. 手作業。 「タイプミスを修正／タイプミスを修正／タイプミスを修正」や「ファイルを追加／ファイルを削除／ファイルを再追加」のような小さなコミットの並びを探します。こうしたワークフローは、スクリプトやフックにすべきものです。
3. 記述との乖離。 Phase 3 で読んだ各コンテキストファイルについて、そこに記載された主張（パス、ツール、制約など）を 1 つ選び、過去 1 週間の作業と矛盾していないか確認します。矛盾をすべて挙げ、それぞれに 1 行の修正案を添えてください。
4. 肥大化。 監査期間より古く、現在の命名規則に合わなくなったファイル、*-draft-N.md の同類ファイル、アーカイブ候補を確認します。
5. うまくいったこと。 今週、明らかにうまくいったパターンは何ですか？ それを証明するファイルまたはコミットの名前を挙げてください。証拠を示す前に一般化しないでください。
6. （V2、V3 で強化）引き継ぎ項目の確認＋ゾンビ項目の終了。 前回のレポート（Phase 3）から各アクション項目を確認し、完了、一部完了、未実施、または2 サイクル連続で未実施のいずれかに分類します。証拠となるのは、コミット、新規ファイル、変更された行、またはドラフトの場合は変更、削除、正式採用された _drafts/<name>/ ディレクトリです。1 行で完了率を算出します（「5 件中 3 件完了」）。2 回連続で未実施のアクションは、セクション 0 で理由を 1 行添えて明示的に終了します。今週の推奨事項に再登場させてはいけません。（出典：TeamRetro のレトロスペクティブに関するアンチパターン 2026 — 「ゾンビアクション」は、レトロスペクティブが変化を促さなくなる最大の原因です。）
7. （V2）修正の前に根本原因を特定。 繰り返し発生する課題パターンごとに、修正案を提案する前に簡単ななぜなぜ分析を行い、セクション 3 で症状ではなく原因に対処します。（振り返りの証拠によると、症状に対処するアクションは毎サイクル再提起されます。）
8. （V3）課題全体に共通する主要な根本原因。 各課題についてなぜなぜ分析を行った後（観点 7）、根本原因全体を見渡し、今週の課題のうち最も多くの問題を説明する原因、つまりパレートの根本原因を特定します。個々の課題の一覧より先に、これをセクション 3 の冒頭に記載します。原因が 2 つで同率の場合は、両方を挙げて終わります。（出典：オペレーション／リーンにおけるパレートの法則。）

compound-engineering:ce-sessions がインストールされている場合は、会話の傾向（例：「今週、ユーザーが『X の方法は？』と 3 回質問した」）を見つけるために、任意で使用できます。利用できない場合はスキップしてください。このスキルは、これを使わなくても機能する必要があります。

Phase 5: 作成

出力ファイル： <WORKING_FOLDER>/weekly-setup-improvements.md

前回のレポートがある場合： 書き込む前に、アーカイブします。

PRIOR="$WORKING_FOLDER/weekly-setup-improvements.md"
if [ -f "$PRIOR" ]; then
  PRIOR_DATE=$(grep -m1 '^# Weekly Setup Improvements' "$PRIOR" | sed -E 's/.*— ([A-Za-z]+ [0-9]+, [0-9]+).*/\1/' | tr ' ,' '--')
  [ -z "$PRIOR_DATE" ] && PRIOR_DATE=$(date -r "$PRIOR" +%Y-%m-%d 2>/dev/null || echo "$START")
  mv "$PRIOR" "$WORKING_FOLDER/weekly-setup-improvements-$PRIOR_DATE.md"
fi

構成（必ず以下のとおりにしてください）：

# Weekly Setup Improvements — <Month Day, Year>

Based on review of <one-line scope>: files modified, git activity, and patterns from <START> to <TODAY>.

---

## 0. Last Week's Actions  *(V2 — skip if no prior report)*

Closure rate: <N of M done>. One line per prior action: ✅ done (evidence) / ◐ partial / ✗ dropped (why) / 💀 **killed** (dropped 2× — rationale). A killed action does not reappear in this week's Section 2/3 — explain why we cut it and stop re-surfacing it. *(V3: zombie-action kill rule.)*

## 1. Context File Updates

For each context file, give one of:
- **Create:** path + suggested content (in a code block)
- **Update:** path + the specific lines to add or change
- **No change:** path + one-line reason it's still accurate

## 2. New Skill Ideas

Cap at 3. Quality over quantity. For each:
- `/skill-name` — one-line description
- **What it does:** 2-3 bullets
- **Trigger phrases:** when the user would invoke it (cite the surfaced repetition)
- **Draft:** *(V3)* `_drafts/<skill-name>/SKILL.md` created (or "draft exists, last touched <date>" if it already did from a prior week)

## 3. Workflow Gaps

**Dominant root cause this week:** *(V3 — one sentence naming the Pareto cause across the gaps below; if two tie, name both.)*

Each gap is one bullet group:
- **Did manually:** what
- **Root cause:** *(V2)* the Five-Whys result — why this keeps happening, not just that it did
- **Should be:** what (a tool, a script, a skill, a hook) — addressing the cause
- **Owner / next action:** *(V2)* the single concrete next step that closes it (a solo practitioner's "owner" is a named next action carried into next week's Section 0)
- **Cost of waiting:** why this matters

## 4. Files to Clean Up

For each: path + action (DELETE / MOVE TO / ARCHIVE / MERGE INTO).
Skip the section if nothing to clean up.

## 5. What's Working

3-5 bullets. Concrete -- name specific files, skills, or workflows that produced clear value this week.

---
*Generated by /weekly-setup-improvements on <TODAY>.*

Phase 5b: ドラフトを作成 (V3)

レポートを書き終えたら、セクション 2 のスキル案ごとに、references/skill-draft-template.md のテンプレートを使って <WORKING_FOLDER>/_drafts/<skill-name>/SKILL.md にひな形を作成します。ドラフトの description に記載するトリガーフレーズは、見つかった繰り返しパターンから抽出し、考案してはいけません。

DRAFTS="$WORKING_FOLDER/_drafts"
mkdir -p "$DRAFTS"
# For each Section 2 idea, write _drafts/<name>/SKILL.md from the template.
# If a draft of the same name already exists, skip it (the user is iterating; don't clobber).

前週から同じ <skill-name> のドラフトディレクトリがすでに存在する場合は、上書きしないでください。ユーザーが作業を続けているため、そのまま残します。代わりに、セクション 2 に既存のドラフトを記載します（例：「ドラフトあり、最終更新 」）。

この手順の理由：V2 ではセクション 2 が「/foo を作るべきです」で終わっていました。1 週間後も、その推奨はただの文章のままです。V3 では「/foo のひな形は _drafts/foo/SKILL.md にあります。開いて編集してください」で終わります。この着手のしやすさの違いが、V3 の主旨です。

Phase 6: 提示

書き込み後、以下を出力します。

1. 出力ファイルのフルパス。
2. 各セクションの要約を 1 行ずつ（例：「セクション 2：新しいスキル案 2 件、セクション 4：整理対象ファイル 5 件」）。
3. レポートの冒頭 15～20 行。ユーザーが Obsidian を開かずに行動できるようにします。

品質基準

すべてのチェック項目を満たしている場合、レポートは合格です。満たしていない場合は、該当箇所を書き直してください。

• セクション 1 の各項目では、実在するファイル（既存または作成予定）を参照し、「更新を検討する」ではなく、具体的な差分またはコンテンツブロックを示します。
• セクション 2 の各スキルでは、そのスキルを正当化する具体的な反復（コミット数、ファイル数、プロンプト数）を挙げます。
• セクション 3 の各ギャップでは、手作業で行ったことと、それに置き換えるべきものを明記します。
• セクション 4 の各項目には、動詞（DELETE/MOVE/ARCHIVE/MERGE）とパスを含めます。
• セクション 5 では、長所ではなくファイル名またはコミットを挙げます。
• (V3) セクション 3 は、ギャップを列挙する前に、支配的な根本原因を一文で述べます。
• (V3) セクション 2 の各アイデアは、ディスク上に実在する _drafts/<name>/SKILL.md を参照するか、既存のファイルであることを記します。
• 「検討する」「おそらく」「〜するとよいかもしれません」「〜するプロセスを確立する」、その他の曖昧な表現をセクション内で使いません。すべての推奨事項は、次の 30 分以内に実行できるほど具体的にします。

注意点

• 作業記録を書かないでください。 これは今後の改善に向けたものであり、「実施したこと」の日記ではありません。日記のように読めるセクションは、実行項目として書き直してください。
• 一般論で水増ししないでください。 すべての箇条書きで、実在するファイル、スキル、または今週確認されたパターンを参照してください。
• 新しいスキルを 3 つ以上提案しないでください。 それ以上はノイズになり、ユーザーはどれも作成しなくなります。
• 「うまくいっていること」を省略しないでください。 否定的な偏りは禁物です。ユーザーは、変更点と同じくらい維持すべき点も知る必要があります。
• ほかのファイルを変更しないでください。 このスキルが書き込むファイルは 1 つだけです（以前のファイルがある場合は、そのファイルを改名します）。
• ユーザーのパスをハードコードしないでください。 /Users/<name>/... ではなく、$WORKING_FOLDER、$HOME、$1 を使ってください。

変更履歴

V3.1 (2026-05-30) — ドラフトテンプレートの厳格化

• references/skill-draft-template.md の手順セクションで、提示された反復作業から具体的な動詞を取り入れることを必須にしました。<Step> プレースホルダーは埋め草です。手順 1 を実行可能にしなければ、着手のハードルを下げるという目的は達成できません。Gotchas と Testing では、初回実行のデータが本当に必要なため、TODO を引き続き許可します。ただし、Procedure では禁止します。V3 の A/B テストで判明した残存課題に対処します。評価者は、実体化されたスタブにプレースホルダーの手順があったため、Draft-fidelity のスコアを 5 点満点中 4 点にとどめました。

V3（2026-05-29）— 下書きの自動生成、ゾンビアクションの終了、主要な根本原因

skillforge optimize を使って最適化しました。目標とする成果：レポートの提案が再掲されるだけでなく、翌週に実際に実行される割合を高めます。

• フェーズ 5b 下書きの具体化：セクション 2 のアイデアごとに、references/skill-draft-template.md を使って _drafts/<skill-name>/SKILL.md を作成します。V2 で未解決だった着手のハードルを解消します。説明文とは異なり、下書きは反復して改善できます。（出典：Ole Lehmann のスレッド、および環境設計に関する『Atomic Habits』の章。）
• ゾンビアクション終了ルールをセクション 0 に追加しました。2 サイクル連続で実行されなかったアクションは、理由を明記して終了し、再び持ち出さないようにします。（出典：TeamRetro の振り返りに関するアンチパターン 2026。）
• セクション 3 の冒頭に主要な根本原因を追加しました。個別のギャップを列挙する前に、Five Whys の結果からパレートの観点で主要な根本原因を 1 つ特定します。（出典：リーンオペレーションにおけるパレートの法則。）
• 品質改善：「What NOT to Do」を「Gotchas」に変更し、skillforge 自身のチェックリストとの用語の一貫性を高めました。references/ ディレクトリを追加し、「段階的な情報開示がない」というドライラン時のギャップを解消しました。
• A/B 検証 — 5 タスクの合成ベンチマーク（チューニング 3 件、検証 2 件）で V3 と V2 を比較し、5 項目の評価基準（実行可能性 ×2、具体性、因果の深さ、ループの完結、スキル下書きへの忠実度）を使って、LLM-as-a-judge によるブラインド評価を実施しました。結果：
  • チューニング（F1～F3）：V3 は 84、V2 は 72、平均 Δ は +4.00/30。
  • 検証（F4～F5）：V3 は 53、V2 は 47、平均 Δ は +3.00/30 — 過学習はありません。
  • V3 は 5 件中 4 件で勝ち、1 件は引き分けでした（グリーンフィールドのケース、F4 — 過去のレポートがないため、V3 が解消する着手のハードルはまだ存在しません）。
  • 項目別の差分：下書きへの忠実度 +2.0（V3 の主旨）、因果の深さ +0.6、実行可能性 +0.4、ループの完結 +0.2、具体性 ±0.0。
  • 残る課題も正直に記します。手順の骨子が TODO のままだと、具体化された下書きが中身の薄い埋め草になりかねないと評価者に指摘されました。そのため、V3 の下書きへの忠実度のスコアは 4/5 にとどまりました。次回のテンプレート改訂で、これを改善する必要があります。

V2（2026-05-27）

skillforge optimize を使って最適化しました（成果に関する調査：2026 年の振り返り／継続的改善の実践）。

• セクション 0 — 先週のアクションと完了率の確認を追加しました（前回のレポートを読み、各アクションを根拠とともに「完了」「一部完了」「未実施」に分類します）。振り返りが無視される最大の理由は、アクションのフォローアップがないことです。この変更で、そのサイクルを完結させます。
• セクション 3 のすべてのギャップに担当者／次のアクションを設定し、翌週のセクション 0 に引き継ぎます。
• 修正を提案する前に**根本原因（Five Whys）**を特定し、症状ではなく原因を対象とするようにします。
• 成果目標：毎回新たな要望リストを作るのではなく、週をまたいで実際に変化を促すレポートにします。出典：TeamRetro の振り返りに関するアンチパターン 2026、継続的改善（Five Whys／Force Field）の実践。

定例実行／スケジュール

毎週実行するには、/schedule スキルを呼び出し、対象のフォルダーと cron 式を指定して、このスキルのスケジュール設定を依頼します。例：

/schedule weekly-setup-improvements every Sunday at 9am, working folder ~/path-to-folder

schedule スキルが cron 構文と永続化を処理します。このスキル自体は、実行時にレポートを生成する方法だけを認識しています。

テスト

これはプロンプトのみのスキルであり、自動ランタイムテストはありません。提供されている tests/eval.sh は構造評価を実行し、SKILL.md に設計上の契約が維持されていること（各フェーズが存在すること、ハードコードされた禁止パスがないこと、出力ファイル名が正しいことなど）を確認します。

エンドツーエンドで動作を検証するには：

1. 直近 7 日間に活動があったフォルダーに cd します。
2. /weekly-setup-improvements を実行します。
3. 次の点を確認します：
   • 出力ファイルが現在の作業ディレクトリに作成されていること。
   • 5 つのセクションすべてに内容があること（または「What's Working」が 5 件未満の場合、妥当な理由があること）。
   • 各箇条書きに、過去 1 週間の実在するファイル、コマンド、またはパターンが記載されていること。
   • 「検討してみてください…」や「おそらく…」のような水増し表現がないこと。
   • 前回のレポートがある場合、上書きされず、日付付きのファイル名でアーカイブされていること。
4. 明示的なパス引数を指定して再実行します：/weekly-setup-improvements ~/some-other-folder。レポートが現在の作業ディレクトリではなく、そのフォルダーに書き込まれることを確認します。