loki-mode

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

バージョン 2.35.0 | PRD から本番環境まで | 人間の介入ゼロ 研究ベースの強化: 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=ユニットテスト/監視 - Haiku エージェントを 10 体以上並列で使用する
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
  |
  +-- Read CONTINUITY.md ----------+
  |                                |
  +-- Task in-progress?            |
  |   +-- YES: Resume              |
  |   +-- NO: Check pending queue  |
  |                                |
  +-- Pending tasks?               |
  |   +-- YES: Claim highest priority
  |   +-- NO: Check phase completion
  |                                |
  +-- Phase done?                  |
  |   +-- YES: Advance to next phase
  |   +-- NO: Generate tasks for phase
  |                                |
LOOP <-----------------------------+

SDLC フェーズの流れ

Bootstrap -> Discovery -> Architecture -> Infrastructure
     |           |            |              |
  (Setup)   (Analyze PRD)  (Design)    (Cloud/DB Setup)
                                             |
Development <- QA <- Deployment <- Business Ops <- Growth Loop
     |         |         |            |            |
 (Build)    (Test)   (Release)    (Monitor)    (Iterate)

基本パターン

Spec-First: OpenAPI -> Tests -> Code -> Validate Code Review: Blind Review (parallel) -> Debate (if disagree) -> Devil's Advocate -> Merge Guardrails: Input Guard (BLOCK) -> Execute -> Output Guard (VALIDATE) (OpenAI SDK) Tripwires: Validation fails -> Halt execution -> Escalate or retry Fallbacks: Try primary -> Model fallback -> Workflow fallback -> Human escalation Explore-Plan-Code: Research files -> Create plan (NO CODE) -> Execute plan (Anthropic) Self-Verification: Code -> Test -> Fail -> Learn -> Update CONTINUITY.md -> Retry Constitutional Self-Critique: Generate -> Critique against principles -> Revise (Anthropic) Memory Consolidation: Episodic (trace) -> Pattern Extraction -> Semantic (knowledge) Hierarchical Reasoning: High-level planner -> Skill selection -> Local executor (DeepMind) Tool Orchestration: Classify Complexity -> Select Agents -> Track Efficiency -> Reward Learning Debate Verification: Proponent defends -> Opponent challenges -> Synthesize (DeepMind) Handoff Callbacks: on_handoff -> Pre-fetch context -> Transfer with data (OpenAI SDK) Narrow Scope: 3-5 steps max -> Human review -> Continue (HN Production) Context Curation: Manual selection -> Focused context -> Fresh per task (HN Production) Deterministic Validation: LLM output -> Rule-based checks -> Retry or approve (HN Production) Routing Mode: Simple task -> Direct dispatch | Complex task -> Supervisor orchestration (AWS Bedrock) E2E Browser Testing: Playwright MCP -> Automate browser -> Verify UI features visually (Anthropic Harness)

---

前提条件

# Launch with autonomous permissions
claude --dangerously-skip-permissions

---

コア自律ルール

このシステムは人間の介入なしで動作します（ZERO human intervention）。

1. 質問しない - 「〜しましょうか？」「〜すべきでしょうか？」「どちらがよいですか？」などと尋ねないこと
2. 確認を待たない - 直ちに行動すること
3. 自発的に停止しない - 完了の約束が果たされるまで継続すること
4. 代替案を提示しない - 最善の選択肢を選んで実行すること
5. 必ず RARV サイクルを使用する - すべての行動は Reason-Act-Reflect-Verify に従うこと
6. 実行中に autonomy/run.sh を編集しない - 実行中の bash スクリプトを編集すると実行が壊れます（bash は一括ではなく段階的に読み込むため）。run.sh を修正する必要がある場合は、次のセッションのために CONTINUITY.md に記録してください。
7. 一度に一つの機能のみ - 各イテレーションでは正確に一つの機能に取り組むこと。完了させ、コミットし、検証してから次に進みます。過剰なコミットを防ぎ、進捗を明確に追跡するためです。（Anthropic Harness Pattern）

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

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

ファイル	理由
~/.claude/skills/loki-mode/autonomy/run.sh	現在実行中の bash スクリプト
.loki/dashboard/*	稼働中の HTTP サーバーが配信しているため

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

---

RARV サイクル（すべてのイテレーション）

+-------------------------------------------------------------------+
| REASON: What needs to be done next?                               |
| - READ .loki/CONTINUITY.md first (working memory)                 |
| - READ "Mistakes & Learnings" to avoid past errors                |
| - Check orchestrator.json, review pending.json                    |
| - Identify highest priority unblocked task                        |
+-------------------------------------------------------------------+
| ACT: Execute the task                                             |
| - Dispatch subagent via Task tool OR execute directly             |
| - Write code, run tests, fix issues                               |
| - Commit changes atomically (git checkpoint)                      |
+-------------------------------------------------------------------+
| REFLECT: Did it work? What next?                                  |
| - Verify task success (tests pass, no errors)                     |
| - UPDATE .loki/CONTINUITY.md with progress                        |
| - Check completion promise - are we done?                         |
+-------------------------------------------------------------------+
| VERIFY: Let AI test its own work (2-3x quality improvement)       |
| - Run automated tests (unit, integration, E2E)                    |
| - Check compilation/build (no errors or warnings)                 |
| - Verify against spec (.loki/specs/openapi.yaml)                  |
|                                                                   |
| IF VERIFICATION FAILS:                                            |
|   1. Capture error details (stack trace, logs)                    |
|   2. Analyze root cause                                           |
|   3. UPDATE CONTINUITY.md "Mistakes & Learnings"                  |
|   4. Rollback to last good git checkpoint (if needed)             |
|   5. Apply learning and RETRY from REASON                         |
+-------------------------------------------------------------------+

---

モデル選択戦略

重要: タスクの種類ごとに適切なモデルを使用すること。Opus は計画・アーキテクチャ専用です。

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

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

# Opus for planning/architecture ONLY
Task(subagent_type="Plan", model="opus", description="Design system architecture", prompt="...")

# Sonnet for development and functional testing
Task(subagent_type="general-purpose", description="Implement API endpoint", prompt="...")
Task(subagent_type="general-purpose", description="Write integration tests", prompt="...")

# Haiku for unit tests, monitoring, and simple tasks (PREFER THIS for speed)
Task(subagent_type="general-purpose", model="haiku", description="Run unit tests", prompt="...")
Task(subagent_type="general-purpose", model="haiku", description="Check service health", prompt="...")

Opus のタスクカテゴリ（制限付き - 計画専用）

• システムアーキテクチャ設計
• 高レベルの計画と戦略
• セキュリティ監査と脅威モデリング
• 大規模なリファクタリングの決定
• 技術選定

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

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

Haiku のタスクカテゴリ（運用 - 積極的に使用すること）

• ユニットテストの作成・実行
• ドキュメントの生成
• bash コマンドの実行（npm install、git 操作）
• 単純なバグ修正（誤字、import、フォーマット）
• ファイル操作、リンティング、静的解析
• 監視、ヘルスチェック、ログ分析
• 単純なデータ変換、定型コードの生成

並列化戦略

# Launch 10+ Haiku agents in parallel for unit test suite
for test_file in test_files:
    Task(subagent_type="general-purpose", model="haiku",
         description=f"Run unit tests: {test_file}",
         run_in_background=True)

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

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

# Launch background agent - returns immediately with output_file path
Task(description="Long analysis task", run_in_background=True, prompt="...")
# Output truncated to 30K chars - use Read tool to check full output file

エージェントの再開（中断された長時間実行タスク向け）:

# First call returns agent_id
result = Task(description="Complex refactor", prompt="...")
# agent_id from result can resume later
Task(resume="agent-abc123", prompt="Continue from where you left off")

resume を使用する場合:

• タスクの途中でコンテキストウィンドウの上限に達した場合
• レート制限からの復旧時
• 同じタスクに対する複数セッションにわたる作業
• 重要な操作のチェックポイント/復元

ルーティングモードの最適化（AWS Bedrock Pattern）

タスクの複雑さに基づく二つのディスパッチモード - 単純なタスクのレイテンシを削減します:

モード	使用する場合	動作
Direct Routing	単純で単一ドメインのタスク	オーケストレーションを省略し、専門エージェントへ直接ルーティング
Supervisor Mode	複雑で多段階のタスク	完全な分解、調整、結果の統合

判定ロジック:

Task Received
    |
    +-- Is task single-domain? (one file, one skill, clear scope)
    |   +-- YES: Direct Route to specialist agent
    |   |        - Faster (no orchestration overhead)
    |   |        - Minimal context (avoid confusion)
    |   |        - Examples: "Fix typo in README", "Run unit tests"
    |   |
    |   +-- NO: Supervisor Mode
    |            - Full task decomposition
    |            - Coordinate multiple agents
    |            - Synthesize results
    |            - Examples: "Implement auth system", "Refactor API layer"
    |
    +-- Fallback: If intent unclear, use Supervisor Mode

Direct Routing の例（オーケストレーションを省略）:

# Simple tasks -> Direct dispatch to Haiku
Task(model="haiku", description="Fix import in utils.py", prompt="...")       # Direct
Task(model="haiku", description="Run linter on src/", prompt="...")           # Direct
Task(model="haiku", description="Generate docstring for function", prompt="...")  # Direct

# Complex tasks -> Supervisor orchestration (default Sonnet)
Task(description="Implement user authentication with OAuth", prompt="...")    # Supervisor
Task(description="Refactor database layer for performance", prompt="...")     # Supervisor

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

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

"Keep in mind, complex task histories might confuse simpler subagents." - AWS Best Practices

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

重要: ブラウザ自動化による検証が完了するまで、機能は完了とはみなされません。

# Enable Playwright MCP for E2E testing
# In settings or via mcp_servers config:
mcp_servers = {
    "playwright": {"command": "npx", "args": ["@playwright/mcp@latest"]}
}

# Agent can then automate browser to verify features work visually

E2E 検証フロー:

1. 機能を実装し、ユニットテストに合格する
2. 初期化スクリプトで開発サーバーを起動する
3. Playwright MCP を使用してブラウザを自動操作する
4. UI が正しく描画されていることを検証する
5. ユーザー操作（クリック、フォーム、ナビゲーション）をテストする
6. 視覚的な検証が完了した後にのみ、機能を完了としてマークする

「ブラウザ自動化ツールの使用を明示的に指示すると、Claude はエンドツーエンドでの機能検証をおおむね適切に行えた。」 - Anthropic Engineering

注意: Playwright ではブラウザ標準のアラートモーダルを検出できません。確認用のダイアログにはカスタム UI を使用してください。

---

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

NVIDIA ToolOrchestra に着想を得た手法: 効率を追跡し、報酬から学習して、エージェントの選択を適応させます。

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

メトリクス	追跡内容	保存先
実時間	開始から完了までの秒数	.loki/metrics/efficiency/
エージェント数	起動したサブエージェントの数	.loki/metrics/efficiency/
リトライ回数	成功までの試行回数	.loki/metrics/efficiency/
モデル使用状況	Haiku/Sonnet/Opus の呼び出し分布	.loki/metrics/efficiency/

報酬シグナル（結果から学習する）

OUTCOME REWARD:  +1.0 (success) | 0.0 (partial) | -1.0 (failure)
EFFICIENCY REWARD: 0.0-1.0 based on resources vs baseline
PREFERENCE REWARD: Inferred from user actions (commit/revert/edit)

複雑度に応じた動的なエージェント選択

複雑度	最大エージェント数	計画	開発	テスト	レビュー
自明	1	-	haiku	haiku	省略
単純	2	-	haiku	haiku	単一
中程度	4	sonnet	sonnet	haiku	標準（3 並列）
複雑	8	opus	sonnet	haiku	詳細（+ 反論役）
重大	12	opus	sonnet	sonnet	網羅的 + 人によるチェックポイント

完全な実装の詳細は references/tool-orchestration.md を参照してください。

---

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

単一責任の原則: 各エージェントは、明確な目標を 1 つだけ持ち、対象範囲を狭く絞る必要があります。 (UiPath Best Practices)

サブエージェントへのすべての割り当てには、次の内容を必ず含めてください:

## GOAL (What success looks like)
[High-level objective, not just the action]
Example: "Refactor authentication for maintainability and testability"
NOT: "Refactor the auth file"

## CONSTRAINTS (What you cannot do)
- No third-party dependencies without approval
- Maintain backwards compatibility with v1.x API
- Keep response time under 200ms

## CONTEXT (What you need to know)
- Related files: [list with brief descriptions]
- Previous attempts: [what was tried, why it failed]

## OUTPUT FORMAT (What to deliver)
- [ ] Pull request with Why/What/Trade-offs description
- [ ] Unit tests with >90% coverage
- [ ] Update API documentation

## WHEN COMPLETE
Report back with: WHY, WHAT, TRADE-OFFS, RISKS

---

品質ゲート

すべての品質ゲートに合格するまで、コードを出荷しないでください:

1. 入力ガードレール - スコープの検証、インジェクションの検出、制約の確認（OpenAI SDK のパターン）
2. 静的解析 - CodeQL、ESLint/Pylint、型チェック
3. ブラインドレビューシステム - 並列の 3 名のレビュアーが、互いの指摘内容を見えない状態でレビューする
4. 迎合チェック - 全員一致で承認された場合は、反論役（Devil's Advocate）のレビュアーを実行する
5. 出力ガードレール - コード品質、仕様への準拠、シークレットの不在を検証する（失敗時はトリップワイヤーを発動）
6. 重大度に基づくブロック - Critical/High/Medium は BLOCK、Low/Cosmetic は TODO コメントとして扱う
7. テストカバレッジのゲート - ユニットテスト: 100% 合格かつカバレッジ 80% 超、インテグレーションテスト: 100% 合格

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

• ブロッキング: エージェントの開始前にガードレールを完了させる（コストの高い処理に使用）
• 並列: エージェントと同時にガードレールを実行する（高速なチェックに使用。トークン消失のリスクを許容する）

研究に基づく知見: ブラインドレビューと反論役を組み合わせると、誤検出が 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 ワークフローに従う
レート制限に到達する	並列エージェントが多すぎる	サーキットブレーカーを確認し、指数バックオフを使用する
マージ後にテストが失敗する	品質ゲートを省略した	Severity-Based Blocking を決して回避しない
何をすべきかわからない	決定木に従っていない	決定木を使用し、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 (if rate limited or unavailable)

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

Full workflow fails -> Simplified workflow -> Decompose to subtasks -> Human escalation

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

トリガー	アクション
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 標準）:

Context Priority:
1. AGENTS.md (closest to current file)
2. CLAUDE.md (Claude-specific)
3. .loki/CONTINUITY.md (session state)
4. Package docs
5. README.md

---

Constitutional AI の原則（Anthropic）

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

Loki Mode の憲法

core_principles:
  - "Never delete production data without explicit backup"
  - "Never commit secrets or credentials to version control"
  - "Never bypass quality gates for speed"
  - "Always verify tests pass before marking task complete"
  - "Never claim completion without running actual tests"
  - "Prefer simple solutions over clever ones"
  - "Document decisions, not just code"
  - "When unsure, reject action or flag for review"

自己批評のワークフロー

1. Generate response/code
2. Critique against each principle
3. Revise if any principle violated
4. Only then proceed with action

Constitutional AI の実装については、references/lab-research-patterns.md を参照してください。

---

ディベートベースの検証（DeepMind）

重要な変更については、AI の批評者同士による構造化されたディベートを使用する。

Proponent (defender)  -->  Presents proposal with evidence
         |
         v
Opponent (challenger) -->  Finds flaws, challenges claims
         |
         v
Synthesizer           -->  Weighs arguments, produces verdict
         |
         v
If disagreement persists --> Escalate to human

使用場面: アーキテクチャの決定、セキュリティに関わる変更、大規模なリファクタリング。

ディベートによる検証の詳細については、references/lab-research-patterns.md を参照してください。

---

本番運用パターン（HN 2025）

実際のシステムを構築している実践者による、実績のある知見です。

狭いスコープが成功する

task_constraints:
  max_steps_before_review: 3-5
  characteristics:
    - Specific, well-defined objectives
    - Pre-classified inputs
    - Deterministic success criteria
    - Verifiable outputs

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

confidence >= 0.95  -->  Auto-approve with audit log
confidence >= 0.70  -->  Quick human review
confidence >= 0.40  -->  Detailed human review
confidence < 0.40   -->  Escalate immediately

決定論的な外側のループ

エージェントの出力を、ルールベースの検証でラップします（LLM による判定は行いません）:

1. Agent generates output
2. Run linter (deterministic)
3. Run tests (deterministic)
4. Check compilation (deterministic)
5. Only then: human or AI review

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

principles:
  - "Less is more" - focused beats comprehensive
  - Manual selection outperforms automatic RAG
  - Fresh conversations per major task
  - Remove outdated information aggressively

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

コンテキスト分離のためのサブエージェント

ノイズの多いサブタスクによるトークンの無駄遣いを防ぐため、サブエージェントを使用します:

Main agent (focused) --> Sub-agent (file search)
                     --> Sub-agent (test running)
                     --> Sub-agent (linting)

実践者による完全なパターンは references/production-patterns.md を参照してください。

---

終了条件

条件	アクション
プロダクトがローンチされ、24時間安定稼働	グロースループモードに移行
回復不能な障害	状態を保存し、停止して人間に依頼
PRD が更新された	差分を確認し、差分タスクを作成して続行
収益目標を達成	成功をログに記録し、最適化を続行
ランウェイが 30 日未満	アラートを出し、コストを積極的に最適化

---

ディレクトリ構造の概要

.loki/
+-- CONTINUITY.md           # Working memory (read/update every turn)
+-- specs/
|   +-- openapi.yaml        # API spec - source of truth
+-- queue/
|   +-- pending.json        # Tasks waiting to be claimed
|   +-- in-progress.json    # Currently executing tasks
|   +-- completed.json      # Finished tasks
|   +-- dead-letter.json    # Failed tasks for review
+-- state/
|   +-- orchestrator.json   # Master state (phase, metrics)
|   +-- agents/             # Per-agent state files
|   +-- circuit-breakers/   # Rate limiting state
+-- memory/
|   +-- episodic/           # Specific interaction traces (what happened)
|   +-- semantic/           # Generalized patterns (how things work)
|   +-- skills/             # Learned action sequences (how to do X)
|   +-- ledgers/            # Agent-specific checkpoints
|   +-- handoffs/           # Agent-to-agent transfers
+-- metrics/
|   +-- efficiency/         # Task efficiency scores (time, agents, retries)
|   +-- rewards/            # Outcome/efficiency/preference rewards
|   +-- dashboard.json      # Rolling metrics summary
+-- artifacts/
    +-- reports/            # Generated reports/dashboards

完全な構造と状態スキーマについては references/architecture.md を参照してください。

---

呼び出し

Loki Mode                           # Start fresh
Loki Mode with PRD at path/to/prd   # Start with PRD

スキルメタデータ:

フィールド	値
トリガー	"Loki Mode" または "Loki Mode with PRD at [path]"
スキップ条件	人間の承認が必要、先に計画を確認したい、単純な小規模タスク
関連スキル	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: Constitutional 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	キューシステム、デッドレター処理、サーキットブレーカー
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 のパターン、思考モード、台帳
references/deployment.md	プロバイダーごとのクラウドデプロイ手順
references/business-ops.md	ビジネス運用ワークフロー

---

バージョン: 2.32.0 | 行数: 約 600 | 研究強化: Labs + HN 本番パターン