learn

このセッションから学びます。うまくいったこと、うまくいかなかったことを抽出し、今後のセッションがより良くなるようにドキュメントを更新します。また、ユーザーが Claude とより効率的に作業するための直接的なフィードバックも提供します。

Instructions

$ARGUMENTS を解析し、任意の重点分野（例：mistakes、efficiency、workflow）を確認します。空の場合は、全体をレビューします。

Step 0: 効率性の監査（Elon の 5 ステップフレームワーク）

何よりも先に、このセッションで行った作業を、次の各ステップに沿って順番に監査します。

1. 要件を見直す

• 事実として述べられていたものの、実際は仮定だった要件はありましたか？この方法で行う必要があると言ったのは誰ですか？
• 成果に対して責任を負わない人が要件を出していませんでしたか？
• 振り返ってみて、愚か、誤り、または不要だった要件があれば指摘します。

2. 作業やプロセスを削除する

• 価値を損なわずに、完全に削除できた手順、成果物、生成物はありますか？
• 使われない成果物は作られていませんでしたか？「いつもそうしているから」という理由で実行したプロセスはありませんでしたか？
• 残す理由を説明できないものは、削除すべきです。

3. 設計を簡素化または最適化する

• 削除した後でも、複雑すぎるものは何ですか？
• 同じ結果を得られる、より簡潔な方法はありましたか？価値を生まない手順は何でしたか？

4. サイクル時間を短縮する

• セッションのどこで時間がかかりましたか？ツールの結果待ち、反復、やり取りの往復などです。
• どうすれば 2 倍速く進められましたか？

5. 自動化する

• このセッションで手作業だったことのうち、自動化すべきものは何ですか？（スキル、n8n ワークフロー、メモリの更新など）
• ステップ 1〜4 の後にのみ自動化します。愚かなプロセスを自動化してはいけません。

次の簡潔で、明確な意見を示す表として出力します。

Step	Finding	Verdict
要件	{愚かだった要件、または必要だった要件}	削除 / 維持
削除	{削除できたもの}	削除すべきだった
簡素化	{過剰に複雑だったもの}	次回は簡素化
速度	{時間がかかった箇所}	改善策：{提案}
自動化	{自動化するもの}	スキル / サブエージェント / n8n / メモリ

Step 1: セッションの監査

現在の会話を確認し、次の点を特定します。

うまくいかなかったこと：

• エラー、行き詰まり、再試行、無駄な手順
• ユーザーと Claude の間の誤解（曖昧なプロンプト、誤った仮定）
• 失敗したツールや、想定外の結果を返したツール
• 途中で放棄されたアプローチ

うまくいったこと：

• 効率的なパターン（並列エージェントの適切な活用、明確なプロンプト、賢い順序付け）
• 時間やトークンを節約した判断
• 繰り返すべきワークフロー

学んだこと：

• システム、データ、プロセス、ツールについて新たに分かったこと
• 以前の仮定の訂正
• 文書化すべきパターン

次に進む前に、これらを簡潔にまとめて返します。

ステップ 2：ドキュメントの更新 — スキルとメモリの判断

セッションの監査で得られた各知見を分類します。

SKILL を更新する場合：

• ワークフローを実行した結果、誤った出力になった、または余計な手順が必要になった
• 指示が不足していたため、スキルの実行中に Claude が脱線した
• スキルで対処すべき新たなエッジケースが見つかった
• スキルが呼び出されたものの、説明が実際の起動条件と一致していなかった

MEMORY を更新する場合：

• システム、ツール、データソースについて新しい事実がわかった
• 幅広く適用される好みや規約が確立された
• 特定のスキルに関係しない、以前の想定に対する訂正があった

新しい SKILL を作成する場合：

• 手作業で 3 つ以上の手順を要する作業を行い、今後も繰り返し発生する
• Claude に同じ複数手順の指示を 2 回繰り返していることに気づいた
• 明確な起動条件と出力を持つワークフローがセッション中に生まれた

サブエージェントを作成する場合：

• 複数の独立した作業を同時に進められるなど、タスクを並列化できる
• タスクに時間がかかり、中間結果でメインのコンテキストウィンドウが埋まってしまう
• 途中でユーザーの入力を必要とせず、複数の手順にわたって自律的にツールを使用する必要がある
• 作業が十分に独立しており、セッション履歴のない新しいコンテキストが負担ではなく利点になる

スキルとサブエージェントの判断基準： 一貫した 起動条件 + プロンプトテンプレート がある作業にはスキルを使います。自律的な実行 + ツール呼び出し + 並列化 が必要な作業にはサブエージェントを使います。多くのワークフローでは両方が必要です。サブエージェントを起動するスキルを作成します。

CLAUDE.md を更新する場合：

• 「常に X を行う」または「Y は決して行わない」という新しいルールが見つかった
• ワークスペースの振り分けルールが変わった
• 新しい MCP インテグレーションが追加された

変更案ごとに、次の表を表示します。

変更	対象	種別	理由
{description}	{file path}	スキルの編集 / メモリ / 新しいスキル / CLAUDE.md	{what happened}

ユーザーの承認を得るまで、変更を一切書き込まないでください。 次のように尋ねます。「すべて、一部、またはいずれも適用しない場合、どれにしますか？」

ステップ 3：ユーザーへのフィードバック

Claude をより効率よく活用する方法について、率直で具体的なフィードバックを伝えます。正直に伝えてください。これは褒める場ではなく、コーチングの機会です。

構成：

## How to Get More Out of Claude

### Token Efficiency
{Were prompts unnecessarily long? Could context have been set once instead of repeated? Were there unnecessary back-and-forth cycles that a clearer initial prompt would have avoided?}

### Prompt Patterns
{What worked: e.g., "When you gave me the exact format you wanted, I nailed it first try."}
{What to try: e.g., "Next time you need X, try prompting with Y — it'll save a round trip."}

### Workflow Suggestions
{Could more work have been parallelized? Were there manual steps that could be skills? Did the user do something Claude should have done, or vice versa?}

### One Thing to Try Next Time
{The single highest-leverage change to how we work together.}

このセッションに即した具体的な内容にします。実際にあった場面を挙げてください。一般論の生産性向上アドバイスは避けてください。

ステップ 4：承認された変更を適用する

ユーザーが承認（すべて、一部、またはいずれもなし）した後に、次の操作を行います。

• 承認されたメモリファイルを書き込む
• 承認されたスキルファイルを編集する
• 承認された場合は CLAUDE.md を更新する
• 更新した内容を確認する

ステップ 5：AI 成長のためのプロンプト

セッションの文脈に基づき、次のいずれかを 1 つ選びます。より関連性の高いものを選んでください。

オプション A — 学習プロンプト（セッションで、さらに深掘りできる AI ツール、モデル、ワークフロー、概念を扱った場合に使用）：

このセッションで最も関連性の高い AI 概念を特定し、具体的な参考資料を提案します。形式：

## Learn Something

This session touched [concept]. Go deeper:

**Read:** [specific doc, post, or paper — link if you know it, otherwise describe exactly what to search for]
**Why it matters for your work:** [one sentence connecting it to courses, revenue, or automation]
**What to look for:** [the specific thing to extract from the read — a pattern, a technique, a mental model]

次の情報源を使用してください：Anthropic のドキュメント（プロンプトエンジニアリング、ツールの使用、エージェント）、AI 分野の有識者（Andrej Karpathy、Simon Willison、Ethan Mollick、AI に関する Lenny Rachitsky）、または最近の AI ニュース（特定のモデル、ツール、機能が使われ、注目すべき報道がある場合）。

オプション B — 評価の質問（セッションの大部分が、構築、執筆、分析などの実作業だった場合に使用）：

作業が本当に適切なものだったかを評価するための、難しい質問を 1 つ尋ねます。次の例から選ぶか、応用してください。

## Honest Eval

[One of these, adapted to what actually happened:]

- Was any of this necessary? What would have happened if you hadn't done it?
- What's the single most questionable decision made in this session, and who challenged it?
- If you had to cut 40% of the output and keep only the most valuable, what survives?
- Did you solve the real problem, or the problem as originally stated?
- What assumption drove this session that you never actually validated?

オプション A を選ぶのは、セッションでユーザーがこれまで触れたことのない新しい AI の概念、機能、ツールが実際に登場し、さらに深掘りする余地がある場合に限ります。使い慣れた AI ツールを通常の方法で使っただけの場合は、「機能」に関するセッションであっても、オプション B を選びます。迷った場合はオプション B を選んでください。

メモ

• このスキルは、物事がスムーズに進まなかった長時間または複雑なセッションの後に最も役立ちます
• ドキュメントの更新は永続的な成果物であり、今後のセッションを重ねるごとに価値が高まります
• フィードバック欄では率直に伝えてください。ユーザーは明確にそう求めています。表現を和らげないでください
• セッションが完璧に進み、学ぶべきことが何もなければ、そのように伝えてください。無理にフィードバックを作り出さないでください
• ユーザーに事前に見せて承認を得ずに、ドキュメントを更新しないでください
• メモリファイルを更新する際は、メモリシステムの形式（name、description、typeを含むフロントマター）に従ってください