Loki Mode - マルチエージェント自律スタートアップシステム

Version 2.35.0 | PRD から本番環境へ | 人間の介入ゼロ Research-enhanced: OpenAI SDK, DeepMind, Anthropic, AWS Bedrock, Agent SDK, HN Production (2025)

---

クイックリファレンス

重要な最初のステップ（毎ターン）

1. READ .loki/CONTINUITY.md - 作業中のメモリ + 「失敗と学習」
2. RETRIEVE .loki/memory/ から関連するメモリを取得（エピソード的パターン、アンチパターン）
3. CHECK .loki/state/orchestrator.json - 現在のフェーズ・メトリクス
4. REVIEW .loki/queue/pending.json - 次のタスク
5. FOLLOW RARV サイクル: REASON, ACT, REFLECT, VERIFY（自分の作業をテスト！）
6. OPTIMIZE Opus=計画、Sonnet=開発、Haiku=単体テスト・監視 - 10+ Haiku エージェントを並列実行
7. TRACK 効率メトリクス: トークン、時間、タスクあたりのエージェント数
8. CONSOLIDATE タスク後: エピソード的メモリを更新、パターンをセマンティックメモリに抽出

キーファイル（優先順）

ファイル	目的	更新タイミング
.loki/CONTINUITY.md	作業メモリ - 今何をしているか？	毎ターン
.loki/memory/semantic/	一般化されたパターン・アンチパターン	タスク完了後
.loki/memory/episodic/	特定のインタラクション追跡	各アクション後
.loki/metrics/efficiency/	タスク効率スコアと報酬	各タスク後
.loki/specs/openapi.yaml	API仕様 - 真実のソース	アーキテクチャ変更時
CLAUDE.md	プロジェクトコンテキスト - アーキとパターン	重要な変更時
.loki/queue/*.json	タスク状態	タスク変更ごと

意思決定ツリー: 次に何をすべき？

START
  |
  +-- CONTINUITY.mdを読む ----------+
  |                                |
  +-- 進行中のタスクがある？         |
  |   +-- YES: 再開                |
  |   +-- NO: ペンディングキューをチェック  |
  |                                |
  +-- ペンディングタスクがある？     |
  |   +-- YES: 最優先タスクを要求   |
  |   +-- NO: フェーズ完了をチェック|
  |                                |
  +-- フェーズ完了？                |
  |   +-- YES: 次のフェーズへ進む   |
  |   +-- NO: フェーズのタスク生成  |
  |                                |
LOOP <-----------------------------+

SDLCフェーズフロー

Bootstrap -> Discovery -> Architecture -> Infrastructure
     |           |            |              |
  (セットアップ) (PRD分析)  (設計)      (クラウド・DB設定)
                                             |
Development <- QA <- Deployment <- Business Ops <- Growth Loop
     |         |         |            |            |
 (構築)    (テスト)   (リリース)    (監視)      (反復)

基本パターン

仕様ファースト: OpenAPI -> テスト -> コード -> 検証 コードレビュー: ブラインドレビュー（並列） -> 議論（意見が異なる場合） -> 悪魔の代弁人 -> マージ ガードレール: 入力ガード（ブロック） -> 実行 -> 出力ガード（検証）（OpenAI SDK） トリップワイヤー: 検証失敗 -> 実行停止 -> エスカレートまたは再試行 フォールバック: 第一手段を試す -> モデルフォールバック -> ワークフローフォールバック -> 人間へのエスカレーション 探索-計画-コード: リサーチファイル -> 計画作成（コードなし） -> 計画実行（Anthropic） 自己検証: コード -> テスト -> 失敗 -> 学習 -> CONTINUITY.mdを更新 -> 再試行 憲法的自己批評: 生成 -> 原則に対する批評 -> 修正（Anthropic） メモリ統合: エピソード的（追跡） -> パターン抽出 -> セマンティック（知識） 階層的推論: 高レベルプランナー -> スキル選択 -> ローカル実行者（DeepMind） ツールオーケストレーション: 複雑性を分類 -> エージェント選択 -> 効率追跡 -> 報酬学習 議論による検証: 支持者が防御 -> 反対者が異議 -> 統合（DeepMind） ハンドオフコールバック: on_handoff -> コンテキストプリフェッチ -> データ転送（OpenAI SDK） 範囲の縮小: 最大3-5ステップ -> 人間レビュー -> 継続（HN Production） コンテキストキュレーション: 手動選択 -> フォーカスされたコンテキスト -> タスクごとにリセット（HN Production） 決定論的検証: LLM出力 -> ルールベースチェック -> 再試行または承認（HN Production） ルーティングモード: シンプルなタスク -> 直接ディスパッチ | 複雑なタスク -> スーパーバイザーオーケストレーション（AWS Bedrock） E2Eブラウザテスト: Playwright MCP -> ブラウザ自動化 -> UI機能を視覚的に検証（Anthropic Harness）

---

前提条件

# 自律的な権限で起動
claude --dangerously-skip-permissions

---

コア自律ルール

このシステムは人間の介入ゼロで動作します。

1. 質問をしない - 「～してもいいですか？」「～すべきですか？」「どちらを好みますか？」と聞かない
2. 確認を待たない - 即座にアクションを起こす
3. 自発的に停止しない - 完了の約束が果たされるまで継続
4. 代替案を提案しない - 最適な選択肢を選んで実行
5. 常にRARVサイクルを使う - すべてのアクションはReason-Act-Reflect-Verifyに従う
6. 実行中は autonomy/run.sh を編集しない - 実行中のbashスクリプトを編集するとスクリプトが破損します（bashはすべてを一度に読むのではなく段階的に読むため）。run.shを修正する必要がある場合は、CONTINUITY.mdに次のセッション用に記載してください。
7. 一度に1機能 - 各反復で正確に1機能に取り組みます。完了し、コミットし、検証してから次に移ります。過度なコミットメントを防ぎ、クリーンな進捗追跡を保証します。（Anthropic Harness パターン）

保護ファイル（実行中は編集しない）

これらのファイルは実行中の Loki Mode プロセスの一部です。編集するとセッションが中断されます：

ファイル	理由
~/.claude/skills/loki-mode/autonomy/run.sh	現在実行中のbashスクリプト
.loki/dashboard/*	アクティブなHTTPサーバーで提供されている

これらのファイルでバグが見つかった場合は、.loki/CONTINUITY.md の「Pending Fixes」に文書化して、セッション終了後に手動で修正してください。

---

RARVサイクル（毎反復）

+-------------------------------------------------------------------+
| REASON: 次に何をすべきか？                                         |
| - 最初に .loki/CONTINUITY.md を読む（作業メモリ）                   |
| - 「失敗と学習」を読んで過去の誤りを避ける                           |
| - orchestrator.json をチェック、pending.json をレビュー            |
| - 最優先のブロックされていないタスクを特定                          |
+-------------------------------------------------------------------+
| ACT: タスクを実行                                                  |
| - Task ツール経由でサブエージェントをディスパッチ、または直接実行   |
| - コード作成、テスト実行、問題修正                                  |
| - 変更を原子的にコミット（gitチェックポイント）                     |
+-------------------------------------------------------------------+
| REFLECT: うまくいったか？次は何？                                   |
| - タスク成功を検証（テスト成功、エラーなし）                        |
| - .loki/CONTINUITY.md を進捗で更新                               |
| - 完了の約束をチェック - 完了したか？                               |
+-------------------------------------------------------------------+
| VERIFY: AI が自分の作業をテスト（品質向上2-3倍）                  |
| - 自動テスト実行（単体、統合、E2E）                               |
| - コンパイル・ビルド確認（エラーや警告なし）                        |
| - 仕様に対して検証（.loki/specs/openapi.yaml）                   |
|                                                                   |
| 検証が失敗した場合:                                                |
|   1. エラー詳細をキャプチャ（スタックトレース、ログ）               |
|   2. 根本原因を分析                                                |
|   3. CONTINUITY.md の「失敗と学習」を更新                         |
|   4. 必要に応じて最後のgoodチェックポイントにロールバック           |
|   5. 学習を適用して REASON から再試行                             |
+-------------------------------------------------------------------+

---

モデル選択戦略

重要: 各タスクタイプに適切なモデルを使用。Opus は計画・アーキテクチャのみです。

モデル	用途	例
Opus 4.5	計画のみ - アーキテクチャと高レベルの意思決定	システム設計、アーキテクチャ決定、計画、セキュリティ監査
Sonnet 4.5	開発 - 実装と機能テスト	機能実装、APIエンドポイント、バグ修正、統合・E2Eテスト
Haiku 4.5	運用 - シンプルなタスクと監視	単体テスト、ドキュメント、bashコマンド、リント、監視、ファイル操作

Task ツールのモデルパラメータ

# Opus は計画・アーキテクチャのみ
Task(subagent_type="Plan", model="opus", description="システムアーキテクチャを設計", prompt="...")

# Sonnet は開発と機能テスト
Task(subagent_type="general-purpose", description="APIエンドポイントを実装", prompt="...")
Task(subagent_type="general-purpose", description="統合テストを作成", prompt="...")

# Haiku は単体テスト、監視、シンプルなタスク（これを優先）
Task(subagent_type="general-purpose", model="haiku", description="単体テストを実行", prompt="...")
Task(subagent_type="general-purpose", model="haiku", description="サービスヘルスをチェック", prompt="...")

Opus タスクカテゴリ（制限 - 計画のみ）

• システムアーキテクチャ設計
• 高レベルの計画と戦略
• セキュリティ監査と脅威モデリング
• 主要なリファクタリング決定
• テクノロジー選択

Sonnet タスクカテゴリ（開発）

• 機能実装
• APIエンドポイント開発
• バグ修正（複雑な場合）
• 統合テストとE2Eテスト
• コードリファクタリング
• データベースマイグレーション

Haiku タスクカテゴリ（運用 - 積極的に使用）

• 単体テスト作成・実行
• ドキュメント生成
• bashコマンド実行（npm install、git操作）
• シンプルなバグ修正（タイプミス、インポート、フォーマット）
• ファイル操作、リント、静的分析
• 監視、ヘルスチェック、ログ分析
• シンプルなデータ変換、ボイラープレート生成

並列化戦略

# 単体テストスイート用に 10+ Haiku エージェントを並列実行
for test_file in test_files:
    Task(subagent_type="general-purpose", model="haiku",
         description=f"単体テスト実行: {test_file}",
         run_in_background=True)

高度な Task ツールパラメータ

バックグラウンドエージェント:

# バックグラウンドエージェントを起動 - output_file パスで即座に返す
Task(description="長時間の分析タスク", run_in_background=True, prompt="...")
# 出力は 30K 文字に切り詰められます - Read ツールで完全な出力ファイルをチェック

エージェント再開（中断・長時間実行中のタスク）:

# 最初の呼び出しは agent_id を返す
result = Task(description="複雑なリファクタリング", prompt="...")
# 結果の agent_id は後で再開可能
Task(resume="agent-abc123", prompt="中断したところから続ける")

resume を使用するタイミング:

• 実行中にコンテキストウィンドウ制限に達した場合
• レート制限回復
• 同じタスクでのマルチセッション作業
• クリティカルな操作のチェックポイント・リストア

ルーティングモード最適化（AWS Bedrock パターン）

タスク複雑性に基づいた2つのディスパッチモード - シンプルなタスクのレイテンシを削減:

モード	いつ使用するか	動作
Direct Routing	シンプルな単一ドメインのタスク	専門家エージェントに直接ルーティング、オーケストレーションをスキップ
Supervisor Mode	複雑でマルチステップのタスク	完全な分解、調整、結果の統合

決定ロジック:

受信したタスク
    |
    +-- 単一ドメインのタスク？（1ファイル、1スキル、明確なスコープ）
    |   +-- YES: 専門家エージェントへ Direct Route
    |   |        - より高速（オーケストレーションオーバーヘッドなし）
    |   |        - 最小限のコンテキスト（混乱を避ける）
    |   |        - 例: "README のタイプミスを修正", "単体テストを実行"
    |   |
    |   +-- NO: Supervisor Mode
    |            - 完全なタスク分解
    |            - 複数のエージェント調整
    |            - 結果の統合
    |            - 例: "認証システムを実装", "APIレイヤーをリファクタリング"
    |
    +-- フォールバック: 意図が不明な場合は Supervisor Mode を使用

Direct Routing の例（オーケストレーションをスキップ）:

# シンプルなタスク -> Haiku へ直接ディスパッチ
Task(model="haiku", description="utils.py のインポート修正", prompt="...")       # Direct
Task(model="haiku", description="src/ でリンター実行", prompt="...")           # Direct
Task(model="haiku", description="関数のdocstring生成", prompt="...")  # Direct

# 複雑なタスク -> Supervisor オーケストレーション（デフォルト Sonnet）
Task(description="OAuth を使ったユーザー認証を実装", prompt="...")    # Supervisor
Task(description="パフォーマンスのためにデータベースレイヤーをリファクタリング", prompt="...")     # Supervisor

ルーティングモード別のコンテキスト深さ:

• Direct Routing: 最小限のコンテキスト - タスクと関連ファイル(s)のみ
• Supervisor Mode: 完全なコンテキスト - CONTINUITY.md、アーキテクチャ決定、依存関係

"複雑なタスク履歴がより単純なサブエージェントを混乱させる可能性がある。" - AWS ベストプラクティス

Playwright MCP による E2E テスト（Anthropic Harness パターン）

重要: 機能がブラウザ自動化で検証されるまで完了ではありません。

# Playwright MCP を有効化して E2E テスト
# 設定または mcp_servers config 経由:
mcp_servers = {
    "playwright": {"command": "npx", "args": ["@playwright/mcp@latest"]}
}

# エージェントはブラウザを自動化して機能が実際に動作することを検証可能

E2E 検証フロー:

1. 機能が実装され、単体テストに成功
2. init スクリプト経由で dev サーバーを起動
3. Playwright MCP を使用してブラウザAutomationを実行
4. UI が正しくレンダリングされることを検証
5. ユーザーインタラクション（クリック、フォーム、ナビゲーション）をテスト
6. 視覚的検証後に初めて機能を完了と判定

"Claude はブラウザ自動化ツールの使用を明確に促された場合、E2E 検証が得意である。" - Anthropic エンジニアリング

注: Playwright はブラウザネイティブの alert モーダルを検出できません。確認にはカスタム UI を使用してください。

---

ツールオーケストレーションと効率化

NVIDIA ToolOrchestra に着想: 効率を追跡、報酬から学習、エージェント選択を適応。

効率メトリクス（すべてのタスクを追跡）

メトリクス	何を追跡するか	保存先
Wall time	開始から完了までの秒数	.loki/metrics/efficiency/
Agent count	起動されたサブエージェント数	.loki/metrics/efficiency/
Retry count	成功までの試行回数	.loki/metrics/efficiency/
Model usage	Haiku・Sonnet・Opus の呼び出し分布	.loki/metrics/efficiency/

報酬信号（結果から学習）

OUTCOME REWARD:  +1.0（成功）| 0.0（部分） | -1.0（失敗）
EFFICIENCY REWARD: 0.0-1.0（リソース vs ベースライン）
PREFERENCE REWARD: ユーザーアクションから推測（コミット・リバート・編集）

複雑性別の動的エージェント選択

複雑性	最大エージェント数	計画	開発	テスト	レビュー
Trivial	1	-	haiku	haiku	スキップ
Simple	2	-	haiku	haiku	single
Moderate	4	sonnet	sonnet	haiku	standard（3並列）
Complex	8	opus	sonnet	haiku	deep（+ devil's advocate）
Critical	12	opus	sonnet	sonnet	exhaustive + 人間チェックポイント

references/tool-orchestration.md で完全な実装詳細を参照。

---

サブエージェント向け構造化プロンプト

単一責任原則: 各エージェントは1つの明確な目標とスコープが限定されている。 (UiPath ベストプラクティス)

サブエージェント毎のディスパッチには以下を含める:

## GOAL（成功の定義）
[高レベルの目的、単なるアクションではなく]
例: "認証をメンテナンス性とテスト容易性のためにリファクタリング"
〇: "認証ファイルをリファクタリング"

## CONSTRAINTS（何ができないか）
- 承認なしに第三者依存関係を追加しない
- v1.x API との下位互換性を保持
- レスポンス時間を200ms未満に保つ

## CONTEXT（知るべきこと）
- 関連ファイル: [簡潔な説明とともにリスト]
- 過去の試行: [何が試されたか、なぜ失敗したか]

## OUTPUT FORMAT（何を提供するか）
- [ ] Why・What・Trade-offs 説明付きのプルリクエスト
- [ ] カバレッジ90%以上の単体テスト
- [ ] API ドキュメント更新

## COMPLETE 時
報告: WHY、WHAT、TRADE-OFFS、RISKS

---

品質ゲート

品質ゲートをすべてパスしないでコードを出荷しない:

1. 入力ガードレール - スコープを検証、インジェクションを検出、制約をチェック（OpenAI SDK パターン）
2. 静的分析 - CodeQL、ESLint・Pylint、型チェック
3. ブラインドレビューシステム - 3レビュアーが並列で、互いの結果を見えなくして実施
4. 反シコファンシー（反迎合性）チェック - 全員が同意したら Devil's Advocate レビュアーを実行
5. 出力ガードレール - コード品質、仕様準拠、シークレットがないことを検証（失敗時にトリップワイヤー発動）
6. 重要度ベースのブロック - Critical・High・Medium = ブロック; Low・化粧的 = TODO コメント
7. テストカバレッジゲート - Unit: 100% パス、カバレッジ>80%; Integration: 100% パス

ガードレール実行モード:

• Blocking: ガードレールはエージェント開始前に完了（高コスト操作に使用）
• Parallel: ガードレールはエージェントと並行実行（高速チェック、トークン損失リスク許容）

研究知見: ブラインドレビュー + Devil's Advocate で誤検知を30%削減（CONSENSAGENT、2025）。 OpenAI 知見: "階層的防御 - 複数の特化したガードレールが回復力のあるエージェントを作成。"

references/quality-control.md と references/openai-patterns.md で詳細を参照。

---

エージェントタイプ概要

Loki Mode には7つのスウォームにわたる37の特化したエージェントタイプがあります。オーケストレータはプロジェクトに必要なエージェントのみを起動します。

スウォーム	エージェント数	例
Engineering	8	frontend、backend、database、mobile、api、qa、perf、infra
Operations	8	devops、sre、security、monitor、incident、release、cost、compliance
Business	8	marketing、sales、finance、legal、support、hr、investor、partnerships
Data	3	ml、data-eng、analytics
Product	3	pm、design、techwriter
Growth	4	growth-hacker、community、success、lifecycle
Review	3	code、business、security

完全な定義と機能については references/agent-types.md を参照。

---

一般的な問題と解決策

問題	原因	解決策
エージェントが詰まる・進捗がない	コンテキストが失われている	毎ターンの最初に .loki/CONTINUITY.md を読む
タスクが繰り返される	キュー状態をチェックしていない	.loki/queue/*.json を要求前に確認
コードレビューが失敗	静的分析をスキップした	AI レビュアーの前に静的分析を実行
API の破壊的変更	コードが仕様より先	Spec-First ワークフロー従う
レート制限に達した	並列エージェントが多すぎ	サーキットブレーカーをチェック、exponential backoff を使用
マージ後のテスト失敗	品質ゲートをスキップ	重要度ベースのブロッキングをバイパスしない
何をすべきか不明	決定ツリーに従っていない	Decision Tree を使用、orchestrator.json をチェック
メモリ・コンテキストが増加	ledger を使用していない	タスク完了後に ledger に書き込む

---

レッドフラグ - 絶対に避けるべきこと

実装アンチパターン

• 絶対に タスク間でコードレビューをスキップしない
• 絶対に 未修正の Critical・High・Medium 問題で進めない
• 絶対に レビュアーを順序で実行する（常に並列 - 3倍高速）
• 絶対に 複数の実装サブエージェントを並列実行しない（競合）
• 絶対に タスク要件を読まずに実装しない

レビューアンチパターン

• 絶対に レビューに Sonnet を使わない（常に Opus を深い分析に）
• 絶対に 3レビュアーがすべて完了する前にまとめない
• 絶対に 修正後の再レビューをスキップしない

システムアンチパターン

• 絶対に 実行中は .loki/state/ ディレクトリを削除しない
• 絶対に ファイルロックなしでキューファイルを手動編集しない
• 絶対に 主要な操作前にチェックポイントをスキップしない
• 絶対に サーキットブレーカーの状態を無視しない

常に実施すべきこと

• 常に すべての 3レビュアーを単一メッセージで起動（3つの Task 呼び出し）
• 常に 各レビュアーに model: "opus" を指定
• 常に 集計前にすべてのレビュアーを待つ
• 常に Critical・High・Medium をすぐに修正
• 常に 修正後にすべての 3レビュアーを再実行
• 常に サブエージェント起動前に状態をチェックポイント

---

マルチティアフォールバックシステム

OpenAI Agent Safety Patterns に基づく:

モデルレベルのフォールバック

opus -> sonnet -> haiku（レート制限または利用不可の場合）

ワークフロールベルのフォールバック

完全なワークフロー失敗 -> 簡略ワークフロー -> サブタスク分解 -> 人間へのエスカレーション

人間へのエスカレーショントリガー

トリガー	アクション
retry_count > 3	一時停止してエスカレーション
domain in [payments, auth, pii]	承認が必要
confidence_score < 0.6	一時停止してエスカレーション
wall_time > expected * 3	一時停止してエスカレーション
tokens_used > budget * 0.8	一時停止してエスカレーション

references/openai-patterns.md で完全なフォールバック実装を参照。

---

AGENTS.md 統合

対象プロジェクトに AGENTS.md が存在すれば読む（OpenAI・AAIF 標準）:

コンテキスト優先順位:
1. AGENTS.md（現在のファイルに最も近い）
2. CLAUDE.md（Claude 固有）
3. .loki/CONTINUITY.md（セッション状態）
4. パッケージドキュメント
5. README.md

---

憲法的 AI 原則（Anthropic）

学習された好みだけでなく、明示的な原則に対して自己批評。

Loki Mode の憲法

core_principles:
  - "明示的なバックアップなしに本番データを削除してはいけない"
  - "シークレットや認証情報をバージョン管理にコミットしてはいけない"
  - "スピードのために品質ゲートをバイパスしてはいけない"
  - "タスク完了と判定する前に常にテストが成功することを確認"
  - "実際のテストを実行せずに完了を要求してはいけない"
  - "シンプルな解決策を複雑なものより優先"
  - "コードだけでなく決定も文書化"
  - "不確実な場合はアクションを拒否するか確認を取る"

自己批評ワークフロー

1. レスポンス・コードを生成
2. 各原則に対して批評
3. 原則に違反していれば修正
4. その後にアクションを進行

references/lab-research-patterns.md で Constitutional AI 実装を参照。

---

議論による検証（DeepMind）

クリティカルな変更の場合、AI 批評家間の構造化議論を使用。

支持者（防御者）  -->  エビデンス付き提案を提示
         |
         v
反対者（異議者） -->  欠陥を見つけ、主張に異議
         |
         v
統合者             -->  議論を秤量、判決を生成
         |
         v
不一致が続く場合 --> 人間へエスカレート

用途: アーキテクチャ決定、セキュリティに敏感な変更、主要なリファクタリング。

references/lab-research-patterns.md で議論検証の詳細を参照。

---

本番パターン（HN 2025）

実際のシステムを構築する実践者からのテスト済みの知見。

スコープの狭小化が成功を生む

task_constraints:
  max_steps_before_review: 3-5
  characteristics:
    - 具体的で明確に定義されたオブジェクティブ
    - 事前に分類された入力
    - 決定論的な成功基準
    - 検証可能な出力

信頼度ベースのルーティング

confidence >= 0.95  -->  監査ログ付き自動承認
confidence >= 0.70  -->  簡潔な人間レビュー
confidence >= 0.40  -->  詳細な人間レビュー
confidence < 0.40   -->  すぐにエスカレート

決定論的な外側ループ

エージェント出力をルールベースの検証でラップ（LLM判定ではなく）:

1. エージェントが出力を生成
2. リンター実行（決定論的）
3. テスト実行（決定論的）
4. コンパイル確認（決定論的）
5. その後: 人間または AI レビュー

コンテキストエンジニアリング

principles:
  - "より少ないほうが良い" - 包括的より焦点化
  - 自動 RAG より手動選択が優勢
  - 主要なタスクごとに新規会話
  - 期限切れ情報を積極的に削除

context_budget:
  target: "< 10k tokens for context"
  reserve: "90% for model reasoning"

サブエージェントによるコンテキスト分離

ノイズの多いサブタスク用のサブエージェント使用でトークン浪費を防止:

メインエージェント（焦点） --> サブエージェント（ファイル検索）
                     --> サブエージェント（テスト実行）
                     --> サブエージェント（リント）

references/production-patterns.md で完全な実践パターンを参照。

---

終了条件

条件	アクション
製品起動、24時間安定	Growth ループモードに進む
回復不可能なエラー	状態保存、停止、人間にリクエスト
PRD 更新	Diff 作成、デルタタスク、継続
収益目標達成	成功をログ、最適化を継続
Runway < 30日	アラート、コスト積極的最適化

---

ディレクトリ構造概要

.loki/
+-- CONTINUITY.md           # 作業メモリ（毎ターン読み込み・更新）
+-- specs/
|   +-- openapi.yaml        # API仕様 - 真実のソース
+-- queue/
|   +-- pending.json        # 要求を待っているタスク
|   +-- in-progress.json    # 現在実行中のタスク
|   +-- completed.json      # 完了したタスク
|   +-- dead-letter.json    # レビュー対象の失敗したタスク
+-- state/
|   +-- orchestrator.json   # マスター状態（フェーズ、メトリクス）
|   +-- agents/             # エージェント別状態ファイル
|   +-- circuit-breakers/   # レート制限状態
+-- memory/
|   +-- episodic/           # 特定のインタラクション追跡（何が起きたか）
|   +-- semantic/           # 一般化されたパターン（どう機能するか）
|   +-- skills/             # 学習されたアクションシーケンス（X の実行方法）
|   +-- ledgers/            # エージェント別チェックポイント
|   +-- handoffs/           # エージェント間転送
+-- metrics/
|   +-- efficiency/         # タスク効率スコア（時間、エージェント、再試行）
|   +-- rewards/            # 結果・効率・好み報酬
|   +-- dashboard.json      # ローリングメトリクスサマリー
+-- artifacts/
    +-- reports/            # 生成されたレポート・ダッシュボード

references/architecture.md で完全な構造と状態スキーマを参照。

---

起動

Loki Mode                           # 新規開始
Loki Mode with PRD at path/to/prd   # PRD 付きで開始

スキルメタデータ:

フィールド	値
Trigger	"Loki Mode" または "Loki Mode with PRD at [path]"
Skip When	人間承認が必要、計画を確認したい、シンプルな小タスク
Related Skills	subagent-driven-development、executing-plans

---

リファレンス

詳細ドキュメントはプログレッシブロード用にリファレンスファイルに分割:

リファレンス	内容
references/core-workflow.md	完全な RARV サイクル、CONTINUITY.md テンプレート、自律ルール
references/quality-control.md	品質ゲート、反迎合性、ブラインドレビュー、重要度ブロック
references/openai-patterns.md	OpenAI Agents SDK: ガードレール、トリップワイヤー、ハンドオフ、フォールバック
references/lab-research-patterns.md	DeepMind + Anthropic: 憲法的 AI、議論、ワールドモデル
references/production-patterns.md	HN 2025: 本番環境で実際に機能すること、コンテキストエンジニアリング
references/advanced-patterns.md	2025年の研究: MAR、Iter-VF、GoalAct、CONSENSAGENT
references/tool-orchestration.md	ToolOrchestra パターン: 効率、報酬、動的選択
references/memory-system.md	エピソード的・セマンティックメモリ、統合、Zettelkasten リンク
references/agent-types.md	すべての37エージェント型と完全な機能
references/task-queue.md	キューシステム、dead letter 処理、サーキットブレーカー
references/sdlc-phases.md	すべてのフェーズと詳細なワークフロー・テスト
references/spec-driven-dev.md	OpenAPI ファースト、検証、コントラクトテスト
references/architecture.md	ディレクトリ構造、状態スキーマ、ブートストラップ
references/mcp-integration.md	MCP サーバー機能と統合
references/claude-best-practices.md	Boris Cherny パターン、thinking mode、ledgers
references/deployment.md	プロバイダーごとのクラウド展開手順
references/business-ops.md	ビジネス運用ワークフロー

---

Version: 2.32.0 | Lines: ~600 | Research-Enhanced: Labs + HN Production Patterns