inho-team · qe-framework · v6.5.0

QE Framework
システム構成図

Query & Execute — AI とのすべてのインタラクションを 2 つのアクションに還元し、その間に Plan → Spec → Execute → Verify パイプラインと SIVS 品質ゲートを挿入する Claude Code プラグイン。

SKILLS ···· 165
AGENTS ···· 21
CODING EXPERTS ···· 71
LICENSE ···· MIT

USER SAYS

"何をしたい？"
"それをやって"

→

CONTEXTFolder Memory

QUALITYSIVS Loop

LIBRARY165 Skills

→

YOU GET

精密な Query
検証済み Result

PSE Chain — ユーザーワークフロー

4-STEP PIPELINE

ユーザー動線 4 段階 — 大きなタスクでも 1 つのバグでも同じパイプライン。各段階は既定のモデルが決まっていますが、/Qsivs-configで自由に変更可能。Qplan が Micro スケールと判定したら、ロードマップなしで直ちに /Qgs に自動ハンドオフ— ユーザーはスケール判定の必要がありません。

STEP 01 / PLAN

Plan

/Qplan

ロードマップ・段階・要件を押さえます。何を作るかを構造化する段階。

→

STEP 02 / SPEC

Spec

/Qgs

TASK_REQUEST + VERIFY_CHECKLIST を生成します。「精密な Query」で洗練される段階。

→

STEP 03 / EXECUTE

Execute

/Qatomic-run

Haiku Teammates で並列 Wave 実行。順序実行は /Qrun-task フォールバック。

→

STEP 04 / VERIFY

Verify

/Qcode-run-task

Test → Review → Fix 品質ループ。合格するまで反復。

💡 各段階の エンジン(Claude / Codex)とモデルは /Qsivs-configで自由に変更可能 — 既定値は上述の通りですが、どの段階でも別のエンジン・モデルに置き換えられます。

Layer Architecture — 6-Layer Stack

SYSTEM STRUCTURE

フレームワークは 6 つのレイヤーで構成。上(User)ほどユーザー可視領域、下(Engine Bridge)ほど実行基盤。レイヤー間の通信はアーティファクト(ファイル)経由のみです。

フレームワークは明確な 6 つのレイヤーに分離されます。上レイヤー(User)ほどユーザー可視領域、下レイヤー(Engine Bridge)ほど実行基盤。各レイヤーは自身の責務のみを持ち、隣接するレイヤーと アーティファクト(ファイル)経由でのみ通信します。

LAYER 01 · INTERFACE
User Interfaceユーザーが直接呼び出すエントリーポイント。スラッシュコマンド(/Qplan, /Qgs…)と PSE Chain ユーザー動線。プロンプト文脈、CLAUDE.md、セッション入力がこのレイヤーに属します。
CLAUDE.md · prompts · /Q* commands
LAYER 02 · SKILLS
Skill Library165 以上の自己完結スキル定義。各スキルは Role / Workflow / Handoff を含む Markdown。ユーザーコマンドがスキルにルーティングされて実行計画が確立されますが、実装はエージェントに委任されます。
skills/**/SKILL.md
LAYER 03 · AGENTS
Agent Fleet21 個のバックグラウンドエージェント(E*)。Teammate(Haiku)・Executor(Sonnet)・Supervisor(Sonnet/Opus)の 3 層責務分離。スキルが委任する実行主体。
agents/E*.md
LAYER 04 · HOOKS
Hook System決定論的制御レイヤー。SessionStart・PreToolUse・PostToolUse・Stop などのイベントに自動応答してコンテキスト注入・権限ゲート・状態同期を実行。LLM 判断から独立したルールベース ゲート。
hooks/scripts/*.mjs
LAYER 05 · STATE
State & MemoryUnified State(.qe/state/unified-state.json)単一の真実の源 + Folder-Aware Context(.qe/context/)。すべてのフック・エージェントが 1 つのバージョンの状態を共有してレース条件を防止します。
.qe/state/ · .qe/context/ · .qe/tasks/
LAYER 06 · ENGINE
Engine BridgeSIVS 段階別エンジンルーティング抽象化。Claude を既定、オプションで codex-plugin-cc経由で Codex に委任。外部 SDK(OpenAI/Gemini)の直接呼び出しなし— 依存性隔離。
scripts/lib/codex_bridge.mjs

# レイヤー通信はアーティファクト経由 — スキルがエージェントを呼ぶときもファイル/状態経由
# フックはどのレイヤーも直接変更せず、状態レイヤーのみに書き込む (deterministic)

SIVS Loop & 3 大支柱

QUALITY GATE + SUPPORT SYSTEMS

SIVS は PSE パイプライン内で回る品質ゲート。Spec → Implement → Verify → Supervise 4 段階。Verify(できたか？)と Supervise(うまくできたか？)は異なる作業。FAIL なら REMEDIATION でループ再進入(最大 3 回)。

SIVS Loop — 品質ゲート

INSIDE STEPS 03 & 04

Spec

Implement

Verify

Supervise

→ PASS
完了 (Done)

→ FAIL
Remediate → Spec 再試行

# 核心: Supervise 段階が独立エンジンのとき「自己採点」問題を回避
# 各段階は Claude / Codex 中から自由にルーティング

CORE PRINCIPLE

"Work without a spec is guesswork.
A spec without implementation is intent.
Implementation without verification is hope.
Verification without supervision is confirmation bias."

SPEC → IMPLEMENT

TASK_REQUEST が実装の契約となる。契約なしに実行すると検証が不可能。

VERIFY ≠ SUPERVISE

Verify は「できたか？」(yes/no)、Supervise は「うまくできたか？」(security・quality・docs 専門評価)。

REMEDIATE

FAIL 時に即座修正ではなく 新しい spec(REMEDIATION_REQUEST)を作成してループ再進入。最大 3 回。

CROSS-PHASE

Phase N 完了前に Phase 1~N-1 の核心 VERIFY 項目を再検証。回帰防止ゲート。

PILLAR 01

Context Memory Manager

フォルダ別にコンテキストを分割して作業ディレクトリとマッチするものだけをロード。単一 CLAUDE.md の代わりに .qe/context/ 下に分散。

コンテキストトークン節約

PILLAR 02

SIVS Loop Engine

Spec → Implement → Verify → Supervise。Multi-Engine ルーティングで自己採点を防止、Supervisor が PASS/FAIL を判定。

Claude ↔ Codex 独立ルーティング

PILLAR 03

Skills & Agents Library

165 Skills (Q*, M*, coding-experts) + 21 Agents (E*)。状況に応じて注入される専門知識 + 実行主体。

165 skills · 21 agents · 71 experts

Design Philosophies — 5 公理

FOUNDATIONAL AXIOMS

すべてのスキル・エージェント・フックが従う 5 公理 + 5 義務。核心: 「トークン浪費はドリフト」、「並列が基本、順次はフォールバック」、「Spec なしで実行禁止」。

SIVS ループの外にも、フレームワーク全体に浸透した 5 つの公理。すべてのスキル・エージェント・フックはこの公理に反する場合、Ttuneで修正されます。

AXIOM 01

Efficiency = Accuracy

トークン浪費は単なるコストではなく ドリフトの根源です。不要な I/O・重複読み込みはモデルの集中力を散らし、間違った判断を招きます。

適用: ContextMemo · Semantic Compression · 140k/170k 圧縮ゲート

AXIOM 02

Parallel-First

2 つのタスク間にデータ依存関係がなければ基本は並列。順次は依存関係が明示されるときのみフォールバック。デフォルトを反転させるとラウンドトリップ時間が短縮されます。

適用: Haiku Wave · マルチ UUID Qrun-task · 同時 Test+Review

AXIOM 03

Spec-First

Spec なしの実行は推測です。リクエストが曖昧なら、まず TASK_REQUEST を作成してから実行に移行。緊急リクエストでも最小限の契約を要求。

適用: Qplan → Qgs 強制順序 · Pre-execution Gate

AXIOM 04

Minimal Change

リクエストされた範囲のみを変更。周辺コードの「見栄えよく」リファクタリング禁止。バグ修正は修正のみ、1 つのタスクは 1 つの目的のみ。

適用: Qcommit アトミック分割 · レビューア境界監査

AXIOM 05

Evidence-Based

推測しない。不確実なら、ファイルを読んで確認。「あるはずだ」ではなく「line 42 にある」。メモリ・キャッシュの主張も現在の状態と対照。

適用: grep・Read 事前確認 · VERIFY_CHECKLIST yes/no 厳密判定

▸ MANDATORY OBLIGATIONS (5) — 展開

Respect the spec — TASK_REQUEST なしで実行禁止。なければ最初に生成。
Do not skip verification — VERIFY_CHECKLIST 未完了状態で complete 禁止。
Parallel first — 依存なしの 2 つのタスクは必ず並列で。
Remediation is a new spec — ad-hoc 修正禁止、REMEDIATION_REQUEST 生成。
The loop is the product — 機能・スキル・エージェントは手段、spec→実装→検証ループが目的。

Multi-Engine Routing

/Qsivs-config

SIVS 4 段階それぞれを Claude または Codex に独立割り当て可能。同一エンジンが自己結果を採点する「自己評価バイアス」を回避。既定値はすべて Claude。

SIVS の各段階(Spec/Implement/Verify/Supervise)に Claude または Codex を独立割り当て。同一エンジンが自己結果を採点する問題を回避。

SPEC

Claude

or Codex

IMPLEMENT

Codex

or Claude

VERIFY

Claude

or Codex

SUPERVISE

Codex

or Claude

$ /Qsivs-config implement codex --effort high
$ /Qsivs-config set --all claude # 既定値復元

Folder-Aware Context Memory

.qe/context/

プロジェクトコンテキストをフォルダ別に分割保存。作業ディレクトリとマッチするファイルのみ自動ロード — 単一 CLAUDE.md 方式対比でコンテキストトークン節約（プロジェクトにより異なる、docs/BENCHMARK.md で測定）。

# 作業位置: src/frontend/components/Button.tsx
.qe/context/
├── _registry.json      # フォルダ ↔ コンテキストマッピング
├── root.md             # 常時ロード (プロジェクト全体ルール)
├── frontend.md          # ✔ src/frontend/** マッチ → ロード
├── backend.md           # ✘ スキップ
└── scripts.md           # ✘ スキップ
RESULT → fewer context tokens (varies by project)

Skill Library — 165 Skills

Q* + M* + coding-experts

165 以上のスキルを 12 カテゴリに分類。PSE Core、Meta、PM、Docs/Writing、Coding Experts(71 名)、QA/Testing、Data/Analysis など。各スキルは frontmatter + Role + Workflow + Handoff の 4-part 標準。

Backend

Django, FastAPI, Spring, Rails, NestJS…

Frontend

React, Vue, Next.js, Flutter, Angular…

Languages

Python, Rust, Go, TS, Kotlin, Swift…

Infra

K8s, Terraform, AWS, CI/CD, SRE…

Quality

Code review, security, debugging, E2E…

Data/ML

RAG, fine-tuning, ML pipelines, Spark…

Core Q-Skills · 主要コマンド

/Qinit 初期化
/Qplan 計画
/Qgs スペック生成
/Qatomic-run 並列実行
/Qrun-task 順次実行
/Qcode-run-task 検証
/Qcontext コンテキスト
/Qsivs-config ルーティング
/Qrefresh 更新
/Qmemory メモリ
/Qcompact 圧縮
/Qcommit コミット
/Qbranch ブランチ
/Qarchive アーカイブ
/Qmap-codebase マップ
/Qpm-prd PRD
/Qpm-roadmap ロードマップ
/Qpm-okr OKR
/Qfact-checker 검증
/Qdocx ドキュメント
/Qpptx スライド
/Qxlsx テーブル
/Qfind-skills 検索
/Qhelp ヘルプ

SKILL CATEGORIES — 12 クラスター

165 以上のスキルを役割別に 12 個カテゴリに分類。各カテゴリは 1 つの ユーザー意図パターンに対応し、IntentGate が意図→カテゴリ→スキルパスでルーティングします。

① PSE Core

ユーザーワークフロー 4 段階 — 企画・スペック・実行・検証の骨組み。

/Qplan · /Qgs · /Qatomic-run · /Qcode-run-task

② Meta (M*)

フレームワーク自体を管理 — バージョン・スキル生成・監査・テスト。

/Mbump · /Mcreate-skill · /Mqe-audit · /Mtest-skill

③ PM / Strategy

プロダクト・戦略ドキュメント — PRD、OKR、ロードマップ、レトロ、GTM。

/Qpm-prd · /Qpm-okr · /Qpm-roadmap · /Qpm-retro

④ Docs / Writing

ドキュメント・メール・論文・プレゼンテーション作成と精製。

/Qdocx · /Qpptx · /Qwriting-clearly · /Qdoc-comment

⑤ Coding Experts

言語・フレームワーク別ベストプラクティス 71 専門家 (Java・Go・Rust…)。

Qjava-specialist · Qreact · Qfastapi · Qkotlin…

⑥ QA / Testing

テスト計画・シナリオ・回帰・セキュリティ・ビジュアル QA。

/Qqa-test-planner · /Qscenario-test · /Qvisual-qa

⑦ Data / Analysis

データ探索・統計・金融分析・DB スキーマ設計。

/Qdata-analysis · /Qfinance-analyst · /Qdatabase-schema-designer

⑧ Research / Content

深掘りリサーチ・事実検証・出典検証・コンテンツ作成。

Edeep-researcher · /Qfact-checker · /Qsource-verifier

⑨ Dev Env / Integration

MCP 設定・Chrome・Stitch・Codex 連携・シークレット管理。

/Qmcp-setup · /Qchrome · /Qstitch-cli · /Qsecret

⑩ Browser / UI

ブラウザ自動化・UI デザイン・スタイル監査・ビジュアルリデザイン。

/Qagent-browser · /Qfrontend-design · /Qdesign-audit

⑪ Academic / Thesis

論文作成・レビュー応答・研究計画・セミナー準備。

/Qgrad-paper-write · /Qgrad-paper-review · /Qgrad-research-plan

⑫ Utility / Flow

セッション管理・コンテキスト・引き継ぎ・整理・自動化ループ。

/Qcompact · /Qresume · /Qcommit · /Qcron · /Qutopia ⚠

SKILL COMPOSITION

1 つの SKILL.md はどのような構成になっているか

すべてのスキルは同じ 4-part 構造に従います。この標準のおかげで、新しいスキルを /Mcreate-skillで自動生成でき、ルーティング・実行エンジンがどのスキルでも同じパターンで処理できます。

PART 01 — FRONTMATTER (YAML)

---
name: Qexample
description: One-line description. Use when user says "keyword1", "keyword2".
recommendedModel: sonnet         # haiku | sonnet | opus
invocation_trigger: When to invoke. Typical user phrasing.
---

PART 02 — ROLE (1 段落)

# Skill Name

## Role
You are [X]. Your job is to [Y]. [Z constraint].
Match the [action] to the [context], not the other way around.

PART 03 — WORKFLOW (Steps)

## Workflow

### Step 1: [Discovery / Context Acquisition]
- 何を読んで何を決めるか

### Step 2: [Draft / Execute]
- 実際の作業 (ファイル作成・分析・リネーム など)

### Step 3: [Verification / Approval]
- AskUserQuestion でユーザー確認 (MANDATORY)

### Step N: [Handoff]
- 次のスキルに渡す標準フォーマット

PART 04 — HANDOFF (응답 마지막 블록)

Phase {X}: {PhaseName} — Complete

Roadmap
  [x] Phase 1: {Name1}
  [>] Phase {X+1}: {NextName}

PSE: [x] Plan [x] Spec [x] Execute [x] Complete

次: /Qgs Phase {X+1}: {短いエイリアス}

# Handoff がなければスキル実行失敗と見なす — ユーザーが次の段階に進めない
# 短いエイリアスのみ許可、Phase 全体説明のコピー禁止 (feedback_handoff_brevity ルール)

Agent Fleet & Model Tiering

21 AGENTS · 3 TIERS

21 個のバックグラウンドエージェント(E* プレフィックス) + 3 モデルティア — Haiku(高速・並列)、Sonnet(バランス・実装)、Opus(深さ・戦略)。Delegation Enforcer フックが用途に合ったモデルを自動注入。

Agent Fleet · E* Agents (21)

Etask-executor — 複雑なチェックリスト実行
Eqa-orchestrator — テスト・レビュー・修正ループ
Esupervision-orchestrator — ドメイン監督者ルーティング
Ecode-reviewer — コードレビュー
Ecode-test-engineer — テスト作成
Ecommit-executor — AI 痕跡なしコミット
Erefresh-executor — プロジェクト分析・コンテキスト更新
Edeep-researcher — マルチソースリサーチ
Esecurity-officer — diff セキュリティ監査
Ecompact-executor — コンテキストウィンドウ管理
Epm-planner — PRD・ロードマップ・ドキュメント
+ 10 more — アーカイビング・プロファイリング・ハンドオフ…

TIER 01 · FAST

Haiku

シンプル・並列タスク

Wave Teammates
アーカイビング / データ更新

TIER 02 · BALANCED

Sonnet

コード実装

Etask-executor
Ecode-reviewer

TIER 03 · DEEP

Opus

戦略・アーキテクチャ

/Qplan
Edeep-researcher

# Delegation Enforcer が pre-tool-use フックで正しいモデルを自動注入
# トークン圧迫時: 140k → Ecompact-executor トリガー、170k → 強制圧縮

Hook System — 決定論的制御レイヤー

DETERMINISTIC CONTROL

9 種のイベントフック(SessionStart・PreToolUse・PostToolUse・Stop など)で LLM 判断から独立したゲート提供 — コンテキスト注入・権限チェック・状態同期・圧縮トリガーを決定論的に処理。

フックは Claude ライフサイクルの 決定論的実行ポイント — プロンプトが「提案」ならフックは「強制」です。

モデルルーティング — Delegation Enforcer がエージェント別 recommendedModel 自動注入
重複 I/O ブロック — ContextMemo で同じファイル再読み込みを防止
自動圧縮 — 140k トークン突破時 Ecompact トリガー、170k で強制
パイプライン持続性 — Stop 時にタスク状態保存、再開時に続行

SESSION LIFECYCLE

▶ SessionStart

QE: _registry.json ロード
フォルダコンテキスト注入

│

↺ Main Loop

(오른쪽 상세 참조)

│

📦 PreCompact

QE: 140k → Ecompact
170k → 強制圧縮

│

⏹ SessionEnd

QE: タスク記録 / アーカイブ

MAIN CONVERSATION LOOP

📝 HOOK

UserPromptSubmit

ユーザープロンプト受信 · 前処理注入可能

↓

Claude 判断

回答生成 or Tool 呼び出し決定

↓

🔁 TOOL EXECUTION LOOP · Tool 使用毎に反復

① HOOK

PreToolUse

Delegation Enforcer · ContextMemo · Security Gate

↓

② RUN

Tool 実行

Bash · Edit · Write · Read · Grep · Task

↓

③ HOOK

PostToolUse

監査ログ · 自動フォーマット · リント

↺ 結果が Claude コンテキストに返却 → 必要なら ①から再開

↓

🛑 HOOK

Stop

Persistent Mode がパイプライン中断をブロック

EXIT CODE プロトコル

exit 0

成功 — 継続進行。
stdout の JSON があれば解析され、allow / additionalContext 注入に使用。

exit 2

決定論的 BLOCK。
stderr メッセージを Claude に返却。ContextMemo が重複読み込みをブロックするときこの方法。

exit N

その他エラー — non-blocking。
verbose モードのみ stderr 表示、実行は継続。

# Hooks run with user permissions
# No sandbox — スクリプトは注意深く

QE Framework 特殊フック · What happens at each point

フック名	イベント	動作	結果
Delegation Enforcer	PreToolUse	タスク種に合ったモデル(Haiku / Sonnet / Opus)を自動注入。例: /Qplan は Opus で、Wave Teammate は Haiku で。	inject · exit 0
ContextMemo	PreToolUse (Read)	既に読んだファイルを重複して再度読もうとするとフックレベルでブロック。トークン浪費を防止。	BLOCK · exit 2
Folder Context Loader	SessionStart	作業ディレクトリと .qe/context/_registry.json をマッチング、root.md + 対象フォルダコンテキストのみを注入。	inject ctx · exit 0
Auto-compaction Trigger	PreCompact	140k トークン到達時 Ecompact-executor 自動呼び出し、170k 超過時に強制圧縮実行。	spawn agent
Persistent Mode	Stop	PSE Chain 進行中なら Claude が途中で応答終了するのをブロック。SIVS Loop 終了まで実行強制。	BLOCK · exit 2
Commit Trace Cleaner	PreToolUse (Bash: git commit)	Ecommit-executor と連携 — コミットメッセージの AI 痕跡削除、規約準拠検査。	allow / deny
Context Refresh Guard	PostToolUse (Edit/Write)	ファイル修正後、対象フォルダコンテキストの staleness チェック、必要時 /Qrefresh トリガー。	trigger
Security Gate	PreToolUse (Bash)	rm -rf /、force push to main、curl \| sh など危険パターンハードブロック。	BLOCK · exit 2

End-to-End Flow — 1 回の質問が回る経路

USER QUERY → FINAL RESPONSE

1 つのユーザークエリがフレームワークの 6 レイヤーをどのように通過するか全体経路スナップショット — プロンプト受信から最終応答まで、どのフック・スキル・エージェントがいつ介入するか一目瞭然。

ユーザーが 1 行入力して検証済み応答を受け取るまで、Context・Hook・PSE Chain・SIVS Loop が 実際にどの順序で組み合わさり回るかを 1 枚のフローチャートに整理。分岐(◆)で経路が分かれ、失敗時は前段階にループバックされます。

MAIN 段階

HOOK 介入

CONTEXT 状態

分岐 / 判定

━ 実線: 実行 · ┄ 点線: 参照/ループバック

💡 ダイアグラムの "既定 Opus/Sonnet/Haiku"はデフォルトのみ — 各 PSE 段階のエンジン(Claude/Codex)とモデルは /Qsivs-configでいつでも再ルーティング可能。

flowchart TD USER["👤 USER
バグを修正してください"]:::terminal H_PROMPT["UserPromptSubmit フック"]:::hook H_SESSION["SessionStart フック"]:::hook H_PRE["PreToolUse フック
· Delegation Enforcer
· ContextMemo
· Security Gate"]:::hook H_POST["PostToolUse フック
· 監査ログ · 自動フォーマット"]:::hook H_COMPACT["PreCompact フック"]:::hook H_STOP["Stop フック"]:::hook H_END["SessionEnd フック"]:::hook C_CTX["フォルダコンテキスト
root.md + folder.md
マッチしたコンテキストのみ"]:::ctx C_MEMO["読んだファイルキャッシュ"]:::ctx C_TOKEN["トークン使用量モニター"]:::ctx SUBMIT["プロンプト受信"]:::main CTXLOAD["Folder Context Loader
作業フォルダマッチロード"]:::main CLAUDE["Claude 処理開始"]:::main PLAN["① Plan · /Qplan
既定 Opus"]:::main SPEC["② Spec · /Qgs
既定 Sonnet"]:::main EXEC["③ Execute · /Qatomic-run
既定 Haiku Wave"]:::main VERIFY["④ Verify · /Qcode-run-task
既定 Sonnet"]:::main TCALL["Tool Call 発生
Bash · Edit · Write · Read"]:::main CHECK{"重複セキュリティリスク
ブロック必要？"}:::decision BLOCK["exit 2 BLOCK
Claude に理由を返却"]:::block TEXEC["Tool 実行"]:::main POSTLOG["結果処理
監査ログ · フォーマット"]:::main SIVS{"SIVS 判定"}:::decision TOKEN{"トークン閾値？"}:::decision COMPACT["Ecompact-executor
自動圧縮実行"]:::main STOP{"Stop 試行
パイプライン進行中？"}:::decision PERSIST["Persistent Mode BLOCK"]:::block ARCHIVE["セッションアーカイブ
コンテキスト保存"]:::main RESULT["✅ 検証済み応答
バグ修正 + テスト + レビュー完了"]:::terminal USER --> SUBMIT H_PROMPT -.-> SUBMIT SUBMIT --> CTXLOAD H_SESSION -.-> CTXLOAD C_CTX -.-> CTXLOAD CTXLOAD --> CLAUDE CLAUDE --> PLAN PLAN --> SPEC SPEC --> EXEC EXEC -->|Tool 必要| TCALL H_PRE -.-> TCALL C_MEMO -.-> CHECK TCALL --> CHECK CHECK -->|YES ブロック| BLOCK CHECK -->|NO 通過| TEXEC TEXEC --> POSTLOG H_POST -.-> POSTLOG POSTLOG -.->|次 Tool Call| TCALL POSTLOG --> VERIFY BLOCK --> VERIFY VERIFY --> SIVS SIVS -->|FAIL Remediate| SPEC SIVS -->|PASS| TOKEN C_TOKEN -.-> TOKEN TOKEN -->|140k 以上自動| COMPACT TOKEN -->|170k 以上強制| COMPACT TOKEN -->|140k 未満| STOP H_COMPACT -.-> COMPACT COMPACT --> STOP H_STOP -.-> STOP STOP -->|進行中| PERSIST PERSIST -.->|継続実行| EXEC STOP -->|完了| ARCHIVE H_END -.-> ARCHIVE ARCHIVE --> RESULT classDef main fill:#18212d,stroke:#3a4a60,stroke-width:1px,color:#dce4ef classDef hook fill:#2a1d08,stroke:#fbbf24,stroke-width:1px,color:#fbbf24 classDef ctx fill:#0a1e2a,stroke:#7dd3fc,stroke-width:1px,color:#7dd3fc classDef decision fill:#2a0e20,stroke:#f472b6,stroke-width:1.5px,color:#f472b6 classDef terminal fill:#0a2a1d,stroke:#6ee7b7,stroke-width:2px,color:#6ee7b7 classDef block fill:#2a0e14,stroke:#fb7185,stroke-width:1px,color:#fb7185

CONTEXT

フォルダ別選択ロード
読んだファイルキャッシュ
トークン自動圧縮

HOOKS (7)

SessionStart · End
Pre·PostToolUse
PreCompact · Stop

PIPELINE

Plan → Spec
Execute → Verify
(+ Inner Tool Loop)

DECISIONS (4)

Tool ブロック
SIVS PASS/FAIL
トークン閾値 · Stop