miniproject

Markdown を活用したタスク管理

これは、簡素で簡潔なプロジェクト管理 AI メモリーフレームワークです。

メモ

重要 作業を始める前に、必ず次の手順を実施してください。

1. ヘルパースクリプトを使ってメモリーストアを見つけます。

   MEMORY_DIR=$(/home/zenobius/.pi/agent/skills/projectmanagement/miniproject/scripts/miniproject.sh memory-dir)
   

   • git worktree を自動的に処理します（メインの worktree 内の .memory/ を見つけます）
   • ディレクトリが存在しない場合は、--create フラグを使って作成します
2. 次のファイルが .memory/ に存在することを確認します。

• .memory/todo.md、.memory/summary.md、.memory/knowledge.md、.memory/team.md を読みます（glob や list ツールではなく、grep/ls を使います）
• .memory/ にこれらのファイルがない場合は、その3つを作成します。

3. 存在しない場合は、ナレッジのコードマップを初期化します。

• コードベースについての理解を表す ASCII の状態遷移図を含む .memory/knowledge-codemap.md ファイルを作成します。
• これはプロジェクトの構造と流れを理解するうえで非常に重要です。

4. 作業を始める前に、必ず .memory/summary.md、.memory/todo.md、.memory/team.md を読みます。
5. 作業中のエピックとフェーズ、および担当者を示すため、必ず .memory/team.md を更新します（エージェント名ではなく、セッション ID を記載します）。
6. .memory/todo.md は、各ステップで常に最新の状態に保ちます。
7. タスクまたはフェーズを完了したら、必ず変更をコミットします。人間によるレビューなしに変更をプッシュしてはいけません。
8. ファイル名の規則を厳守してください。

ルール 0：メモリーストア

.memory/ ディレクトリは非常に重要です。すべてのプロジェクト管理ファイルとナレッジファイルをここに保存する必要があります。

ルール 0.1：メモリーストアの場所を特定する

ヘルパースクリプトを使って、メモリーディレクトリを見つけます。

# Find the .memory directory (fails if not found)
MEMORY_DIR=$(/home/zenobius/.pi/agent/skills/projectmanagement/miniproject/scripts/miniproject.sh memory-dir)

# Find or create the .memory directory
MEMORY_DIR=$(/home/zenobius/.pi/agent/skills/projectmanagement/miniproject/scripts/miniproject.sh memory-dir)

スクリプトは次の処理を行います。

• Git worktree（worktree のチェックアウト先ではなく、メインの worktree 内の .memory/ を見つけます）
• 通常の git リポジトリ
• .memory/ の絶対パスを返します

警告

.memory/ は gitignore の対象になっている場合があるため、通常のファイル一覧表示ツール（Glob、List、ripgrep）では期待どおりに動作しないことがあります。

ルール 0.2：メモリーストアの保存

.memory/ 内のファイルを編集または作成するときは、必ず次の手順を実施します。

1. メモリーストアを作業ディレクトリとして、git を使って変更をコミットします。

ルール 1：ファイル名の規則

以下に示す規則に厳密に従うファイル名のみを作成してください。

規則に従っていないファイルはすべて無効であり、その目的を確認したうえで、次のいずれかを行う必要があります。

1. 目的が単一で、規則に適合する場合は名前を変更する、または
2. 規則に適合する複数のファイルに分割する、または
3. 他のファイルで内容が網羅されている場合は削除する。

不要なファイルや不適切な名前のファイルを残しておくと、混乱を招き、メモリーシステムの品質を低下させます。

ガイドライン

• [core] 調査結果は .memory/ ディレクトリに保存します
• [core] .memory/ 内のすべてのメモは Markdown 形式にします
• [core] アーカイブ済みのストーリー、タスク、エピックは archive ディレクトリ .memory/archive/ に移動します。
• [core] summary.md、todo.md、team.md、knowledge-*.md は、プロジェクトの概要、未完了のタスク、チームの役割をそれぞれ示す特別なファイルです。
• [core] .memory/knowledge-codemap.md には、コードベースを状態機械として理解した内容を表す ASCII 図を記載します。
• [core] .memory/knowledge-data-flow.md には、データフローを表す ASCII 図を記載します
• [core] 特定の知識領域を記録するために、ほかの .memory/knowledge-*.md ファイルを作成できます。
• [core] .memory/summary.md を除き、.memory/ 内のすべてのメモはファイル名規則 .memory/<type>-<8_char_hashid>-<title>.md に従う必要があります
• [core] <type> は research、epic、task、story、learning のいずれかです
• [core] <8_char_hashid> は、ファイルごとに一意な8文字のハッシュ識別子です。
• [core] 初期化時には、既存のコードベースのコードマップを作成し、コードベースを理解した内容を表す状態機械の ASCII 図を .memory/knowledge-codemap.md に記載します。
• [core] すべてのプロジェクトでは、ストーリーやタスクを作成する前に、必ずエピックの定義から開始する必要があります
• [core] .memory/summary.md は、現在のエピック、進行中のフェーズ、次のマイルストーンを反映して常に最新の状態に保ちます。不正確または古くなった情報は削除します。
• [git] タスクまたはフェーズの完了後は、必ず変更をコミットします。
• [git] 人間によるレビューなしに変更をプッシュしてはなりません。
• [git] 変更をコミットする際は、Conventional Commits の規約に従います。
• [git] 変更に関連するファイルを明記した、わかりやすいコミットメッセージを使用します。

概念モデル：ストーリー、フェーズ、タスク

これらの成果物の関係を理解することは重要です。

Epic (vision/goal)
 ├── Stories (WHAT - phase-agnostic requirements)
 │    └── Stories define what users need, independent of timeline
 │
 └── Phases (WHEN - inline sections in epic file)
      └── Phases define when work happens
           └── Tasks link to BOTH:
                ├── story_id → the requirement being implemented (WHAT)
                └── phase_id → the timeline slot (WHEN)

成果物	関心事	関連先	フェーズに依存しないか
エピック	ビジョン	-	はい
ストーリー	WHAT	エピック	はい
フェーズ	WHEN	エピック（インライン）	いいえ
タスク	HOW + WHEN	ストーリー + フェーズ	いいえ
調査	発見	エピック／タスク	はい
学習	知識	-	はい

重要なポイント： ストーリーは、いつ実装されるかとは独立して存在する要件です。フェーズはストーリー（要件）ではなく、タスク（予定された作業）をグループ化します。タスクは、ストーリー（実装する内容）とフェーズ（予定されている時期）の両方に関連付けることで、この2つをつなぎます。

アーカイブ

• [archive] 完了したタスクとストーリーは、ファイルを .memory/archive/ ディレクトリに移動してアーカイブします。
• [archive] 学習ファイルや調査ファイルはアーカイブしてはなりません。これらは今後のプロジェクトに役立つ貴重な知識です。
• [archive] すべてのフェーズが完了し、学びが抽出されるまでは、エピックファイルをアーカイブしてはなりません。アーカイブするエピックには、抽出した学びへのリンクが必要です。
• [archive] 完了したフェーズとエピックを .memory/summary.md に反映します。
• [archive] フェーズはエピックファイル内にインラインで記載されるため、エピックとともにアーカイブされます。

メモリの検索 [重要]

.memory/ が gitignore の対象になっている場合、通常の List ツールと Glob ツールは期待どおりに動作しないことがあります。gitignore のルールを回避するには、--no-ignore を付けて ripgrep を使用します。

# First, get the memory directory path
MEMORY_DIR=$(/home/zenobius/.pi/agent/skills/projectmanagement/miniproject/scripts/miniproject.sh memory-dir)

# Search for terms (--no-ignore bypasses .gitignore)
rg --no-ignore "<search-term>" "$MEMORY_DIR/"

# Find outstanding tasks
rg --no-ignore "TODO" "$MEMORY_DIR/todo.md"

# List all memory files
ls -al "$MEMORY_DIR/"

ヒント

rg -u は rg --no-ignore の省略形です。隠しファイルも検索するには rg -uu を使用します。

テンプレート

一貫性とアクセスのしやすさを確保するため、.memory/ 内の各 Markdown ファイルには、種類に応じた特定のフロントマター項目を含める必要があります。

共通のフロントマター項目

• id：ファイルごとに一意な8文字のハッシュ識別子。
• title：内容を要約した簡潔なタイトル。
• created_at：ファイルの作成日時。
• updated_at：ファイルの最終更新日時。
• status：proposed、planning、todo、in-progress、completed、archived のいずれかを示します。

共通セクション

• # {Title}：ドキュメントのメインタイトル。

テンプレート：タスク

タスクは、スケジュールされたフェーズ内でストーリーを実装します。タスクは、ストーリー（「何を」）とフェーズ（「いつ」）の両方にリンクします。

フロントマター：

• 共通のフロントマターフィールドすべて。
• epic_id：親エピックの一意の識別子です。
• phase_id：このタスクがスケジュールされているフェーズ（「いつ」—必須）です。
• story_id：このタスクが実装するストーリー（「何を」—ストーリーが存在する場合は必須）です。
• assigned_to：タスクを担当するエージェントまたは人間のセッション ID です。

メモ

二重リンクモデル： タスクには、異なる目的で使用する親リンクが 2 つあります。

• story_id → このタスクが満たす要件（何を）にリンクします
• phase_id → このタスクがスケジュールされている時期（いつ）にリンクします

story_id のないタスクは、探索的またはインフラストラクチャ関連の作業です。phase_id のないタスクは、スケジュールされていません。

セクション：

• 共通セクションすべて。
• ## Objective：タスクの達成目標を明確に記述します。
• ## Related Story：このタスクが実装するストーリーへのリンク（該当する場合）。このタスクが満たすことに貢献する受け入れ基準を含める必要があります。
• ## Related Phase：このタスクがスケジュールされているフェーズへのリンク。フェーズ名とエピックのコンテキストを含めます。
• ## Steps：タスクを完了するための手順を詳しく列挙します。
• ## Unit Tests：このタスクで作成したユニットテストの概要です。各項目には、何をテストするのか、親ストーリーのどの受け入れ基準をサポートするのかを記載します。形式：- [test name/file]: [what it verifies] → supports AC#N of story [hash]。親ストーリーがないタスクの場合は、ユニットテストで独立して検証する内容を記載します。
• ## Expected Outcome：タスク完了時に期待される結果を記述します。
• ## Actual Outcome：タスク完了後の実際の結果を記述します。
• ## Lessons Learned：タスクの完了を通じて得た重要な学びや知見です。

テンプレート：エピック

フロントマター：

• 共通のフロントマターフィールドすべて。

セクション：

• 共通セクションすべて。
• ## Vision/Goal：エピック全体のビジョンと目標を明確に記述します。
• ## Success Criteria：エピックの成功を測定するための指標と基準です。
• ## Stories：このエピックの要件を定義するストーリーの一覧（ストーリーファイルへのリンク）です。ストーリーはフェーズに依存せず、何を構築する必要があるかを定義し、いつ構築するかは定義しません。
• ## Phases：フェーズをインラインで記述するセクションです（以下の形式を参照）。フェーズは、作業をいつ行うかを定義し、スケジュールされたタスクを含みます。
• ## Dependencies：エピックに影響する可能性のある依存関係です。

フェーズセクションの形式（エピック内にインラインで記述）

フェーズは個別のファイルではなく、エピックファイル内のインラインセクションとして定義します。

## Phases

### Phase 1: Foundation
- **Status**: completed
- **Start Criteria**: Epic approved
- **End Criteria**: Core data model implemented and tested
- **Tasks**:
  - [x] [task-abc12345-data-model](./task-abc12345-data-model.md)
  - [x] [task-def67890-basic-api](./task-def67890-basic-api.md)
- **Notes**: Completed ahead of schedule

### Phase 2: Core Features  
- **Status**: in-progress
- **Start Criteria**: Phase 1 complete
- **End Criteria**: All core user stories have passing tests
- **Tasks**:
  - [x] [task-ghi11111-auth-flow](./task-ghi11111-auth-flow.md)
  - [ ] [task-jkl22222-user-dashboard](./task-jkl22222-user-dashboard.md)
- **Notes**: Auth complete, dashboard in progress

### Phase 3: Polish & Launch
- **Status**: planned
- **Start Criteria**: Phase 2 complete
- **End Criteria**: Production deployment successful
- **Tasks**: (to be assigned during task breakdown)

テンプレート：ストーリー

ストーリーはユーザーの要件を記録します。ストーリーはフェーズに依存せず、実装時期とは無関係に、ユーザーが何を必要としているかを定義します。

フロントマター：

• すべての共通フロントマターフィールド。
• epic_id：親エピックの一意の識別子。
• priority：優先度（例：critical、high、medium、low）。
• story_points：見積もり工数／複雑度（任意。例：1、2、3、5、8、13）。
• test_coverage：すべての受け入れ基準に、対応する成功したテストが紐付いているかどうか。値は none、partial、full のいずれかです。

メモ

ストーリーには phase_id はありません。ストーリーは要件であり、スケジュールされた作業ではありません。 タスクは、実装対象（何を実装するか）としてストーリーに、スケジュール（いつ実施するか）としてフェーズに紐付きます。

セクション：

• すべての共通セクション。
• ## User Story：次の形式で記述するユーザーストーリー：「[ペルソナ]として、[目標]を実現したい。それによって[メリット]を得るためです。」
• ## Acceptance Criteria：ストーリーを完了とみなすために満たす必要がある、具体的でテスト可能な条件のチェックリストです。未完了の基準には - [ ]、完了した基準には - [x] を使用します。
• ## Context：このストーリーが必要な理由についての背景情報とコンテキストです。
• ## Out of Scope：スコープの拡大を防ぐため、このストーリーに含まれない内容を明示的に列挙します。
• ## Tasks：このストーリーを実装するタスクファイルへのリンクです（タスクの分解時に記入）。各タスクには、スケジュール設定のためのフェーズも記載します。
• ## Test Specification：各受け入れ基準とその検証方法を対応付けます。次の2つのサブセクションを含みます。
  • ### E2E Tests：各受け入れ基準と、対応する E2E テストケースを対応付ける表です。1つのストーリーにつき、E2E テストスイート／ファイルは1つです。各受け入れ基準は、そのスイート内の1つのテストケースに対応します。形式：| AC# | Criterion | Test file/case | Status |
  • ### Unit Test Coverage (via Tasks)：このストーリーから作成されたタスクの一覧です。各タスクの単体テストで何を検証するか、また、それがストーリーの受け入れ基準の達成にどう貢献するかを要約します。形式：- Task [hash]: [unit test summary] → satisfies AC#N
• ## Notes：追加の注記、エッジケース、検討事項です。

メモ

ストーリーは、ビジネス要件と技術タスクをつなぐ橋渡しです。

• ストーリーには、ユーザーの視点から見た「何を」「なぜ」を記載します。
• タスクには、実装の視点から見た「どのように」を記載します。
• 1つのストーリーから、異なるフェーズにまたがる複数のタスクが作成される場合があります。
• タスクを作成する前に、受け入れ基準を記述してください。

メモ

ストーリーはテストの主要な対象です。

• E2E テストはストーリーを検証します。 各ストーリーから、E2E テストスイートが1つ作成されます。各受け入れ基準は、そのスイート内の1つのテストケースになります。対応関係は、1ストーリー：1テストスイート、N個の受け入れ基準：N個のテストケースです。
• 単体テストはタスクを検証します。 単体テストの対象はストーリー（要件）ではなく、タスク（実装）です。単体テストは、親タスクを通じてストーリーに紐付きます：story.acceptance_criteria → task.objective → task.unit_tests。
• test_coverage が full でない限り、ストーリーを completed にすることはできません。full とは、すべての受け入れ基準に、対応する成功したテストが紐付いている状態です。

テンプレート：リサーチ

フロントマター：

• すべての共通フロントマターフィールド。
• epic_id：親エピックの一意の識別子。
• related_task_id：このリサーチのきっかけとなったタスクの一意の識別子。[任意]

セクション：

• すべての共通セクション。
• ## Research Questions：リサーチで回答を目指す具体的な質問の一覧です。
• ## Summary：リサーチ結果の簡潔な概要です。
• ## Findings：リサーチ結果の詳細です。
• ## References：リサーチで使用した情報源や参考資料の一覧です。

テンプレート：学び

フロントマター：

• すべての共通フロントマターフィールド。
• tags：学びを分類するタグの一覧です（例：best-practices、lessons-learned、technical-insights）。

セクション：

• すべての共通セクション。
• ## Summary：学びの簡潔な概要です。
• ## Details：学びの詳細な説明です。
• ## Implications：今後のプロジェクトでこの学びをどのように活用できるかを記載します。

テンプレート：Constitution

フロントマター：

• すべての共通フロントマターフィールド。

セクション：

• すべての共通セクション。
• ## Project Rules：プロジェクトの管理と実行を規定するルールのリスト。
• ### {Concept}：各コンセプトの説明とガイドライン。

テンプレート：Knowledge

フロントマター：

• すべての共通フロントマターフィールド。
• area：文書化する特定のナレッジ領域（例：codebase-structure、data-flow、design-patterns）。
• tags：ナレッジを分類するタグのリスト（例：architecture、best-practices、technical-insights）。
• learned_from：このナレッジにつながったエピック、フェーズ、タスク、または外部ソースへの参照。

セクション：

• すべての共通セクション。
• ## Overview：ナレッジ領域の概要。
• ## Details：ナレッジの詳細な説明。

テンプレート：Knowledge Codemap

メモ

正確さを保ち、最新の状態にしてください。コードベースの構造とフローを理解するうえで非常に重要です。 これを適切に行えば、ユーザーに大変喜ばれるでしょう。 適切に行うことで報酬が得られます。

これは Knowledge テンプレートと同じですが、コードベースのコードマップ専用です。

その詳細は、コードベースを状態機械として捉えた理解を表す ASCII 図のみで構成されます。

運用手順

プロジェクト憲章 ワークフロー

0. Initialise > Action > 停止
1. Idea > Epic Definition > Research > Story Definition（テスト仕様を含む）> Phase Planning > 人間によるレビュー > Task Breakdown > 停止
2. Task Execution（ユニットテストを含む）> Learning Distillation > 繰り返し
3. Story Completion > 受け入れ基準とテストカバレッジのゲートを検証 > Phase Completion > Learnings Distillation > 人間によるレビュー > 停止
4. Epic Completion > Epic Summary & Learnings > 人間によるレビュー > 停止
5. 必要に応じて Maintenance Actions。
6. Status > 停止

以下に、プロジェクトのライフサイクルにおける各段階の詳細な手順を示します。

ユーザーが miniproject <action> を要求した場合、<action>（または <ACTION>、<Action>）を以下の該当する [ACTION] に対応付け、ルールとガイドラインを厳守してください。

初期化アクション [INITIALISE]

• [core] メモリディレクトリを見つけるか、作成します。

  MEMORY_DIR=$(/home/zenobius/.pi/agent/skills/projectmanagement/miniproject/scripts/miniproject.sh memory-dir)
  

• [core] $MEMORY_DIR/ に以下のファイルが存在することを確認します。
  • todo.md（タスクの追跡用）
  • summary.md（プロジェクトの概要用）
  • team.md（チームの役割と担当用）
  • knowledge-codemap.md（コードベースの理解用）
  • knowledge-data-flow.md（コードベースのデータフローを状態機械として表した ASCII 図。）
• [core] これらのファイルが存在しない場合は、適切な見出しと初期内容を記載して作成します。
• [core] プロジェクトのルールとガイドラインをまとめる constitution.md ファイルを定義するか、ユーザーに確認します。定義する場合は、テンプレート構造でファイルを作成します。

メンテナンスアクション

.memory/ ディレクトリにはメンテナンスが必要になることがあります。必要に応じて以下のアクションを使用してください。

アクション：メモリの要約 [SUMMARIZE-MEMORY]

• [core] すべての .memory/ ファイルを読み、現在のエピック、進行中のフェーズ、次のマイルストーンを反映するよう .memory/summary.md を更新します。誤った情報や古くなった情報は削除します。
• [core] .memory/summary.md が簡潔で、ひと目で理解しやすい内容であることを確認します。

アクション：クリーンアップ [CLEAN-UP]

• [tasks] 完了したタスクを .memory/archive/ ディレクトリに移動します。
• [learning] 重要な学びがすべて .memory/learning-<8_char_hash_id>-<title>.md ファイルに記録されていることを確認します。
• [stories] 完了したストーリーのすべてのタスクをアーカイブした後、そのストーリーを .memory/archive/ ディレクトリに移動します。

アクション：メモリの検証 [VALIDATE-MEMORY]

• [core] 検証スクリプトを実行し、すべてのメモリファイルがフロントマターのルールに準拠していることを確認します：./scripts/validate.ts

アクション：憲章の改訂 [REFINE-CONSTITUTION]

• [core] ユーザーの入力に基づいて、.memory/constitution.md を確認し、更新します。
• [core] 憲章に変更があった場合は、チームメンバー全員に確実に周知します。
• [core] 人間から依頼されない限り、.memory/constitution.md を更新してはいけません。
• [core] 更新する場合は、memory/constitution をスコープとして、明確なコミットメッセージを付けて変更を個別にコミットします。

ステータスアクション [STATUS]

• [core] .memory/summary.md に基づいて、現在のエピック、進行中のフェーズ、次のマイルストーンの概要を提示します。
• [core] .memory/todo.md に記載された未完了タスクを一覧表示します。
• [core] タスクの作業がステートマシンのどの部分に関連するかを示す ASCII 図で、ステータスに文脈を与えます。

計画ステージ

ステージ：アイデア創出 [IDEA]

• [core] すべてのプロジェクトは、ストーリーやタスクを作成する前に、必ずエピックの定義から始めます。
• [core] 初期化時に既存のコードベースのコードマップを作成し、コードベースに対する理解を表すステートマシンの ASCII 図を .memory/knowledge-codemap.md に記載します。
• [epic] アイデアが提示されたら、ユーザーと Q&A セッションを行い、アイデアを具体化して追求する価値があるかを判断します。追求する価値がある場合は、ただちにエピック定義ステージに進みます。そうでない場合は、今後の参考として、アイデアと却下した理由を .memory/learning-<8_char_hash_id>-<title>.md ファイルに記録します。

ステージ：エピック定義 [EPIC]

• [epic] すべてのプロジェクトは、全体的な目標とスコープを定めるエピックから必ず開始します。
• [epic] 各エピックは .memory/epic-<8_char_hash_id>-<title>.md ファイルに記録します。
• [epic] エピックには、ビジョン／目標、成功基準、ストーリーの一覧、フェーズ（インライン）、全体のタイムライン、依存関係を含める必要があります。
• [epic] フェーズはエピックファイル内のインラインセクションとし、別ファイルにはしません。
• [epic] 人間が明示的に承認しない限り、同時にアクティブにできるエピックは 1 つだけです。
• [epic] すべてのフェーズが完了し、学びが整理されるまで、エピックファイルをアーカイブしてはいけません。

ステージ：調査 [RESEARCH]

• [research] 調査を始める前に、.memory/summary.md と .memory/**/learning**.md を読み、これまでに判明していることを把握します。調査を重複させてはいけません。
• [research] 既存の調査結果が見つかった場合は、それを必要とするドキュメントからリンクし、コピーや重複を避けます。
• [research] 調査を、具体的で回答可能な質問に分解します。
• [research] 外部検索を行う前に、.memory/ 内のアーカイブ済みメモリファイルを調べ、関連情報が見つかった場合は、重複させずにその情報へリンクします。
• [research] use_skill(brave_search) の search および content 抽出スクリプトを使って情報を収集します。失敗した場合は、lynx CLI を使って手動で検索し、内容を抽出します。
• [research] 情報源の信頼性、関連性、偏りを批判的に評価します。評価理由と 10 点満点のスコアを記載した脚注に、情報源をリンクします。
• [research] 調査結果を .memory/research-<8_char_hash_id>-<title>.md ファイルに明確かつ簡潔に記録します。冒頭に概要を置き、その下に詳細な調査結果を記し、末尾に参考資料を記載します。
• [research] ユーザー主導の発見・計画 Q&A を行う際は、質問、提示した選択肢すべて、ユーザーの回答の原文を含め、セッション全体を調査成果物に逐語的に記録します。要約は補足として記載できますが、逐語的な Q&A の代わりにしてはいけません。
• [research] 調査タスクは常に「Deep Researcher SubAgent」に委任します。利用可能なサブエージェント、サブスレッド、または委任ツールを使ってください。
• [research] サブエージェントの場合は、割り当てられたタスクだけに集中してください。逸脱したり、さらに委任したりしてはいけません。

ステージ：ストーリーの定義 [STORY-DEFINITION]

• [story] ストーリーには、実装を開始する前に、明確な受け入れ条件とともにユーザー要件を記述します
• [story] 各ストーリーは、.memory/story-<8_char_hash_id>-<title>.md ファイルに記録してください
• [story] ストーリーには、ユーザーストーリーの記述、受け入れ条件、コンテキストを必ず含めてください
• [story] ストーリーがリンクするのは親エピックのみです。ストーリーはフェーズに依存しない要件です
• [story] ストーリーに phase_id はありません。定義するのは「何を」であり、「いつ」ではありません
• [story] 受け入れ条件は、具体的でテスト可能なチェックリスト形式にしてください
• [story] 受け入れ条件を記述した後、## Test Specification セクションに以下を記入します：
  • このストーリーの E2E テストスイート名／ファイルを定義する
  • 各受け入れ条件を、名前付きの E2E テストケースに対応付ける
  • frontmatter に test_coverage: none を設定する（テストの作成に合わせて更新）
• [story] タスクを作成する前にストーリーを作成します。タスクはストーリーを実装します
• [story] 1 つのストーリーから、異なるフェーズにわたって計画される複数のタスクが生じる場合があります
• [story] すべての受け入れ条件が満たされ、検証されたら、ストーリーを completed にします
• [story] ストーリーを使うことで、「ユーザーが必要としていること」と「それをいつ、どのように実装するか」を分けて管理できます

メモ

ストーリーとフェーズとタスクの違い：

• ストーリー：「ユーザーとして、アカウントに再びアクセスできるよう、パスワードをリセットしたいです。」（フェーズに依存しない要件）
  • 受け入れ条件：「ユーザーが 2 分以内にメールを受け取る」「リンクは 24 時間後に期限切れになる」など
• フェーズ：「フェーズ 2：ユーザー認証」— エピック内の、期間が定められた作業のまとまり
• タスク：「パスワードリセット用 API エンドポイントを実装する」（ストーリーとフェーズにリンク）、「メールテンプレートを作成する」（ストーリーとフェーズにリンク）など
• E2E テスト（ストーリーを検証）：password-reset.e2e.spec → 各受け入れ条件に対してテストケースを用意
• ユニットテスト（タスクを検証）：エンドポイントの入力検証、テンプレートのレンダリング、トークンの有効期限ロジックなど

ステージ：フェーズの計画 [PHASE-PLANNING]

• [phase] フェーズはエピックファイル内のインラインセクションであり、個別のファイルではありません
• [phase] 各フェーズには、ステータス、開始条件、終了条件、タスクリストを含めてください
• [phase] フェーズでは、ストーリー（要件）ではなくタスク（計画された作業）をまとめます
• [phase] フェーズには、エピックの目標に沿った明確な開始条件と終了条件を設定してください
• [phase] フェーズをストーリーの一覧として扱わないでください。フェーズにはストーリーを実装するタスクを含めます
• [phase] 新しいフェーズを追加するには、エピックの ## Phases セクションを更新してください

メモ

検証手順：

• フェーズを計画したら、タスクの分解に進む前に必ず人間に確認してください。
• フェーズ計画に人間のレビューが必要であることを示す大きな ASCII ボックスをチャットに表示してください。
• 人間の確認が得られるまで、先に進まないでください。

ステージ：タスクの分解 [TASK-BREAKDOWN]

• [tasks] 各タスクは、目標、実施手順、期待される成果を含めて、.memory/task-<8_char_hash_id>-<title>.md ファイルに記録してください。
• [tasks] タスクには、以下の 2 つのリンクを必ず設定してください：
  • story_id：このタスクが実装するストーリー（「何を」）
  • phase_id：このタスクが予定されているフェーズ（「いつ」）
• [tasks] ストーリーにリンクしていないタスクは、インフラ作業または探索作業です。目標を明確に記録してください
• [tasks] フェーズにリンクしていないタスクは、未スケジュールです。実行前にフェーズを割り当ててください
• [tasks] タスクは、具体的で、測定可能で、達成可能で、関連性があり、期限が定められている（SMART）ものにしてください。
• [tasks] 影響度と緊急度に基づいてタスクに優先順位を付けてください。
• [tasks] タスクを作成したら、エピックファイル内の適切なフェーズセクションにも追加してください。
• [tasks] 残りのタスクを追跡するには .memory/todo.md を使用してください。このファイルには .memory/task-<8_char_hash_id>-<title>.md ファイルへのリンクのみを記載します。[CRITICAL] 各ステップで .memory/todo.md を最新の状態に保ってください。

実行ステージ

ステージ：タスク実行 [TASK-EXECUTION]

• [tasks] タスクファイルのチェックリストと進捗は常に更新してください。[CRITICAL] 各ステップで .memory/todo.md を最新の状態に保ってください。
• [tasks] タスクを完了したら、成果と学んだことを該当する .memory/task-<8_char_hash_id>-<title>.md ファイルに記録してください。
• [tasks] 親フェーズのエピックファイル内にあるタスクのチェックボックスを更新してください。
• [core] 現在のエピック、アクティブなフェーズ、次のマイルストーンが反映されるよう、.memory/summary.md を常に最新の状態に保ってください。誤った情報や古い情報は削除してください。

ステージ：学びの抽出 [LEARNING-DISTILLATION]

• [learning] 重要な知見、学んだこと、ベストプラクティスは、今後参照できるよう .memory/learning-<8_char_hash_id>-<title>.md ファイルに記録してください。
• [learning] 学習ファイルはアーカイブも削除もしないでください。[CRITICAL] 学習ファイルは常に保持してください。

完了ステージ

ステージ：ストーリー完了 [STORY-COMPLETION]

• [story] ストーリーを完了としてマークする前に、すべての受け入れ基準が満たされていることを確認してください。
• [story] 各受け入れ基準を確認したら、そのチェックボックスを更新してください（- [ ] から - [x]）。
• [story] 受け入れ基準を満たせない場合は、その理由をストーリーの「Notes」セクションに記録してください。
• [story] 完了したタスクを、## Tasks セクションでストーリーにリンクしてください。
• [story] テスト検証ゲート：ストーリーを completed としてマークする前に、次の項目を確認してください。
  • ## Test Specification > ### E2E Tests の各受け入れ基準に、リンクされた合格済みテストケースがある
  • ## Test Specification > ### Unit Test Coverage に記載された各タスクで、各タスクの ## Unit Tests セクションにユニットテストが記録されている
  • test_coverage のフロントマターを更新する：none → partial（一部のテストがリンク済み）→ full（すべての基準がカバーされ、テストに合格）
  • test_coverage が none または partial の間は、ストーリーを completed としてマークできません。
• [story] すべての基準が確認され、test_coverage が full になったら、ストーリーのステータスを completed に更新してください。
• [story] リンクされたすべてのタスクがアーカイブされるまで、ストーリーをアーカイブしないでください。要件とその達成状況を示すドキュメントとして保持してください。

ステージ：フェーズ完了 [PHASE-COMPLETION]

• [phase] フェーズを完了したら、エピックファイル内のフェーズステータスを completed に更新してください。
• [phase] フェーズ内のすべてのタスクが完了としてマークされていること（チェックボックスが [x] であること）を確認してください。
• [phase] 学んだことを学習ファイルに記録してください。
• [phase] フェーズを完了したら、調査とタスクから得られた関連する学びと成果をまとめて、.memory/learning-<8_char_hash_id>-<title>.md ファイルに記録してください。.memory/summary.md と ./memory/todo.md を整理してください。
• [phase] 完了したタスクは、ファイルを .memory/archive/ ディレクトリに移動してアーカイブしてください。

メモ

検証手順：

• フェーズの完了後、次のフェーズを開始する前に人間によるレビューを受けてください。
• フェーズ完了の人間によるレビューが必要であることを示す大きな ASCII ボックスをチャットに表示してください。
• 人間の確認を待ってから作業を続けてください。

ステージ：エピック完了 [EPIC-COMPLETION]

• [epic] すべてのフェーズが完了し、学びが抽出されるまで、エピックファイルをアーカイブしないでください。
• [archive] すべてのフェーズが完了し、学びが抽出されるまで、エピックファイルをアーカイブしないでください。アーカイブする前に、エピックに抽出した学びへのリンクを含めてください。
• [archive] 完了したフェーズとエピックが反映されるよう、.memory/summary.md を更新してください。
• [archive] 学習ファイルや調査ファイルはアーカイブしないでください。これらは今後のプロジェクトに役立つ貴重な知識です。

メモ

検証手順：

• エピックの完了後、アーカイブする前に必ず人間によるレビューを受けてください。
• エピック完了の人間によるレビューが必要であることを示す大きな ASCII ボックスをチャットに表示してください。
• 人間の確認を待ってから作業を続けてください。

一般的な作業手順

1. ［重大］エピックが存在しない場合は、ほかの作業に着手する前に作成します。 ビジョン、成功基準、ストーリー、計画しているフェーズを（インラインで）定義します。
2. .memory/team.md を更新し、どのエピックとフェーズに誰が取り組んでいるかを示します（エージェント名ではなく、セッション ID を使用します）。
3. .memory/todo.md に [NEEDS-HUMAN] タスクがある場合は、作業を中断して人間の対応を待ちます。
4. 上記のリサーチガイドラインに従います。
5. 人間の介入が必要な作業によって行き詰まった場合は、人間が行う必要のある作業を .memory/todo.md にタスクとして記載します。タスクの行に [NEEDS-HUMAN] を付けます。
6. フェーズの完了後、.memory/summary.md を更新し、必要に応じてほかのファイルを整理します。
7. エピックの完了後、得られたすべての知見を整理し、.memory/summary.md を更新して、完了したタスクやストーリーをアーカイブします。
8. 関連ファイルに言及した、わかりやすいメッセージを添えて変更をコミットします。

人間とのやり取り

• 確認や追加情報が必要な場合は、人間に支援を依頼してください。
• 人間の介入が必要であることを示す大きな ASCII の枠をチャットに表示し、.memory/todo.md にあるタスクをその枠内に列挙してください。
• 人間がタスクを完了するまで待ってから、作業を続行してください。