serena-usage

Serena の使用方法

プロジェクトメモリ管理、コードインテリジェンス、AI エージェントのセッション間での継続性維持における、Serena MCP Server の効果的な使用方法です。

• 利用可能な場合は、ネイティブの並列サブエージェントのディスパッチと 200k 以上のコンテキストウィンドウを活用してください。

有効化条件

症状からアクションへのトリガーを使用します。一致するものがあれば、このスキルを適用し、以下のプロトコルに従って確認してください。

必ず有効化する条件：

• プロジェクトで Serena を利用できる
• タスクでプロジェクトメモリの継続性が必要
• タスクでシンボルナビゲーションまたは Serena のリファクタリングワークフローが必要
• AI セッションの継続性のためにプロジェクトメモリを管理する
• シンボルベースのツールを使用してコードベースをナビゲートする
• Serena のシンボル管理を使用してコードをリファクタリングする
• 新しいプロジェクト向けに Serena のオンボーディングを設定する
• プロジェクトのコンテキストを保持するために Serena のメモリシステムを使用する

重要：Serena の操作を行う前に、必ず最初に get_current_config でプロジェクトの有効化を確認してください

前提条件

• Serena MCP Server が設定され、実行中であること
• プロジェクトが有効化されていること（get_current_config で確認するか、未有効化の場合は activate_project を使用）
• 対象プロジェクトのオンボーディングが完了していること（最初に check_onboarding_performed を使用）
• 未有効化の場合は、プロジェクト名またはパスを指定して activate_project を実行する
• オンボーディングが未完了の場合は、有効化後に onboarding ツールを実行する

---

オンボーディングのワークフロー

プロジェクトの初回セットアップ

1. 有効化を確認する：get_current_config を呼び出し、プロジェクトが有効化されているか確認します
2. 必要に応じて有効化する：未有効化の場合は、プロジェクト名またはパスを指定して activate_project を呼び出します
3. オンボーディングを確認する：check_onboarding_performed を呼び出し、オンボーディングの状態を確認します
4. マニュアルを読む：オンボーディングが未完了の場合は、initial_instructions を呼び出して Serena Instructions Manual を読みます
5. 初期化する：onboarding を呼び出してプロジェクトのセットアップを完了します
6. Serena がプロジェクト構造を分析し、初期コンテキストを作成します

オンボーディングで取得される内容

• プロジェクトの言語とフレームワークの検出
• ディレクトリ構造の分析
• 重要なファイルの特定
• シンボルインデックスの作成
• 初期メモリの足場づくり

有効化確認のパターン

# Always verify activation first
get_current_config
# If no active project, activate it
activate_project project="path/to/project"
# Then proceed with onboarding check
check_onboarding_performed

プロジェクトの有効化

有効化が重要な理由

Serena を使用する際は、プロジェクトの有効化が最初の手順です。作業対象のプロジェクトを Serena に伝え、ワークスペースのコンテキストを初期化します。

有効化のワークフロー

1. 現在の状態を確認する：get_current_config を呼び出し、すでにプロジェクトが有効化されているか確認します
2. 必要に応じて有効化する：アクティブなプロジェクトがない場合は、次を呼び出します。

   activate_project project="project-name"
   # OR with path:
   activate_project project="path/to/project/directory"
   

3. 有効化を確認する：再度 get_current_config を呼び出し、有効化が成功したことを確認します
4. オンボーディングに進む：有効化したら、オンボーディングが必要か確認します

有効化のベストプラクティス

• Serena の操作を行う前に、必ず get_current_config を確認してください
• 有効化するときはワークスペースのルートパスを使用してください
• 有効化はセッションごとに行われます。新しいセッションでは再度有効化が必要になる場合があります
• 有効化後は、以降のすべての Serena 操作でプロジェクトのコンテキストを利用できます

---

メモリ管理

基本概念

Serena のメモリはセッション間で保持され、作業セッションをまたいだ AI エージェントの継続性を支えます。

メモリ操作

操作	ツール	目的
すべてを一覧表示	list_memories	利用可能なメモリを確認する
1 件を読み取る	read_memory	特定のメモリの内容にアクセスする
作成	write_memory	新しい情報を保存する
更新	edit_memory	既存のメモリを変更する
削除	delete_memory	古くなった情報を整理する

メモリ構造

Serena のメモリは、一貫性と明確さを保つために Memory Bank の命名規則を使用します。この構造により、プロジェクトのインテリジェンスを主要ファイルとタスクに整理できます。

コアファイル

メモリ名	目的
project-brief	コア要件と目標を定義する基盤ドキュメントです。他のすべてのメモリの指針となります。プロジェクト開始時に作成されます。
product-context	このプロジェクトが存在する理由、解決する課題、期待される動作、ユーザー体験の目標です。
active-context	現在の作業の焦点、最近の変更、次のステップ、進行中の決定事項や検討事項です。
system-patterns	システムアーキテクチャ、主要な技術的決定、使用中のデザインパターン、コンポーネント間の関係です。
tech-context	使用するテクノロジー、開発環境、技術的な制約、依存関係です。
progress	動作している機能、今後実装する内容、現在の状況、既知の問題です。

タスク管理メモリ

タスクの進捗と履歴を追跡するため、専用のメモリファイルで管理します。

メモリ名	目的
task-{id}	個々のタスクを追跡します（例：TASK001-implement-login.md）。元のリクエスト、思考プロセス、実装計画、進捗ログを記録します。
task-index	ID、名前、ステータス（Pending/In Progress/Completed/Abandoned）、最終更新日を含む、すべてのタスクの一覧です。

タスクメモリの構成

各タスクメモリは、次の形式に従います。

# [Task ID] - [Task Name]

**Status:** [Pending/In Progress/Completed/Abandoned]
**Added:** [Date Added]
**Updated:** [Date Last Updated]

## Original Request
[The original task description as provided by the user]

## Thought Process
[Documentation of the discussion and reasoning that shaped the approach]

## Implementation Plan
- [Step 1]
- [Step 2]
- [Step 3]

## Progress Tracking

**Overall Status:** [Not Started/In Progress/Blocked/Completed] - [Completion Percentage]

### Subtasks
| ID | Description | Status | Updated | Notes |
|----|-------------|--------|---------|-------|
| 1.1 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Relevant notes] |

## Progress Log
### [Date]
- Updated subtask 1.1 status to Complete
- Started work on subtask 1.2
- Encountered issue with [specific problem]
- Made decision to [approach/solution]

タスクインデックスの構成

task-index メモリには、次の構造化された記録を保持します。

# Tasks Index

## In Progress
- [TASK003] Implement user authentication -Working on OAuth integration
- [TASK005] Create dashboard UI -Building main components

## Pending
- [TASK006] Add export functionality -Planned for next sprint

## Completed
- [TASK001] Project setup -Completed on 2025-03-15
- [TASK002] Create database schema -Completed on 2025-03-17

コマンド

add task または create task をリクエストすると、エージェントは次の処理を行います。

1. 一意の Task ID を持つ新しいタスクメモリを作成します
2. アプローチに関する思考プロセスを記録します
3. 実装計画を作成します
4. 初期ステータスを設定します
5. task-index メモリを更新します

タスクを表示するには、コマンド show tasks [filter] を実行します。有効なフィルターを指定して、絞り込んだ一覧を表示できます。

• all - ステータスにかかわらず、すべてのタスクを表示します
• active - 「In Progress」のタスクのみを表示します
• pending - 「Pending」のタスクのみを表示します
• completed - 「Completed」のタスクのみを表示します
• blocked - 「Blocked」のタスクのみを表示します
• recent - 過去1週間に更新されたタスクを表示します

メモリを更新するタイミング

コアメモリを更新するタイミング：

• 重要な機能を実装した後
• アーキテクチャ上の決定を行ったとき
• 新しいプロジェクトのパターンや規約を発見したとき
• 技術スタックや依存関係を変更したとき
• データモデルやスキーマを変更したとき
• 各作業セッションの開始時と終了時

タスクメモリを更新するタイミング：

• 「create task」コマンドで新しいタスクを作成したとき
• 既存のタスクを進めたとき
• サブタスクまたはタスク全体を完了したとき
• ブロッカーや問題に遭遇したとき
• タスクのステータスを変更したとき（Pending → In Progress → Completed/Abandoned）

メモリ作成ワークフロー

重要：新しいメモリを作成する前に、関連する既存のメモリを必ず確認してください

手順

1. 利用可能なメモリを一覧表示する：list_memories を使用して、既存のメモリをすべて確認します
2. 関連性を分析する：既存のメモリが同じトピックや概念を扱っているか確認します
3. メモリの内容を確認する：関連するメモリが見つかった場合は、read_memory を使用して内容を確認します
4. 一致条件を確認する：
   • 同じ機能、テクノロジー、またはトピックの領域である
   • 目的または範囲が重複している
   • 関連するアーキテクチャ上の決定が含まれている
   • 類似する問題領域または懸念事項を扱っている
5. 判断する：
   • 関連するメモリが存在する場合：新しい情報と現在のタイムスタンプを追加して、edit_memory で既存のメモリを更新します
   • 関連するメモリが存在しない場合：write_memory を使用して新しいメモリを作成します

一致のガイドライン

新しいメモリー項目は、次の条件に当てはまる既存のメモリーがあれば、そのメモリーに関連しています。

条件	例
同じ機能領域	「admin-features」がすでに管理ワークフローを扱っている → 新しい管理タスクの詳細を追加する
同じテクノロジー	「auth-context」がすでに認証を扱っている → 新しい認証の実装詳細を追加する
関連するアーキテクチャ	「system-patterns」がアーキテクチャ上の決定を扱っている → 新しいアーキテクチャ上の選択を追加する
同じドメイン上の関心事	「ui-components-and-styling」がコンポーネントライブラリを扱っている → 新しいコンポーネント仕様を追加する
プロジェクト全体の更新	「project-overview」が全体の状況を扱っている → 一般的なプロジェクト更新を追加する

既存のメモリーを更新するパターン

既存のメモリーを更新するときは、次の構成に従います。

## {Topic} — Updated [YYYY-MM-DD HH:MM]

### [Date] - Update
- [New information or decision]
- [Implementation details or findings]
- [Related changes or impacts]
- [Next actions or considerations]

### Previous Context
[Preserve existing relevant information]

メモリーを統合する例

シナリオ 1：新しい管理機能の仕様を追加する

Existing: admin-features.md (500 bytes)
New info: New user moderation workflow specs
Action: Update admin-features.md with new section, update timestamp

シナリオ 2：SQL のバグを修正する

Existing: csx3006-sql-fixes-2026-02-13.md
New info: Another SQL bug related to same issue
Action: Update csx3006-sql-fixes-2026-02-13.md, add new fix details, update timestamp

シナリオ 3：新しい認証の実装詳細

Existing: auth-context.md
New info: Session management implementation specifics
Action: Update auth-context.md with new implementation section, update timestamp

シナリオ 4：別の問題に対する新しいデータベース修正メモリー

Existing: csx3006-sql-fixes-2026-02-13.md (column name fixes)
New info: Index optimization fixes (different topic)
Action: Create NEW memory: csx3006-index-fixes-2026-02-16.md

新しいメモリーを作成する場合

次の場合に限り、新しいメモリーを作成します。

• 異なるドメイン：既存のメモリーとは根本的に異なるトピック
• 重要なマイルストーン：新しいフェーズやプロジェクトの大きな転換
• 新しいテクノロジースタック：既存の技術的コンテキストとは無関係
• 時間ベースの追跡：修正メモリー、日次更新、日付入りログ
• サイズが大きすぎる：追加すると既存のメモリーが 5～10 KB を超える場合

新しいメモリーを作成する場合の例：

Existing: admin-features.md
New: Performance analysis reports → Create NEW: performance-analysis.md

Existing: ui-components-and-styling.md
New: Mobile responsiveness specifications → Create NEW: mobile-responsive.md

Existing: csx3006-sql-fixes-2026-02-13.md (database schema corrections)
New: API endpoint bug fixes → Create NEW: api-fixes-2026-02-16.md

Memory Bank のドキュメント作成ガイドライン

Serena のメモリーは、包括的なプロジェクト情報を提供するため、Memory Bank の構成に従います。主なガイドラインは次のとおりです。

タスクの進捗更新：

• 進捗があった場合は、サブタスクのステータステーブルと進捗ログの両方を必ず更新します
• サブタスクのテーブルは、現在の状況をすばやく視覚的に確認するためのものです
• 進捗ログには、作業プロセスの経緯と詳細を記録します
• 進捗ログの各項目には、日付、達成事項、課題、決定事項を記載します
• 現在の進捗を反映するため、task-index のタスクステータスを更新します

ドキュメント作成の流れ：

New Task → Create task-{id}.py memory → Update task-index
Progress → Update task-{id}.py log table → Update task-index
Discovery → Create/ update appropriate core memory
Architecture Decision → Update system-patterns memory
Completion → Update progress memory → Clear from active tasks

アクティブコンテキストの形式：

## Active Context — Updated [Date]

### Current Focus
- Implementing user authentication with NextAuth.js
- Building recipe CRUD API routes

### Recent Decisions
- Chose MongoDB Atlas over Cosmos DB for cost
- Using server components for recipe listing page

### Blockers
- Image upload size limit needs investigation

### Next Steps
1. Complete login/signup UI
2. Add recipe creation form
3. Set up image upload to Blob Storage

メモリーの作成ガイドライン

## Active Context — Updated [Date]

### Current Focus
- Implementing user authentication with NextAuth.js
- Building recipe CRUD API routes

### Recent Decisions
- Chose MongoDB Atlas over Cosmos DB for cost
- Using server components for recipe listing page

### Blockers
- Image upload size limit needs investigation

### Next Steps
1. Complete login/signup UI
2. Add recipe creation form
3. Set up image upload to Blob Storage

---

コードナビゲーション

シンボルベースのナビゲーション

ツール	用途
find_symbol	名前パスを指定して、特定のクラス、関数、変数を見つけます
find_referencing_symbols	コードベース全体からシンボルの使用箇所をすべて見つけます
get_symbols_overview	ファイル内のシンボルの概要を確認します

ナビゲーションのワークフロー

1. ファイルに対して get_symbols_overview を使い、構造を把握します
2. find_symbol を使い、特定の定義を見つけます
3. 変更の前に find_referencing_symbols を使い、影響範囲を把握します

---

コードのリファクタリング

Serena を使った安全なリファクタリング

ツール	操作
rename_symbol	すべての参照箇所で名前を変更します
replace_symbol_body	関数やメソッドの実装を置き換えます
insert_after_symbol	定義の後に新しいコードを追加します
insert_before_symbol	定義の前に新しいコードを追加します

リファクタリングのワークフロー

1. 把握する：find_symbol と get_symbols_overview を使います
2. 影響を評価する：find_referencing_symbols を使い、すべての使用箇所を確認します
3. 計画する：必要な変更を検討します
4. 実行する：名前変更、置換、挿入のツールを使います
5. 検証する：参照箇所を再確認し、正しく変更されていることを確かめます
6. 記録する：変更の理由をメモリーに反映します

---

ファイル検索

ツール	目的
find_file	名前のパターンに一致するファイルを見つけます
list_dir	ディレクトリーの内容を確認します
search_for_pattern	コードベース全体からテキストや正規表現のパターンを検索します

---

タスクへの準拠

Serena は、集中力を維持するための振り返りツールを提供します。

ツール	使用するタイミング
think_about_collected_information	コンテキストを収集した後 — 十分ですか？
think_about_task_adherence	多くのやり取りを行った後 — まだ軌道に乗っていますか？
think_about_whether_you_are_done	結論を出す前 — すべて完了しましたか？

---

セッションのワークフロー

セッションの開始

1. 有効化を確認する：get_current_config → プロジェクトが有効化されているか確認します
2. 必要に応じて有効化する：アクティブなプロジェクトがない場合は、activate_project → ワークスペースを有効化します
3. オンボーディングを確認する：check_onboarding_performed → オンボーディングの状況を確認します
4. 必要に応じて、オンボーディングのワークフローを使用してオンボーディングを完了します
5. list_memories → 利用可能なプロジェクトメモリを10件すべて確認します
6. read_memory → 現在の作業フェーズに関連するメモリを読み込みます：
   • 常に： project-overview を読み込みます（現在の状況、技術スタック、次のステップ）
   • フェーズ4（バックエンド）： database-integration-implementation-plan-task を読み込みます（TASK-057 から TASK-092）
   • 機能作業： 対象の機能メモリ（admin-features、recipe-features、auth-context）を読み込みます
   • SQL 作業： csx3006-sql-fixes-2026-02-13.md を読み込みます（カラムの規約、FK のパターン）
   • Notion 同期： notion-implementation-tracking.md を読み込みます（更新プロトコル）
7. 現在のフェーズのコンテキストを踏まえて作業を開始します

セッション中

• SQL／データベース作業： {topic}-fixes-{date}.md があるか確認します → バグ修正用に更新するか、新しいメモリを作成します
• 機能の実装： {feature-name}.md があるか確認します → 機能仕様用に更新するか、新しいメモリを作成します
• フェーズの完了： 新しい状況の割合と現在のタイムスタンプで project-overview.md を更新します
• Notion の更新： 計画タスク（TASK-001 → TASK-138）の完了後に notion-update-page を使用します
• コードのナビゲーション： シンボルツールを使用して、React コンポーネントと今後の PHP バックエンドファイルを調べます
• 新しい情報の取り込み：
  1. list_memories を使用して、既存のメモリをすべて確認します
  2. 既存のメモリに該当するトピックがあるか特定します
  3. 関連するメモリがある場合：新しい情報と更新したタイムスタンプを使って edit_memory を使用します
  4. 関連するメモリがない場合：write_memory を使用して新しいメモリを作成します

---

ベストプラクティス

• Serena の操作を行う前に、必ず get_current_config を使って有効化の状態を確認します
• 新しいメモリを作成する前に、必ず list_memories で関連する既存のメモリを確認します
• 重要：重複を作成するのではなく、edit_memory を使って既存のメモリを更新し、新しいタイムスタンプを設定します
• まだ有効化されていない場合は、まず activate_project を使用してプロジェクトを有効化します
• プロジェクトで初めて使用する前に、有効化後のオンボーディング状況を確認します
• メモリは簡潔に保ち、散文よりも構造化データを優先します
• メモリは一括で書き直すのではなく、段階的に更新します
• Memory Bank の規約に従い、プロジェクト間でメモリの命名を統一します
• 複雑なタスクの振り返りには think_about_* ツールを活用します
• タスクを追跡する場合：タスクメモリのサブタスク表と進捗ログの両方を必ず更新します
• タスクメモリのステータスが変更されたら、task-index も同期します
• 混乱を防ぐため、古くなったメモリは削除します
• 作業について話し合う際は、task-index のタスク ID を参照として使用します
• 既存のメモリに情報を追加する場合は、タイムスタンプを YYYY-MM-DD HH:MM 形式に更新します

トラブルシューティング

問題	解決策
プロジェクトが有効化されていない	get_current_config を実行して確認し、プロジェクトのパスを指定して activate_project を実行します
オンボーディングが検出されない	有効化した後、onboarding ツールを明示的に実行します
メモリが見つからない	list_memories で正確な名前を確認します
シンボルが見つからない	ファイルがインデックス化されていることを確認します。より広い範囲の名前を試してください
古いメモリ	edit_memory を使用して、現在の状態とタイムスタンプで更新します
矛盾するメモリ	古いエントリを削除し、内容を統合して単一のメモリにまとめます
重複したメモリ	新しいメモリを作成する前に必ず list_memories を確認して重複を避けます。既存のメモリは edit_memory で更新します
どのメモリを更新すべきか分からない	list_memories を使う → 各メモリの目的を確認する → 関連するメモリを読む → 最も適切なメモリを更新します

---

クライアント間のポータビリティ

このスキルは、GitHub Copilot、Claude Code、Codex で引き続き使用できるように作成されています。

• GitHub Copilot：フォルダーを Copilot から認識できるスキルパスに置くか、フォルダーの検出ができない場合はワークフローをプロジェクトの指示に含めます。
• Claude Code：フォルダーをローカルのスキルディレクトリまたは互換性のあるプラグインソースに置きます。
• Codex：フォルダーを $CODEX_HOME/skills/serena-usage にインストールまたは同期し、大幅な変更を加えた後は Codex を再起動します。

MCP の利用可能性とフォールバック

推奨 MCP サーバー：Serena MCP

• フォールバックプロンプト：「MCP を使わずに Serena Usage スキルを使用してください。文書化されたローカルまたは手動のフォールバックに従い、選択したツールの構成を示し、検証の証拠を報告してください。」
• Serena を利用できない場合は、rg、git diff、対象を絞ったファイルの読み込み、ローカルの Markdown メモリファイルを使用します。
• セッションをまたいでもプロジェクトの継続性を保てるよう、リポジトリのドキュメントまたはメモに軽量な Memory Bank を用意します。
• 現在のホストで MCP が公開されていない場合は、MCP の操作を使用したと主張しないでください。

アンチパターン

• 明確な成功条件を定めずに開始する：スキルがワークフローではなく、単なるアドバイスのようになってしまいます。
• 同梱されたリファレンスやスクリプトを使わない：カタログが維持しようとしている、実証済みの手順を失います。
• 具体的な証拠なしに完了を主張する：後続のエージェントやレビュー担当者が結果を信頼できず、安全に作業を再開できません。

検証プロトコル

「スキルが正常に適用されました」と主張する前に、次のことを確認します。

1. 合格／不合格：Serena Usage のワークフローで、エージェントの境界、委任する範囲、期待される成果物を明示しています。
2. 合格／不合格：ヘルパーに渡すコンテキストは最小限で、タスクに限定され、隠れた期待解答を含んでいません。
3. 合格／不合格：コントローラーが証拠、差分、引用を確認した後にのみ、結果を統合しています。
4. 耐性テストのシナリオ：前提や漏洩したコンテキストを共有してはならない、類似した2つのタスクでワークフローを実行します。
5. 成功指標：コンテキストの漏洩がゼロであり、委任したすべての出力を個別にレビューできます。

参考資料とリソース

ドキュメント

• メモリ管理 — メモリの命名規則、ライフサイクル、保守のベストプラクティス
• シンボルナビゲーション — find_symbol と find_referencing_symbols のパターンおよびワークフロー

プロジェクト固有ガイド（レシピ共有システム）

現在のメモリー構成（有効なメモリー 10 件）：

メモリー	目的	備考
project-overview	プロジェクトの状況、技術スタック、次のステップ	中心的な参照先です。最初に読みます
database-integration-implementation-plan-task	138 タスクの計画 v2.0 の状況	38% 完了（フェーズ 1～3 は完了）
csx3006-sql-fixes-2026-02-13	SQL スクリプトの修正	デバッグ用に保持します
notion-implementation-tracking	Notion 同期プロトコル	タスク完了時に更新します
admin-features	管理者のワークフロー、モデレーション、ユーザー管理	機能仕様のみ
recipe-features	レシピの CRUD、検索、レビュー、エンゲージメント	機能仕様のみ
auth-context	セッションベースの認証フロー	フェーズ 4 のバックエンド、フェーズ 5 の統合
routing-layouts	ルート設定とページレイアウト	レイアウトガード付き HashRouter
storage-data-model	フェーズ 5 前の localStorage 構造	API に置き換える予定です
ui-components-and-styling	コンポーネントライブラリと Tailwind v4	再利用可能なコンポーネント

セッション開始時の手順（フェーズ 4 — バックエンド未着手）：

1. get_current_config → プロジェクトが有効化されていることを確認します
2. 有効化されていない場合は、現在のワークスペースパスを指定して activate_project を実行します
3. check_onboarding_performed → オンボーディングの状態を確認します
4. 必要に応じて、標準のワークフローを使用してオンボーディングを完了します
5. list_memories → 利用可能なメモリーが 10 件あることを確認します
6. project-overview を読みます → 現在の状況（38% 完了、フェーズ 1～3 は完了）
7. database-integration-implementation-plan-task を読みます → フェーズ 4 のタスク（TASK-057～TASK-092）
8. PHP バックエンドの開発を開始します：backend/config/database.php、backend/helpers/、続いて backend/api/

プロジェクト固有のベストプラクティス：

データベースの規約：

• データベース：cookhub（utf8mb4_unicode_ci）
• テーブル：単数形（user、recipe、ingredient など）
• カラム：snake_case、主キーは id
• 主キーへのアクセス：親テーブルでは WHERE id = ?、子テーブルでは外部キーを参照します
• 外部キー：{table}_id カラム

アーキテクチャ：

• プレーンな PHP（フレームワークなし、Composer なし）
• 構成：backend/{config, helpers, api}/
• 各 API ファイルで $_SERVER['REQUEST_METHOD'] を使用してルーティングを処理します
• 認証：セッションベース（HttpOnly Cookie、session テーブル）
• HTTP：ネイティブの fetch() と credentials: 'include'

ドキュメントの更新フロー：

• SQL の修正 → {topic}-fixes-{date}.md が存在するか確認 → 更新するか、新しいメモリーを作成します
• 主要なマイルストーン → 新しいタイムスタンプを付けて project-overview.md を更新します
• フェーズ完了 → 進捗を記載して database-integration-implementation-plan-task.md を更新します
• Notion 同期 → 同期状況を記載して notion-implementation-tracking.md を更新します
• すべての更新 → 次の形式で現在のタイムスタンプを含めます："Updated: YYYY-MM-DD HH:MM"

使用する命名パターン：

• 機能メモリー：小文字の kebab-case（admin-features、recipe-features、auth-context）
• 修正メモリー：{name}-fixes-{date}.md
• 状況メモリー：{project}-updates.md または {plan}-task.md

---

メモリー参照表（CSX3006 プロジェクト）

カテゴリー	メモリー名	更新頻度	読むタイミング
状況と計画	project-overview	フェーズ完了後、アーキテクチャの決定後	セッション開始時は必ず最初に読みます
タスク追跡	database-integration-implementation-plan-task	フェーズ完了後	バックエンド／フロントエンド作業を開始するとき
SQL の修正	csx3006-sql-fixes-2026-02-13.md	データベースの問題を修正するとき	SQL／データベース作業中
Notion 同期	notion-implementation-tracking	Notion 同期パターンが変更されたとき	Notion ページを更新する前
機能仕様	admin-features、recipe-features、auth-context	機能の変更・改善時	関連機能を実装するとき
参照情報	routing-layouts、storage-data-model、ui-components-and-styling	変更はまれ	これらのトピックをすぐに確認するとき

スクリプト

• メモリバックアップ — Serena のメモリファイルをタイムスタンプ付きでバックアップする PowerShell スクリプト

例

• リファクタリングのワークフロー — Serena のツールを使った 13 ステップのリファクタリング手順

---

このプロジェクトのメモリ管理戦略

メモリが 15 個ではなく 10 個である理由（Memory Bank 標準との比較）：

• タスクのメモリではなく、plan/upgrade-database-integration-1.md（138 件のタスク）を使ってプロジェクトの実装計画を管理しています
• 個別の task-{id} メモリは不要です（タスクは計画ファイルに記載されています）
• task-index や progress メモリはありません（ステータスは project-overview.md に記載されています）
• 機能仕様は簡潔にまとめています（admin-features、recipe-features、auth-context はそれぞれ約 500 バイトです）
• すばやく参照できるよう、1 行の参照用メモリを使用しています（routing-layouts、storage-data-model、ui-components-and-styling）

新しいメモリを作成するタイミング：

• SQL／スクリプトの修正：{topic}-fixes-{date}.md（例：csx3006-sql-fixes-2026-02-13.md）
• 機能ドキュメント：{feature-name}.md（例：admin-features.md）
• 主要なマイルストーン：project-overview.md を更新します（ステータスの変更、アーキテクチャ上の判断）

メモリを作成しないタイミング：

• 個別のタスク（upgrade-database-integration-1.md のタスクリストを使用します）
• 日々の進捗（プロジェクトのステータスは project-overview.md で管理します）
• コードサンプル（コードはメモリではなく実際のファイルにあります）
• 一度限りの過去の出来事（不要になったら削除します）
• 新しく作成するのではなく、既存のメモリを更新すべき情報

---

メモリの更新と作成のクイックリファレンス

判断ツリー

Need to store information?
│
├─ Check: `list_memories`
│  │
│  ├─ Existing memory covers this topic?
│  │  │
│  │  ├─ YES → Use `edit_memory` with new info + updated timestamp
│  │  │
│  │  └─ NO → Use `write_memory` to create new memory
│  │
│  └─ Proceed with work

よくある照合パターン

情報を追加する対象...	確認するメモリ...	存在する場合...	存在しない場合...
管理者機能／モデレーション	admin-features	更新します	admin-features を作成します
レシピの CRUD／検索	recipe-features	更新します	recipe-features を作成します
認証／セッション	auth-context	更新します	auth-context を作成します
今日の SQL 修正	{topic}-fixes-{date}	更新します	今日の日付を付けて新規作成します
アーキテクチャ上の判断	system-patterns	更新します	system-patterns を作成します
プロジェクト全体のステータス	project-overview	必ず更新します	project-overview を作成します
コンポーネント仕様	ui-components-and-styling	更新します	トピックが異なる場合は作成します

メモリの編集パターン

# Always use this format when updating existing memories
edit_memory(
  memory_file_name="existing-memory-name",
  needle="section or content to replace or append after",
  repl="new information with timestamp:\n\n## [Section] — Updated YYYY-MM-DD HH:MM\n\n- [new info]",
  mode="literal" # or "regex" as appropriate
)

---

関連スキル

• development-workflow：ワークフローに計画、品質ゲート、デリバリーの追跡も必要な場合に使用します。
• documentation-quality：ワークフローにドキュメントレビューの基準と品質ゲートも必要な場合に使用します。
• verification-before-completion：完了を主張する前の最終的な証拠確認もワークフローに必要な場合に使用します。
• code-quality：仕様への準拠を先に確認し、その後にコード品質を確認する二段階レビュー、保守性、リファクタリングのガイダンスもワークフローに必要な場合に使用します。