project-teacher

Project Teacher

ユーザーが学べるよう、「なぜ」と「どのように」に焦点を当て、現在のプロジェクトやタスクについて詳しい説明を生成します。

使用方法

起動すると、学習リソースを含む Markdown ファイルを生成します。

1. 既存ドキュメントの確認（同期）

新しいファイルを生成する前に、出力ディレクトリ（デフォルト：learning/）を検索し、現在のプロジェクトに関連する既存ドキュメントを探します。

• 該当するドキュメントが見つかった場合：ユーザーに尋ねます。 「既存の学習ドキュメント『[Filename]』が見つかりました。更新しますか、それとも新しいスナップショットを作成しますか？」
• ユーザーが更新を選んだ場合：
  1. 名前の変更：最新の状態を反映するため、末尾の日付を今日の日付に更新します（例：API_Layout - 2024-03-25.md）。
  2. メタデータ：フロントマターのlastフィールドとcommitフィールドを更新します。
  3. 内容：古くなったセクションを書き直します。ただし、今も当てはまる価値ある過去の背景情報は残します。
  4. 履歴：末尾の## Version historyセクションに1行追加します（なければ作成します）。
• ユーザーが新規作成を選んだ場合、または該当するドキュメントが見つからない場合：新しいファイルを作成します。

2. 保存先

1. ユーザーの希望を確認する：ユーザーが保存先（例：「自分のVaultに保存」）を指定した場合は、そこを使用します。
   • Obsidian／外部Vault：外部のObsidian Vaultに保存する場合は、まずそのルートまたは.cursor/／.claude/フォルダーに、適用できるコンテキストファイルがないか確認します。これらのファイルには、そのシステムでノートを保存・整形するための個別の指示が含まれていることがよくあります。見つかった場合は、その指示に従います。
2. デフォルトの保存先：保存先が指定されていない場合は、プロジェクトルートにlearning/という名前のディレクトリを使用します。
   • learning/ディレクトリが存在しない場合は作成します。
   • 重要：learning/が.gitignoreに含まれているか確認します。含まれていない場合は、これらの個人用ドキュメントが共有リポジトリにコミットされないよう、.gitignoreに追加します。
3. ファイル名：[Descriptive title] - [YYYY-MM-DD].mdという形式でファイル名を付けます。
   • 構成：[Topic or Component] - [Date].md。先頭部分には、何について説明するのかを示す、意味が明確で具体的な名前を付けます。
   • 例：
     • Authentication system walkthrough - 2024-03-25.md
     • Recipe parser logic - 2024-03-25.md
     • Project Teacher overview - 2024-03-25.md

3. ファイル構成とメタデータヘッダー

機械可読なステータスにはYAMLフロントマターを、人が読むための補足にはコールアウトを使用します。

---
last: [YYYY-MM-DD]
commit: [Current Git Commit Hash or "N/A"]
tags: [project-teacher, learning, ...]
---

# [Descriptive title in sentence case]

> [!NOTE]
> **Context**: [Brief description, e.g., "Updated after migration to v2"]
> _This document reflects the system state at the time of the last update._

## Code index
*   [MainController.ts](path/to/MainController.ts) - Handles the core logic for...
*   [UserAuth.ts](path/to/UserAuth.ts) - Manages session state.
*   [api/endpoints/](path/to/api/endpoints/) - API route definitions.

## 1. Project overview
[Explain the whole project in plain language as an expert tutor. What did we just build?]

## 2. Architecture and logic
[Use ASCII diagrams or Mermaid charts here to visualize how data flows or how components interact.]

## 3. Key technical decisions
[Explain "why" technical decisions were made.]

### Trade-offs and alternatives
[Explicitly mention what alternatives were considered and why they were rejected. e.g., "Considered using Redux, but opted for React Context because..."]

---
## Version history
*   **[YYYY-MM-DD]**: [Brief note on what changed, e.g. "Initial creation"]
*   **[YYYY-MM-DD]**: [e.g. "Updated diagram to reflect new caching layer"]

## Reflection questions
*   [Question 1 asking about a specific architectural choice]
*   [Question 2 asking about a potential edge case]
*   [Question 3 challenging the user to explain a complex part of the code]

4. 文体とビジュアル

• 見出しの指針：
  • センテンスケース：見出しには必ずセンテンスケースを使用します（例：「Architecture and logic」は可、「Architecture And Logic」は不可）。
  • 具体的にする：見出しは、実際の内容を具体的に表すものにします。一般的な「Challenges」ではなく、「Handling concurrent requests」のようにします。
• 視覚的に説明する：複雑なロジック、データフロー、状態の変化を説明するには、（コードブロックを使った）ASCII図やMermaidチャートを使用します。多くの場合、仕組みを視覚的に表現するほうが、文章で説明するよりも有用です。
• コードインデックス：先頭に「Code index」または「Quick links」セクションを必ず含めます。これにより、ユーザーはIDEで関連ファイルに直接移動できます。
• トレードオフ：トレードオフを扱うセクションを必ず含めます。深く学ぶうえで重要です。
• 振り返り：ユーザーの理解を確かめる問いで締めくくります。ただし、答えは提示しません。
• 柔軟に対応する：内容に合わない場合は、説明を固定的なテンプレートに無理に当てはめないでください。学習に最も効果的な流れになるよう、見出しを調整します。
• 熟練のチューターとして：コードの行ごとの説明だけでなく、その背後にある考え方を理解したい優秀な同僚に説明するように書きます。