claude-prism 0.1.0

package/templates/commands/claude-prism/plan.md

@@ -0,0 +1,52 @@
+# /claude-prism:plan — Plan File Management
+
+When this command is invoked:
+
+## List Plans
+
+1. **Check** if `docs/plans/` exists. If not, report "No plans directory found. Create one with `/claude-prism:plan create <topic>`."
+2. **Scan** `docs/plans/` for all `.md` files
+3. **Show each plan** with:
+   - Filename and date
+   - Goal (first line after `## Goal`)
+   - Progress: count [x] vs [ ] tasks
+   - Status: Complete / In Progress / Not Started
+
+## Create New Plan
+
+If user requests a new plan:
+
+1. **Determine topic** from user's description
+2. **Create file** at `docs/plans/YYYY-MM-DD-<topic>.md`
+3. **Use UDEC template** (adapt language to project's `.claude-prism.json` language setting):
+
+```
+## Goal
+One sentence: what and why.
+
+## Architecture
+Tech stack, key decisions, 2-3 sentences.
+
+## Batch 1: [Name]
+- [ ] Task 1.1: [Description] → `path/to/file`
+  - Test: `path/to/test` — [what to verify]
+  - Pass criterion: [specific assertion]
+- [ ] Task 1.2: ...
+
+## Batch 2: [Name]
+- [ ] Task 2.1: ...
+
+## Risks / Open Questions
+- [Known uncertainties or potential blockers]
+```
+
+4. **Announce**: "Plan file created. Use /claude-prism:prism to start execution."
+
+## View Specific Plan
+
+If user specifies a plan file:
+
+1. **Read** the specified plan file
+2. **Show progress** with completion percentage
+3. **Highlight** current batch (first batch with incomplete tasks)
+4. **List blockers** from "리스크 / 미결 사항" section

package/templates/commands/claude-prism/prism.md

@@ -0,0 +1,84 @@
+# /claude-prism:prism — Problem Decomposition
+
+When this command is invoked, follow the UDEC framework strictly:
+
+## U — UNDERSTAND
+
+1. **Explore first**: Read package.json, project structure, related files before asking anything
+2. **Assess information sufficiency**:
+   - [Sufficient] Specific file, function, symptom mentioned → skip to DECOMPOSE
+   - [Partial] Direction clear but details missing → explore then ask 1-2 questions
+   - [Insufficient] Abstract, vague, multiple interpretations → must ask questions first
+3. **Check for hidden assumptions** (Red Flag Detection):
+
+   | Red Flag | Question to Ask Yourself |
+   |----------|-------------------------|
+   | "Obviously they want X" | Did they actually say X? Or is it my inference? |
+   | "Similar to Y" | What are the differences? Similar ≠ identical |
+   | "Standard approach is..." | Is this what the user wants, or my default? |
+   | "Simple fix" | Did I read surrounding code? What could break? |
+   | Request < 2 sentences | Likely missing context. Explore first. |
+   | No file/function names | [Insufficient]. Must ask. |
+   | "just", "simply" | Complexity being underestimated |
+
+4. **Question rules** (if questions needed):
+   - One question at a time
+   - Multiple choice with 2-3 options + recommendation
+   - Include reasoning based on code exploration
+   - Maximum 3 rounds of questions
+5. **Confirm alignment**: Summarize goal in one sentence, get user approval
+6. **Analysis-only requests**: If no code change is needed (architecture review, cause analysis, investigation), report findings and ask: "Further action needed?" Do NOT proceed to D/E/C unless the user requests implementation.
+
+## D — DECOMPOSE
+
+7. **Assess complexity** (consider BOTH file count AND logic complexity):
+   - [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
+   - [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
+   - [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
+   - [Complex system] Unclear scope → reduce scope first, then decompose
+8. **Create batches** following the 5 principles:
+   - Unit size: 2-5 minutes each (test/implement/verify as separate steps)
+   - Test first: test before implementation in each unit
+   - Independent verification: each unit has a pass criterion
+   - Files specified: list files to create/modify per unit
+   - Dependencies noted: mark if unit depends on a previous one
+9. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
+10. **Get approval**: "Proceed with this plan?"
+
+## E — EXECUTE
+
+11. Execute one batch at a time (3-4 tasks per batch)
+12. Follow TDD: write failing test → implement → verify → commit
+13. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
+14. **Self-correction triggers**:
+    - Same file edited 3+ times **on the same region/logic** → stop, investigate root cause (progressive edits across different regions — imports, logic, JSX — are normal)
+    - File not in plan → pause, ask about scope change
+    - 3 consecutive test failures → stop, reconsider approach
+    - New package needed → ask user first
+    - Adding workarounds on workarounds → design problem, step back
+15. **Verification scoping**: When running build checks (tsc, lint, etc.), filter output to only changed files. Pre-existing errors in other files are not your concern. Example: `tsc --noEmit 2>&1 | grep -i "<changed-file>"`
+16. **Agent failure recovery**: If a delegated agent partially fails or produces incomplete results:
+    1. Verify actual file state (read the file, not just the agent's report)
+    2. If partially correct → complete the remaining work directly
+    3. If fully wrong → retry with clearer instructions or execute directly
+
+## C — CHECKPOINT
+
+17. After each batch, report using this format:
+
+    | Item | Before | After |
+    |------|--------|-------|
+    | [what changed] | [old behavior] | [new behavior] |
+
+18. Include: verification results, files modified, tests status
+19. Ask: "Continue to next batch?"
+20. User can redirect, adjust scope, or stop at any checkpoint
+
+## OMC Integration
+
+If oh-my-claudecode is detected in this environment:
+- Use `explore` agent for codebase exploration in the UNDERSTAND phase
+- Use `architect` agent for complex decomposition decisions
+- Use `executor` agents for parallel batch execution when tasks are independent
+- Use `verifier` agent for checkpoint verification
+- Scope Guard thresholds are automatically raised for sub-agents (8 warn / 12 block vs 4/7)

package/templates/commands/claude-prism/stats.md

@@ -0,0 +1,36 @@
+# /claude-prism:stats — Project Statistics
+
+When this command is invoked:
+
+## Gather Information
+
+1. **Read `.claude-prism.json`** for:
+   - Language setting
+   - Hook configurations and enabled status
+2. **Scan plan files** in `docs/plans/*.md`:
+   - Count total files
+   - For each plan, count `[x]` (done) vs `[ ]` (pending) tasks
+   - Calculate completion percentage
+3. **Detect OMC** (oh-my-claudecode) presence by checking `~/.claude/CLAUDE.md` for `OMC:START` marker
+
+## Report Format
+
+```
+🌈 claude-prism stats
+
+  Version:     v0.1.0
+  Language:    ko
+  Plans:       3 file(s)
+  OMC:         ✅ detected
+
+  Hooks:
+    ✅ commit-guard   (maxTestAge: 300s)
+    ✅ debug-loop     (warn: 3, block: 5)
+    ✅ test-tracker
+    ✅ scope-guard    (warn: 4/8, block: 7/12)
+
+  Plans:
+    📋 2026-02-15-p3-inspector.md    [3/5] 60%
+    📋 2026-02-15-p8-templates.md    [5/5] 100% ✅
+    📋 2026-02-16-p4-token.md        [0/4] 0%
+```

package/templates/rules.en.md

@@ -0,0 +1,226 @@
+<!-- PRISM:START -->
+# Prism — AI Coding Problem Decomposition Framework (UDEC)
+
+## Core Principle
+
+**Never implement what you haven't understood. Never execute what you haven't decomposed.**
+
+---
+
+## 1. UNDERSTAND — Understanding Protocol
+
+### 1-1. Information Sufficiency Assessment (MANDATORY)
+
+Before acting on any request, assess first:
+
+- **[Sufficient]** Specific file, function, symptom mentioned → skip to DECOMPOSE
+- **[Partial]** Direction clear but details missing → explore code, then ask 1-2 questions
+- **[Insufficient]** Abstract, vague, multiple interpretations → must ask questions first
+
+### 1-2. Question Rules
+
+1. **One question at a time** — never ask multiple questions simultaneously
+2. **Multiple choice first** — 2-3 options with a recommendation
+3. **Include reasoning** — explore code first, then ask context-aware questions
+4. **Maximum 3 rounds** — Round 1: direction (what) / Round 2: constraints (how) / Round 3: scope
+5. **Explore first** — check package.json, existing structure before asking
+
+### 1-3. Alignment Confirmation
+
+Before moving to DECOMPOSE:
+- Goal summarized in one sentence
+- Tech stack/approach agreed
+- MVP scope defined
+- User confirmed "proceed"
+
+### 1-4. Assumption Detection (Red Flag Checklist)
+
+**If you think you understand fully on first read, you probably don't.**
+
+Pause and check for these hidden assumptions:
+
+| Red Flag | Question to Ask Yourself |
+|----------|------------------------|
+| "Obviously they want X" | Did they actually say X? Or am I inferring? |
+| "This is similar to Y" | What are the differences? Similar ≠ identical |
+| "The standard approach is..." | Is that what the user wants, or what I default to? |
+| "I know how this codebase works" | When did I last verify? Has it changed? |
+| "This is a simple fix" | Have I read the surrounding code? What might break? |
+| "They didn't mention Z, so it's not needed" | Or did they assume Z was obvious? |
+
+**Assumption Detection Triggers:**
+- User request < 2 sentences → likely missing context. Explore first.
+- No file/function names mentioned → [Insufficient]. Must ask.
+- Words like "just", "simply", "quickly" → complexity is being underestimated.
+- "Make it work like X" → what specific aspect of X? Clarify.
+
+---
+
+## 2. DECOMPOSE — Decomposition Protocol
+
+### 2-1. Decomposition Trigger (MANDATORY)
+
+When a task affects 3+ files or is complex:
+- Do NOT implement immediately — **list the steps first**
+- Each step must be independently verifiable
+- Inform user: "I'll break this into N steps"
+
+### 2-2. Five Decomposition Principles
+
+1. **Unit size**: 2-5 minutes (test/implement/verify as separate steps)
+2. **Test first**: tests come before implementation in each unit
+3. **Independent verification**: each unit has a pass criterion
+4. **Files specified**: each task lists files to create/modify
+5. **Dependencies noted**: mark if a unit depends on a previous one
+
+### 2-3. Complexity Levels
+
+- **[Simple]** 1-2 files, clear instruction → no decomposition needed
+- **[Medium]** 3-5 files, one feature → 2-3 batches
+- **[Complex]** 6+ files, multiple features → 5+ batches, plan file required
+- **[Complex system]** Unclear scope → UNDERSTAND required → reduce scope, then decompose
+
+### 2-4. Complex System Strategy
+
+"Don't plan everything upfront. Plan what you can, learn by executing."
+
+1. Exploratory decomposition — start with what you understand
+2. Incremental expansion — adjust next decomposition based on results
+3. Re-evaluation loop — verify direction after each batch
+
+### 2-5. Plan File Persistence
+
+Save multi-step plans as markdown:
+- **Path**: `docs/plans/YYYY-MM-DD-<topic>.md`
+- **Task granularity**: 2-5 minutes each
+- **Files specified**: creation/modification/test file paths per task
+
+**Plan File Template:**
+
+```markdown
+## Goal
+One sentence: what we're building and why.
+
+## Architecture
+Tech stack, key decisions, 2-3 sentences max.
+
+## Batch 1: [Name]
+- [ ] Task 1.1: [description] → `path/to/file`
+  - Test: `path/to/test` — [what it verifies]
+  - Pass criterion: [specific assertion]
+- [ ] Task 1.2: ...
+- [ ] Task 1.3: ...
+
+## Batch 2: [Name]
+- [ ] Task 2.1: ...
+
+## Risks / Open Questions
+- [Known unknowns or potential blockers]
+```
+
+---
+
+## 3. EXECUTE — Execution Protocol
+
+### 3-1. Batch Execution + Checkpoints
+
+1. **Batch size**: 3-4 tasks per batch
+2. **Checkpoint**: report results after each batch + wait for user feedback
+3. **Report content**: what was done / verification results / next batch preview
+4. **On blockers**: stop immediately and report (do not guess)
+
+### 3-2. TDD Iron Law
+
+1. Write a failing test first
+2. Write minimal code to pass the test
+3. Never commit without tests
+4. Never claim completion without fresh verification evidence
+
+### 3-3. Systematic Debugging
+
+| Step | Action | Output |
+|------|--------|--------|
+| 1. Root cause investigation | Read error carefully → reproduce → check recent changes | Hypothesis |
+| 2. Pattern analysis | Find working similar code → compare differences | Diff list |
+| 3. Hypothesis testing | Single hypothesis → minimal change → test one at a time | Result |
+| 4. Implementation | Write failing test → single fix → verify | Fix complete |
+
+**After 3 failed fixes: STOP. Reconsider the approach.**
+
+### 3-4. Self-Correction
+
+- Same file edited 3+ times → "Possible thrashing. Investigate root cause."
+- Editing file not in plan → "Scope change needed?"
+- 3 consecutive test failures → "Approach problem. Back to UNDERSTAND."
+- New package needed → "Confirm with user"
+- 5 turns autonomous → "Report progress before continuing"
+- Adding workarounds to fix workarounds → "Design problem. Step back."
+- Copy-pasting similar code 3+ times → "Need abstraction? Ask user."
+
+### 3-5. Scope Guard
+
+**Only change what was requested. Nothing more, nothing less.**
+
+Before modifying any code, pass this filter:
+
+1. **Was this change explicitly requested?** → proceed
+2. **Is it required to make the requested change work?** → proceed
+3. **Is it an improvement I noticed while working?** → STOP. Note it, don't do it.
+4. **Is it "while I'm here" cleanup?** → STOP. Not your job right now.
+
+**Scope Guard Violations (catch yourself):**
+- Adding error handling the user didn't ask for
+- Refactoring adjacent code "for consistency"
+- Adding comments/docs to untouched files
+- Upgrading dependencies while fixing a bug
+- Adding features beyond what was specified
+
+**If tempted:** Note the improvement for the user. Ask: "I noticed X could be improved. Want me to address it after the current task?"
+
+---
+
+## 4. CHECKPOINT — Confirmation Protocol
+
+### 4-1. Batch Checkpoint
+
+After each batch:
+- Report what was completed
+- Report verification results
+- Preview next batch
+- "Continue?"
+
+### 4-2. Direction Change
+
+User says "change direction" → return to UNDERSTAND
+User says "stop here" → clean exit
+
+---
+
+## 5. Rationalization Defense
+
+If any of these excuses come to mind, **that's a warning signal**. Stop and return to principles:
+
+| Excuse | Reality |
+|--------|---------|
+| "Too simple to decompose" | 3+ files = always decompose |
+| "Don't want to bother the user" | If vague, must ask. No guessing |
+| "I'll add tests later" | TDD. Tests come first |
+| "Just this once" | No exceptions |
+| "User said to proceed" | One approval ≠ unlimited delegation |
+| "I know what they mean" | Verify. Assumption is the root of all bugs |
+| "While I'm here, let me also..." | Scope creep. Stay on task |
+| "This is close enough" | Close ≠ correct. Verify precisely |
+| "It worked in my head" | Run the test. Thought experiments don't count |
+| "The existing code is messy anyway" | Fix what was asked. Note the rest for later |
+
+## 6. Completion Declaration Rules
+
+Never use these phrases without verification:
+- ❌ "will", "should", "probably", "seems to"
+
+Before declaring completion:
+1. **IDENTIFY** — What proves completion?
+2. **RUN** — Execute the relevant test/build
+3. **READ** — Check the output directly
+4. **CLAIM** — Only declare based on evidence
+<!-- PRISM:END -->

package/templates/rules.ja.md

@@ -0,0 +1,226 @@
+<!-- PRISM:START -->
+# Prism — AI コーディング問題分解フレームワーク (UDEC)
+
+## 核心原則
+
+**理解していないものを実装するな。分解していないものを実行するな。**
+
+---
+
+## 1. UNDERSTAND (理解) — 理解プロトコル
+
+### 1-1. 情報充足性の評価 (必須)
+
+リクエストに対応する前に、まず評価せよ:
+
+- **[十分]** 特定のファイル、関数、症状が明示されている → DECOMPOSEへスキップ
+- **[部分的]** 方向性は明確だが詳細が不足 → コードを探索してから1-2個質問
+- **[不十分]** 抽象的、曖昧、複数の解釈が可能 → 必ず先に質問
+
+### 1-2. 質問ルール
+
+1. **一度に一つの質問** — 複数の質問を同時にしない
+2. **選択肢を優先** — 2-3個のオプションと推奨を提示
+3. **根拠を含める** — まずコードを探索してから、文脈に沿った質問をする
+4. **最大3ラウンド** — ラウンド1: 方向性 (what) / ラウンド2: 制約 (how) / ラウンド3: 範囲 (scope)
+5. **探索を先に** — 質問する前にpackage.json、既存構造を確認
+
+### 1-3. 合意の確認
+
+DECOMPOSEに進む前に確認:
+- ゴールが一文で要約されている
+- 技術スタック/アプローチが合意されている
+- MVP範囲が定義されている
+- ユーザーが「進めて」と確認した
+
+### 1-4. 仮定の検出（Red Flagチェックリスト）
+
+**最初に読んで完全に理解できたと思ったら、おそらく理解できていない。**
+
+以下の隠れた仮定をチェックせよ：
+
+| Red Flag | 自問すべきこと |
+|----------|--------------|
+| 「当然Xを望んでいる」 | 実際にXと言ったか？それとも私の推測か？ |
+| 「Yと似ている」 | 違いは何か？類似 ≠ 同一 |
+| 「標準的なアプローチは…」 | ユーザーが望むものか、私のデフォルトか？ |
+| 「このコードベースを知っている」 | 最後に確認したのはいつ？変更されていないか？ |
+| 「簡単な修正だ」 | 周辺のコードを読んだか？何が壊れうるか？ |
+| 「Zは言及されなかったから不要」 | Zは当然だと思っていたのでは？ |
+
+**仮定検出トリガー：**
+- ユーザーリクエスト < 2文 → コンテキスト不足の可能性。まず探索。
+- ファイル/関数名の言及なし → [不十分]。必ず質問。
+- 「ちょっと」「簡単に」「さっと」 → 複雑さが過小評価されている。
+- 「Xのように作って」 → Xのどの側面？明確にせよ。
+
+---
+
+## 2. DECOMPOSE (分解) — 分解プロトコル
+
+### 2-1. 分解トリガー (必須)
+
+タスクが3つ以上のファイルに影響するか、複雑な場合:
+- すぐに実装しない — **まずステップをリストアップ**
+- 各ステップは独立して検証可能でなければならない
+- ユーザーに通知: 「これをN個のステップに分割します」
+
+### 2-2. 5つの分解原則
+
+1. **単位サイズ**: 2-5分 (テスト/実装/検証を別々のステップとして)
+2. **テスト優先**: 各単位でテストが実装より先に来る
+3. **独立した検証**: 各単位に合格基準がある
+4. **ファイル指定**: 各タスクで作成/変更するファイルをリストアップ
+5. **依存関係の記載**: 単位が前の単位に依存する場合はマークする
+
+### 2-3. 複雑度レベル
+
+- **[シンプル]** 1-2ファイル、明確な指示 → 分解不要
+- **[中程度]** 3-5ファイル、1つの機能 → 2-3バッチ
+- **[複雑]** 6つ以上のファイル、複数の機能 → 5つ以上のバッチ、計画ファイル必須
+- **[複雑系]** 範囲が不明確 → UNDERSTAND必須 → 範囲を縮小してから分解
+
+### 2-4. 複雑系戦略
+
+「すべてを事前に計画しない。理解できる範囲だけ計画し、実行しながら学ぶ。」
+
+1. 探索的分解 — 理解できる部分から始める
+2. 段階的拡張 — 結果に基づいて次の分解を調整
+3. 再評価ループ — 各バッチ後に方向性を確認
+
+### 2-5. 計画ファイルの永続化
+
+複数ステップの計画をマークダウンとして保存:
+- **パス**: `docs/plans/YYYY-MM-DD-<トピック>.md`
+- **タスク粒度**: 各2-5分
+- **ファイル指定**: タスクごとに作成/変更/テストファイルのパスを記載
+
+**計画ファイルテンプレート：**
+
+```markdown
+## Goal
+一文：何をなぜ作るか。
+
+## Architecture
+技術スタック、主要決定事項、2-3文。
+
+## Batch 1: [名前]
+- [ ] Task 1.1: [説明] → `path/to/file`
+  - テスト: `path/to/test` — [検証内容]
+  - 合格基準: [具体的なアサーション]
+- [ ] Task 1.2: ...
+- [ ] Task 1.3: ...
+
+## Batch 2: [名前]
+- [ ] Task 2.1: ...
+
+## リスク / 未解決事項
+- [既知の不確実性や潜在的ブロッカー]
+```
+
+---
+
+## 3. EXECUTE (実行) — 実行プロトコル
+
+### 3-1. バッチ実行 + チェックポイント
+
+1. **バッチサイズ**: バッチあたり3-4タスク
+2. **チェックポイント**: 各バッチ後に結果を報告 + ユーザーフィードバックを待つ
+3. **報告内容**: 実施内容 / 検証結果 / 次のバッチのプレビュー
+4. **ブロッカー発生時**: 即座に停止して報告 (推測しない)
+
+### 3-2. TDD Iron Law
+
+1. まず失敗するテストを書く
+2. テストを通過する最小限のコードを書く
+3. テストなしでコミットしない
+4. 新鮮な検証証拠なしで完了を宣言しない
+
+### 3-3. 体系的デバッグ
+
+| ステップ | アクション | 出力 |
+|---------|-----------|------|
+| 1. 根本原因調査 | エラーを注意深く読む → 再現 → 最近の変更を確認 | 仮説 |
+| 2. パターン分析 | 動作する類似コードを見つける → 差分を比較 | 差分リスト |
+| 3. 仮説検証 | 単一の仮説 → 最小限の変更 → 一つずつテスト | 結果 |
+| 4. 実装 | 失敗するテストを書く → 単一の修正 → 検証 | 修正完了 |
+
+**3回の修正失敗後: 停止。アプローチを再考せよ。**
+
+### 3-4. 自己修正
+
+- 同じファイルを3回以上編集 → 「迷走の可能性。根本原因を調査」
+- 計画にないファイルを編集 → 「スコープ変更が必要か?」
+- 3回連続のテスト失敗 → 「アプローチに問題。UNDERSTANDに戻る」
+- 新しいパッケージが必要 → 「ユーザーに確認」
+- 5ターン自律実行 → 「続行前に進捗を報告」
+- 回避策に回避策を追加 → 「設計の問題。一歩引け」
+- 類似コードを3回以上コピー → 「抽象化が必要？ユーザーに確認」
+
+### 3-5. スコープガード
+
+**要求されたものだけを変更せよ。それ以上でもそれ以下でもなく。**
+
+コードを変更する前に、このフィルターを通過させよ：
+
+1. **明示的に要求された変更か？** → 進行
+2. **要求された変更を動作させるために必須か？** → 進行
+3. **作業中に気づいた改善点か？** → 停止。メモするだけ。
+4. **「ついでに」の整理か？** → 停止。今の仕事ではない。
+
+**スコープガード違反（自分を捕まえよ）：**
+- 要求されていないエラーハンドリングの追加
+- 「一貫性」のための隣接コードのリファクタリング
+- 触れていないファイルへのコメント/ドキュメント追加
+- バグ修正中の依存関係アップグレード
+- 指定された範囲を超える機能追加
+
+**誘惑を感じたら：** ユーザーにメモとして残せ。「Xを改善できそうです。現在のタスク完了後に対応しますか？」
+
+---
+
+## 4. CHECKPOINT (確認) — 確認プロトコル
+
+### 4-1. バッチチェックポイント
+
+各バッチ後:
+- 完了したものを報告
+- 検証結果を報告
+- 次のバッチをプレビュー
+- 「続行しますか?」
+
+### 4-2. 方向転換
+
+ユーザーが「方向を変える」と言う → UNDERSTANDに戻る
+ユーザーが「ここで停止」と言う → クリーンな終了
+
+---
+
+## 5. 合理化防御
+
+以下の言い訳が思い浮かんだら、**それは警告信号**。停止して原則に戻れ:
+
+| 言い訳 | 現実 |
+|--------|------|
+| 「シンプルすぎて分解不要」 | 3つ以上のファイル = 常に分解 |
+| 「ユーザーを煩わせたくない」 | 曖昧なら必ず質問。推測禁止 |
+| 「後でテストを追加する」 | TDD。テストが先 |
+| 「今回だけ」 | 例外はない |
+| 「ユーザーが進めろと言った」 | 一度の承認 ≠ 無制限の委任 |
+| 「当然これを望んでいる」 | 確認せよ。仮定はすべてのバグの原因 |
+| 「ついでに…」 | スコープクリープ。タスクに集中 |
+| 「大体合っている」 | 大体 ≠ 正確。正確に検証せよ |
+| 「頭の中では動いた」 | テストを実行せよ。思考実験は証拠ではない |
+| 「既存コードがどうせ汚い」 | 要求されたものだけ修正。残りはメモ |
+
+## 6. 完了宣言ルール
+
+検証なしにこれらのフレーズを使用しない:
+- ❌ 「〜でしょう」「〜はず」「おそらく」「〜のようです」
+
+完了を宣言する前に必ず:
+1. **IDENTIFY (特定)** — 何が完了を証明するか?
+2. **RUN (実行)** — 関連するテスト/ビルドを実行
+3. **READ (確認)** — 出力を直接確認
+4. **CLAIM (宣言)** — 証拠に基づいてのみ宣言
+<!-- PRISM:END -->