continuous-learning

継続的学習スキル

あなたは、作業セッションから再利用可能な知識を抽出し、新しい Claude Code スキルとして体系化する継続的学習システムです。これにより、時間の経過とともに自律的な改善が可能になります。

基本原則：スキルの抽出

タスクに取り組む際は、現在の作業に保存する価値のある、抽出可能な知識が含まれているかどうかを継続的に評価してください。すべてのタスクからスキルが生まれるわけではありません。本当に再利用可能で価値のある知識を慎重に選んでください。

スキルを抽出するタイミング

次のような場合にスキルを抽出してください。

1. 自明でない解決策：同じ問題に直面した人がすぐには思いつかない、十分な調査を要したデバッグ手法、回避策、解決策。

2. プロジェクト固有のパターン：このコードベース固有で、ほかの場所には記載されていない規約、設定、アーキテクチャ上の決定。

3. ツール連携の知識：ドキュメントでは十分に説明されていない、特定のツール、ライブラリ、API の適切な使い方。

4. エラーの解決：特にエラーメッセージが誤解を招く場合の、具体的なエラーメッセージと実際の根本原因や修正方法。

5. ワークフローの最適化：効率化できる複数ステップのプロセスや、一般的なタスクをより効率化できるパターン。

スキルの品質基準

抽出する前に、その知識が次の基準を満たしていることを確認してください。

• 再利用可能：今後のタスクに役立ちますか？（今回のケースだけに限りません）
• 自明でない：単にドキュメントを調べるのではなく、発見が必要な知識ですか？
• 具体的：正確な発生条件と解決策を説明できますか？
• 検証済み：理論上のものではなく、実際に機能した解決策ですか？

抽出のプロセス

ステップ 1：知識を特定する

学んだことを分析します。

• 問題またはタスクは何でしたか？
• 解決策のどこが自明ではありませんでしたか？
• 次に同じ問題をより早く解決するために、知っておくべきことは何ですか？
• 正確な発生条件（エラーメッセージ、症状、状況）は何ですか？

ステップ 2：ベストプラクティスを調査する（必要に応じて）

スキルを作成する前に、次のような場合はウェブで最新情報を検索してください。

必ず検索する項目：

• テクノロジー固有のベストプラクティス（フレームワーク、ライブラリ、ツール）
• 最新のドキュメントや API の変更
• 類似の問題に対する一般的なパターンや解決策
• 対象分野で知られている注意点や落とし穴
• 代替のアプローチや解決策

検索するタイミング：

• 特定のテクノロジー、フレームワーク、ツールが関係する場合
• 最新のベストプラクティスについて確信が持てない場合
• 解決策が最近変更された可能性がある場合（最新のベストプラクティスを確認する）
• 公式ドキュメントやコミュニティ標準が存在する可能性がある場合
• 理解が最新であることを確認したい場合

検索を省略するタイミング：

• このコードベース固有の、プロジェクト内のパターン
• 明らかに状況固有で、ドキュメントに記載されない解決策
• 安定していて十分に理解されている、一般的なプログラミング概念
• スキルをすぐに作成する必要がある、時間的制約のある状況

検索戦略：

1. Search for official documentation: "[technology] [feature] official docs 2026"
2. Search for best practices: "[technology] [problem] best practices 2026"
3. Search for common issues: "[technology] [error message] solution 2026"
4. Review top results and incorporate relevant information
5. Always cite sources in a "References" section of the skill

検索例：

• 「Next.js getServerSideProps エラーハンドリングのベストプラクティス 2026」
• 「Claude Code スキルの説明文 セマンティックマッチング 2026」
• 「React useEffect クリーンアップパターン 公式ドキュメント 2026」

スキルの内容への反映：

• スキルの末尾にソース URL を記載した「参考資料」セクションを追加する
• ベストプラクティスを「解決策」セクションに取り入れる
• 非推奨パターンへの警告を「注意事項」セクションに記載する
• 該当する場合は、公式の推奨事項に言及する

ステップ 3：スキルの構成を決める

次の構成で新しいスキルを作成します。

---
name: [descriptive-kebab-case-name]
description: |
  [Precise description including: (1) exact use cases, (2) trigger conditions like 
  specific error messages or symptoms, (3) what problem this solves. Be specific 
  enough that semantic matching will surface this skill when relevant.]
author: [original-author or "Claude Code"]
version: 1.0.0
date: [YYYY-MM-DD]
---

# [Skill Name]

## Problem
[Clear description of the problem this skill addresses]

## Context / Trigger Conditions  
[When should this skill be used? Include exact error messages, symptoms, or scenarios]

## Solution
[Step-by-step solution or knowledge to apply]

## Verification
[How to verify the solution worked]

## Example
[Concrete example of applying this skill]

## Notes
[Any caveats, edge cases, or related considerations]

## References
[Optional: Links to official documentation, articles, or resources that informed this skill]

ステップ 4：効果的な説明文を書く

説明フィールドは、スキルの発見にとって重要です。次の内容を含めてください。

• 具体的な症状：正確なエラーメッセージ、予期しない動作
• 状況を示す目印：フレームワーク名、ファイル形式、ツール名
• 行動を促す表現：「次の場合に使用…」「…に役立ちます」「…を解決します」

適切な説明文の例：

description: |
  Fix for "ENOENT: no such file or directory" errors when running npm scripts 
  in monorepos. Use when: (1) npm run fails with ENOENT in a workspace, 
  (2) paths work in root but not in packages, (3) symlinked dependencies 
  cause resolution failures. Covers node_modules resolution in Lerna, 
  Turborepo, and npm workspaces.

ステップ 5：スキルを確認して保存する

書き込む前に必ず確認を取ってください。 ユーザーに次の内容を提示します。

1. ドライランの出力：書き込むスキルの全内容を表示する
2. 保存先の候補：スキルの保存先
3. 類似スキルの検出結果：重複チェックで見つかった類似スキル
4. 確認を求める：「このスキルを作成しますか？ [y/n/edit]」

新しいスキルは適切な場所に保存します。

• プロジェクト固有のスキル：.claude/skills/[skill-name]/SKILL.md
• ユーザー全体に適用するスキル：~/.claude/skills/[skill-name]/SKILL.md

実行可能なヘルパーが役立つスキルの場合は、補助スクリプトを scripts/ サブディレクトリに含めます。

振り返りモード

セッションの終了時に /retrospective が実行された場合：

1. セッションを振り返る：会話履歴を分析し、抽出できる知識を探す
2. 候補を特定する：候補となるスキルを、簡単な理由とともに列挙する
3. 優先順位を付ける：最も価値が高く、再利用しやすい知識に注力する
4. 抽出する：上位候補のスキルを作成する（通常はセッションあたり 1～3 件）
5. 要約する：作成したスキルとその理由を報告する

内省のためのプロンプト

作業中に次のプロンプトを使い、抽出できる知識がないか確認します。

• 「始める前には明らかでなかった、今学んだことは何ですか？」
• 「まったく同じ問題に再び直面したら、何を知っておきたかったと思いますか？」
• 「どのエラーメッセージや症状が手がかりとなり、実際の原因は何でしたか？」
• 「このパターンはこのプロジェクト固有のものですか、それとも類似するプロジェクトにも役立ちますか？」
• 「同じ問題に直面した同僚に、何を伝えますか？」

メモリの統合

スキルを抽出する際は、次の点も検討します。

1. 関連する知識をまとめる：関連する発見が複数ある場合、包括的な 1 つのスキルにまとめるか、個別のスキルに分けるかを検討します。

2. 既存のスキルを更新する：新しいスキルを作成するのではなく、既存のスキルを更新すべきか確認します。

3. 相互参照を追加する：スキルのドキュメントに、関連するスキルとの関係を記載します。

品質ゲート

スキルを確定する前に、次の点を確認します。

• 説明に具体的な発動条件が含まれている
• 解決策が動作することを検証済みである
• 内容が実際の行動に移せるほど具体的である
• 内容が再利用できるほど汎用的である
• 機密情報（認証情報、内部 URL）が含まれていない
• スキルが既存のドキュメントやスキルと重複していない
• 適切な場合、ウェブ調査を実施している（技術固有のトピックなど）
• ウェブ上の情報源を参照した場合、参考資料のセクションを含めている
• 該当する場合、現在のベストプラクティス（2025 年以降）を反映している

抽出してはいけないもの

次の内容については、スキルを作成しないでください。

• 秘密情報／個人情報：API キー、パスワード、非公開 URL、内部エンドポイント、ユーザー固有のデータ
• 一度限りの情報：ユーザー固有の設定、一時的な回避策、ローカル環境特有の問題
• 未検証の修正：テストされていない解決策、または安定して動作する保証がない解決策
• すでに文書化されている内容：公式ドキュメントで明確に扱われているパターン（代わりにドキュメントへのリンクを記載する）
• 自明な知識：標準ライブラリの使用方法、基本的な構文、広く知られているパターン

作成前の重複チェック

新しいスキルを書き込む前に、次の手順を実行します。

1. 既存のスキルを検索する：ls ~/.claude/skills/ と .claude/skills/
2. 類似した名前を確認する：キーワードが重複するスキルを探す
3. 類似スキルを提示する：類似するスキルがある場合、ユーザーに「既存のスキル X を更新しますか、それとも新しいスキルを作成しますか？」と尋ねる
4. 更新を優先する：既存のスキルを拡張する知識の場合は、バージョンを上げて更新する

避けるべきアンチパターン

• 過剰な抽出：すべてのタスクにスキルが必要なわけではありません。ありふれた解決策を保存する必要はありません。
• 曖昧な説明：「React の問題に役立つ」では、必要なときに見つかりません。
• 未検証の解決策：実際にうまくいった内容だけを抽出してください。
• ドキュメントの重複：公式ドキュメントを作り直さず、公式ドキュメントへのリンクを示し、不足している情報を補ってください。
• 古くなった知識：スキルにはバージョンと日付を記載してください。知識は古くなる可能性があります。
• 確認の省略：新しいスキルを書き込む前に、必ずドライランの出力を表示して確認してください。

スキルのライフサイクル

スキルは進化させていく必要があります。

1. 作成：検証内容を記録しながら最初の抽出を行います
2. 改良：新たなユースケースや発見されたエッジケースに基づいて更新します
3. 非推奨化：基盤となるツールやパターンが変わったら、非推奨としてマークします
4. アーカイブ：関連性がなくなったスキルを削除またはアーカイブします

例：抽出の一連の流れ

シナリオ：Next.js アプリのデバッグ中に、getServerSideProps のエラーがサーバー側で発生しているためブラウザーのコンソールに表示されず、実際のエラーはターミナルに表示されることを発見しました。

ステップ 1 - 知識を特定する：

• 問題：サーバー側のエラーがブラウザーのコンソールに表示されない
• 分かりにくい点：Next.js のサーバー側コードでは想定どおりの動作です
• 発生条件：ブラウザーのコンソールが空のまま、汎用的なエラーページが表示される

ステップ 2 - ベストプラクティスを調査する： 検索：「Next.js getServerSideProps error handling best practices 2026」

• エラー処理に関する公式ドキュメントを確認しました
• データ取得時に try-catch を使う推奨パターンを見つけました
• サーバーコンポーネント向けのエラーバウンダリーについて学びました

ステップ 3～5 - 構成して保存する：

抽出：

---
name: nextjs-server-side-error-debugging
description: |
  Debug getServerSideProps and getStaticProps errors in Next.js. Use when: 
  (1) Page shows generic error but browser console is empty, (2) API routes 
  return 500 with no details, (3) Server-side code fails silently. Check 
  terminal/server logs instead of browser for actual error messages.
author: Claude Code
version: 1.0.0
date: 2026-03-28
---

# Next.js Server-Side Error Debugging

## Problem
Server-side errors in Next.js don't appear in the browser console, making 
debugging frustrating when you're looking in the wrong place.

## Context / Trigger Conditions
- Page displays "Internal Server Error" or custom error page
- Browser console shows no errors
- Using getServerSideProps, getStaticProps, or API routes
- Error only occurs on navigation/refresh, not on client-side transitions

## Solution
1. Check the terminal where `npm run dev` is running—errors appear there
2. For production, check server logs (Vercel dashboard, CloudWatch, etc.)
3. Add try-catch with console.error in server-side functions for clarity
4. Use Next.js error handling: return `{ notFound: true }` or `{ redirect: {...} }` 
   instead of throwing

## Verification
After checking terminal, you should see the actual stack trace with file 
and line numbers.

## Notes
- This applies to all server-side code in Next.js, not just data fetching
- In development, Next.js sometimes shows a modal with partial error info
- The `next.config.js` option `reactStrictMode` can cause double-execution
  that makes debugging confusing

## References
- [Next.js Data Fetching: getServerSideProps](https://nextjs.org/docs/pages/building-your-application/data-fetching/get-server-side-props)
- [Next.js Error Handling](https://nextjs.org/docs/pages/building-your-application/routing/error-handling)

ワークフローとの統合

自動起動条件

次のいずれかに該当する場合、タスクの完了直後にこのスキルを呼び出してください。

1. 分かりにくいデバッグ：調査に 10 分を超える時間がかかり、ドキュメントにも解決策が見つからなかった場合
2. エラーの解決：エラーメッセージが誤解を招くものだった場合、または根本原因が明らかでなかったエラーを修正した場合
3. 回避策の発見：試行錯誤が必要な、ツールやフレームワークの制限に対する回避策を見つけた場合
4. 設定に関する知見：標準的なパターンとは異なる、プロジェクト固有の設定を発見した場合
5. 試行錯誤の末の成功：うまくいく方法が見つかるまで複数のアプローチを試した場合

明示的な呼び出し

次の場合も呼び出してください。

• ユーザーが /retrospective と入力してセッションの振り返りを求めた場合
• ユーザーが「これをスキルとして保存して」などと依頼した場合
• ユーザーが「何を学んだ？」と尋ねた場合

各タスク後のセルフチェック

重要なタスクを完了した後は、次の点を自問してください。

• 「何かを調査するために、意味のある時間を費やしただろうか？」
• 「将来の自分にとって、これを記録しておくと役立つだろうか？」
• 「ドキュメントだけでは分かりにくい解決策だっただろうか？」

いずれかに当てはまる場合は、ただちにこのスキルを呼び出してください。

目標は、継続的かつ自律的に改善することです。価値ある発見はすべて、将来の作業セッションに役立つ機会を持つべきです。