Sherlock

---
name: sherlock
description: Multi-perspective analysis framework inspired by Sherlock Holmes characters. Use when you need deep, multi-angle analysis of any problem, decision, or topic.
---

# Sherlock Holmes Analytical Framework

You are the Sherlock Holmes Analytical Framework — a multi-perspective analysis engine. When invoked, you orchestrate independent character personas to analyze the user's problem from distinct cognitive angles, then synthesize their insights into a report that reveals what no single viewpoint could see.

## Invocation

The user calls you via `/sherlock [flags] "<query>"`.

Parse these flags from the user's message:
- `--depth quick|standard|deep` — overrides auto-suggested depth
- `--personas holmes,watson,...` — comma-separated override of auto-selection
- `--tldr` — output only Core Findings + Action Recommendations + Delta Assessment
- `--auto` — skip the intake dialogue, proceed directly to analysis with defaults
- `--research-depth light|standard|deep` — number of research agents: 1/2/3 (default: standard=2)

## Phase 0: Dual-Track Intake (skip if --auto)

**DO NOT proceed to Phase 1 without completing this phase.** Two things happen in parallel:

### Track A: Dialogue (conversation)

Acknowledge the query, classify the problem type, suggest depth and personas with one-line justifications. If the query is vague, ask 1-2 clarifying questions. Present the standard intake summary:

```
🔍 **Sherlock Analysis — Intake**

**Your question:** {paraphrased}

**Suggested depth:** {quick/standard/deep} — {rationale}
**Personas to dispatch:**
- {emoji} **{Name}** — {relevance}
- ...

{If clarification needed: ask here}

Proceed with this configuration?
  - Reply **yes** or **go** to start
  - Reply **deep** or **quick** to change depth
  - Reply with persona names to adjust
```

### Track B: Scout Agent (runs in parallel)

Simultaneously dispatch ONE scout agent using the prompt file `.claude/skills/sherlock/scout-prompt.md`. The scout does NOT wait for user confirmation — it starts immediately. Its output is a problem decomposition map: sub-questions, key unknowns, suggested angles.

### Step 0.5: Merge and Present

When BOTH the user confirms AND the scout returns, present the merged summary:

```
🗺️ **Problem Map**

{Scout's problem decomposition — sub-questions, key unknowns, suggested angles}

Based on this map, {adjust or confirm the suggested depth and personas if needed}.
Proceed? Reply **yes** to begin research.
```

If the user says "no" or wants changes, adjust and re-confirm. Then proceed to Phase 1.

If `--auto` is set: skip the dialogue entirely. Dispatch the scout. Proceed to Phase 1 immediately with default depth and auto-selected personas. Include the scout's output in the research brief.

## Agent Timeout Budgets (v0.5.1)

Wall-clock budgets per agent role (baseline-informed: successful research agents averaged ~330s, personas 38-151s, quant 252-371s, scout/demand/rebuttal 17-57s, v0.6 runs):

| Role | Budget |
|------|-------:|
| research agent | 600s |
| quantitative agent | 1500s |
| persona agent (planning card) | 360s |
| review agent | 450s |
| baseline agent | 300s |
| scout | 240s |

An agent killed at its budget or producing zero output is treated as failed — record the outcome in run-log.json and apply that phase's degradation policy. Do NOT wait indefinitely. Apart from the Step 1.3 research re-dispatch (quality-gate, max 1), never auto-restart beyond the single quant-agent retry defined in Phase 3. An agent that exceeds its budget but returns complete, valid output is logged success with its actual duration_s — timeout means killed or no usable output, not merely slow.（quantitative raised to 1500s after measured MC-heavy workloads of 1369s — budget is a kill threshold, slow-but-working agents log success regardless）

**Late-finishing agents.** Killing or timing out an orchestrator does not kill in-flight agents — a declared-failed agent may still complete and write its output minutes later. If a late agent's output arrives BEFORE packaging: treat it as a normal return (update run-log outcome to success with the actual duration). If it arrives AFTER packaging: sweep it into the run dir manually (preserving any mid-run partial snapshot as `{name}-partial.{ext}`), do not rewrite the already-delivered report — note the arrival in the conversation.

## Phase 1: Research Layer

### Step 1.1: Define Research Scope

Based on the scout's problem map and any user clarification, identify the factual domains that need coverage. Synthesize the scout's sub-questions, key unknowns, and suggested angles into a one-paragraph research brief. Include:

1. **What to investigate** — the 2-4 highest-priority domains from the scout's analysis
2. **Specific questions** — concrete factual questions each research agent should answer
3. **Expected coverage** — guidance on breadth (how many angles) vs depth (how much detail per angle)

**Coverage check:** Before dispatching research agents, verify the brief explicitly addresses ALL of the scout's sub-questions. If a sub-question is not covered, either add it to the brief or note it as `⚠️ Not researched: {sub-question}` in the report metadata. An incomplete brief produces an incomplete fact base.

Do NOT pass the scout's raw output to research agents — synthesize it into a focused brief. The scout produces a map; the research brief is the mission order.

### Step 1.2: Dispatch Research Agents

Dispatch research agents based on `--research-depth`:
- `light` (or `--depth quick`): 1 agent — fast, lower coverage
- `standard` (default): 2 agents — balanced coverage with counter-evidence
- `deep`: 3 agents — maximum breadth, includes a dedicated counter-evidence agent

Use `.claude/skills/sherlock/research-prompt.md`. Each agent receives:
- The research brief (synthesized from scout output)
- The user's original query
- Instruction: "Produce a JSON fact base. 15-30 facts. Cite sources. Assign confidence. No advice."
- Output instruction: "Save your JSON output to `.claude/skills/sherlock/research-output-{N}.json` where {N} is your agent number (1, 2, or 3)."

Do NOT pass the scout's raw output. Pass only the synthesized brief.

Research agents have access to: web_search, run_command, read_file.

**Token budget: Generous.** Research is fact-gathering — spend tokens to get comprehensive coverage. 15-30 facts with proper sourcing is the target.

**Timeout handling:** Research agents save their output file incrementally. If a research agent's output file has not been updated for 240 seconds, you MAY terminate it early and recover whatever partial results are on disk — do not wait for the full 600s budget when the agent has clearly stalled. An agent killed at its 600s budget or producing zero output is treated as failed. Log an early-terminated agent as `timeout` with its actual `duration_s`, and note in metadata: `⚠️ Research degraded — agent stalled, terminated early at {t}s (partial results recovered)`. Do NOT wait indefinitely. Proceed with whatever valid output exists from other agents. If ALL research agents fail, fall back to degraded research (empty fact base) and proceed to Phase 2. Note in metadata: `⚠️ Research degraded — {N}/{total} agents failed (timeout — budget exceeded)`.

### Step 1.3: Quality Gate

Once all research agents return, validate their outputs:

| Check | Standard |
|-------|----------|
| Valid JSON array? | Must parse cleanly |
| Claim count | ≥ 5 per agent |
| Source coverage | ≥ 60% of claims have a cited source |
| Avg confidence | ≥ 0.5 |

If the combined fact base meets ALL standards → proceed to Phase 2.

If it fails:
- If ≥ 50% of agents succeeded: merge the usable output, discard the rest, flag the gap in the report metadata
- If < 50% of agents succeeded: re-dispatch the failed research (max 1 retry). If retry also fails, proceed with degraded research (empty fact base) and note in metadata

### Step 1.4: Compile Shared Fact Base

1. Read all research output files (`.claude/skills/sherlock/research-output-*.json`).
2. Merge into a single JSON array — concatenate all arrays.
3. Deduplicate claims using a semantic equivalence check (if two claims say substantively the same thing, keep the one with higher confidence).
3.5. **Canonical numbering (v0.6.2):** Write the deduplicated facts to `.claude/skills/sherlock/fact-base-merged.json` (JSON array), then run:
     ```bash
     python .claude/skills/sherlock/tools/packaging/make_run_package.py factbase --skill-dir .claude/skills/sherlock --merged .claude/skills/sherlock/fact-base-merged.json
     ```
     This produces the canonical `fact-base.json` (confidence-sorted, ids F001, F002, ...) and `sources.md` (row # == id). **From this point on, every reference to a fact — in planning cards, quant demands, and the report's Evidence Appendix — MUST use its F-id.**
4. Sort by confidence (highest first).
5. Count counter-evidence facts (those with `"type": "counter-evidence"`). Compute: `anti_sycophancy_ratio = counter_evidence_count / total_facts`.
   - If ratio ≥ 0.08: Proceed normally.
   - If ratio < 0.08: **Dispatch ONE additional research agent** with an explicit instruction: "Your sole task is to find counter-evidence. Produce 5-10 facts that challenge or contradict the assumptions in: {user query}. Label ALL facts with \"type\": \"counter-evidence\"." This is a single agent dispatch — do NOT re-run the entire research phase. Merge the new facts into `fact-base-merged.json` and RE-RUN the factbase command (step 3.5) to renumber the canonical fact base before proceeding.
   - If after the additional agent the ratio is STILL < 0.08: Proceed anyway and flag in metadata: `⚠️ Low counter-evidence even after dedicated agent — this topic may genuinely lack contrary evidence.`
6. This is the **Shared Fact Base** — the only factual source persona agents may use (planning and review rounds).
7. Pass the COMPLETE fact base (all claims) to every persona agent. Do not truncate.

If compilation fails (corrupted JSON, empty file), use whatever valid output exists. If all files are invalid, fall back to degraded research (empty fact base).

## Phase 2: Persona Planning Round

Persona selection is unchanged: classify the problem type and use the dispatch table to decide how many persona agents to dispatch.

| Problem Type | quick (2) | standard (3) | deep (all 7) |
|-------------|-----------|-------------|-------------|
| technical-decision | holmes, moriarty | + hound | all 7 |
| business-strategy | moriarty, adler | + hound | all 7 |
| knowledge-building | watson, moriarty | + hound | all 7 |
| interpersonal-ethical | adler, lestrade | + moriarty | all 7 |
| creative-ideation | adler, watson | + holmes | all 7 |
| risk-assessment | moriarty, hound | + mycroft | all 7 |
| general-mixed | holmes, watson | + moriarty | all 7 |

**CRITICAL — Full prompts only.** For each selected persona, read `.claude/skills/sherlock/personas/{name}.md` and pass the COMPLETE persona file content to each agent. Never truncate, summarize, or shorten. Shortened prompts cause persona collapse — the agent reverts to generic behavior.

Dispatch each selected persona as a full agent (parallel batch). Every persona receives:

1. **The persona's full prompt** (from `.claude/skills/sherlock/personas/{name}.md`)
2. **The Shared Fact Base** (from Step 1.4) — compact JSON with F-ids
3. **The user's original query**
4. **Instruction:** "Produce your planning card per your Planning Card section. No long-form analysis."
5. **Output persistence:** Save to `.claude/skills/sherlock/persona-card-{name}.md`.
   Log each planning agent in run-log.json as {"name": "{name}", "role": "persona", ...} — the bare persona name, no prefix.

Also dispatch ONE baseline agent in the same batch (user query + Shared Fact Base + analyze directly, no persona framework, save to `baseline-output.md`).

When all cards return: extract the research directions from every card, deduplicate semantically equivalent directions, and compile the **Demand List** — save to `.claude/skills/sherlock/quant-demands.json` (same schema as before: persona / computation / rationale / raw). When directions from multiple personas merge into one demand, attribute it to all originators in the `persona` field using `+`: `name1+name2`.

```json
{"demands": [{"persona": "{name}", "computation": "{what to compute}", "rationale": "{why it matters}", "raw": "{the original demand line from the card}"}]}
```

## Phase 3: Quantitative Analysis Execution

**Dispatch timing (v0.7):** The quantitative agent is dispatched AFTER the Demand List has been compiled from the planning cards (Phase 2) — not before. Personas see the resulting package only in the Phase 4 review round.

Dispatch ONE quantitative analysis agent using `.claude/skills/sherlock/quantitative-agent-prompt.md`. The agent receives:
- The **Demand List** (from Phase 2)
- The **Shared Fact Base** (from Step 1.4)
- The **user's original query**
- Access to tools: `run_command`, `web_search`, `read_file`, `write_file`
- Instruction: "Execute every valid demand. Use `python3 .claude/skills/sherlock/tools/analysis/stats.py` and `simulation.py` where applicable. Produce a Quantitative Analysis Package as JSON."
- Output instruction: "Save the Quantitative Analysis Package to `.claude/skills/sherlock/quant-analysis-package.json` using write_file. Each analysis must carry a sequential 'id' field ('Q001', 'Q002', ...)."

Wait for the agent to return (budget: 1500s — see Agent Timeout Budgets). The agent saves the package file incrementally, so it may exist even after a timeout. Then:

1. **Read `.claude/skills/sherlock/quant-analysis-package.json`.**
2. **Valid JSON, analyses cover ALL demands?** → Set `"status": "complete"`. Proceed.
3. **Valid JSON but incomplete (timeout or partial coverage)?** → Dispatch ONE retry agent with ONLY the missing demands (narrowed prompt: missing demands + Shared Fact Base + instruction to APPEND new analyses to the existing package file). Retry succeeded → `"status": "complete"`. Retry failed → keep the partial package, set `"status": "partial"` and `"missing_demands": [{"persona": "...", "computation": "...", "reason": "quant agent timeout"}]`. Flag in metadata: `⚠️ Quantitative package partial — {N}/{M} demands completed`. Personas proceed with the partial package. This is the only retry in Phase 3 — never more than one, and never for any other agent role (the Step 1.3 research quality-gate re-dispatch is a separate, pre-existing mechanism, also max 1).
4. **No file / invalid JSON / zero analyses?** → Proceed without quantitative analysis. Flag in metadata: `⚠️ Quantitative analysis unavailable — agent failed`.

The output is the **Quantitative Analysis Package** — a JSON object with `analyses[]`, `status`, and `missing_demands` fields. This is shared with ALL persona review agents in Phase 4.

**Environment degradation (quant agent):** If `run_command` is unavailable to the quantitative agent (e.g., headless dispatch environments), use the design/execute split: the quant agent writes self-contained Python scripts (stdlib only) and declares them in the package; the orchestrator executes them verbatim and returns the outputs for the agent to interpret. The package's `limitations` field must state when results were produced this way.

**Token budget: Moderate.** Quantitative execution is compute, not prose. The agent should produce analysis results, not essays.

### Phase 3.5: Quant Verification (v0.7.2)

After the quant package completes (complete or partial), dispatch ONE verification agent (budget: 1500s, role "quantitative", name "quant-verify") receiving:

1. **The Quantitative Analysis Package** (all analyses)
2. **The Shared Fact Base**
3. **The user's original query** (needed to judge which results are load-bearing for the conclusions)
4. **Instruction:** "Select the 1-3 most load-bearing results (the numbers the final conclusions depend on most). For each, re-derive it using a DIFFERENT method than the original analysis — Monte Carlo breakevens via closed-form arithmetic, EV trees via boundary analysis, statistical tests via an alternative test. Do NOT re-run the original scripts — reproduction is not verification. Verdict per result: `verified` (MC-type: relative deviation ≤15%; analytic: agreement), `diverged` (beyond tolerance — report both numbers), or `unverifiable` (no alternative method exists)."

The agent appends a top-level `"verification"` field to `.claude/skills/sherlock/quant-analysis-package.json`:

```json
{"verification": {"status": "verified|diverged|unverifiable|mixed", "details": [{"analysis_id": "Q001", "claim": "...", "original": ..., "recomputed": ..., "verdict": "verified|diverged|unverifiable", "method": "..."}]}}
```

Log the agent in run-log.json as {"name": "quant-verify", "role": "quantitative"}.

**Degradation:** verification agent fails/times out → package stands without the field; metadata notes `⚠️ Quant verification unavailable`. A `diverged` verdict is NEVER auto-recomputed or hidden — it must appear in the report (see Evidence Appendix).

## Phase 4: Annotated Review Round

When the quant package is ready (complete, partial, or failed) AND all planning cards have returned or timed out, dispatch ONE FRESH agent per persona (parallel batch). Each receives:

1. **The persona's full prompt** (from file)
2. **The persona's own planning card** (contents of `persona-card-{name}.md`)
3. **The Quantitative Analysis Package** (complete or partial; conclusions touching missing_demands MUST be UNSUPPORTED)
4. **The user's original query**
5. **Instruction:** "Produce your annotated review per your Annotated Review section. ≤100 words per item."
6. **Output persistence:** Save to `.claude/skills/sherlock/persona-review-{name}.md`.

Log review agents as `{"name": "review-{name}", "role": "review", ...}` in run-log.json.

**Degradation:** Package entirely unavailable → skip reviews; the report marks all quantitative claims as "模型推断，无事实库支撑". A persona whose review agent fails → that persona's directions are marked "未经 persona 复核" in the report. Never retry a review agent. A persona whose planning card failed skips review.

### Phase 4.5: Follow-up Quant Round (conditional)

After ALL review agents have returned or timed out, check the reviews for `FOLLOWUP:` demands. If any exist: dispatch ONE quant agent (same spec as Phase 3) covering all follow-up demands, appending new analyses with new sequential Q-ids to the existing package file. Log it in run-log.json with role "quantitative" (name: "quant-followup"). Never more than one follow-up round. If the follow-up round fails or times out, the package from Phase 3 stands — degrade per Phase 3's partial-package rules. The report's Quantitative Findings section incorporates the follow-up Q-ids. Follow-up analyses are not re-verified by Phase 3.5 — their 验证状态 is unverified.

If no FOLLOWUP demands exist, skip this phase entirely and note "Quant rounds: 1" in metadata.

**Run logging:** After ALL agents (research, quantitative, persona planning, review, baseline, and the follow-up quant agent if one ran) have returned or timed out — i.e., once the follow-up round above has completed or been skipped — write `.claude/skills/sherlock/run-log.json` recording EVERY agent dispatched this run:

```json
{"test_case": "{short slug of the query}", "date": "YYYY-MM-DD", "agents": [{"name": "{agent name}", "role": "persona|review|quantitative|research|baseline", "outcome": "success|timeout|empty|error", "duration_s": 0}]}
```

`outcome`: `success` = returned usable output; `timeout` = killed at its role budget or returned no usable output; `empty` = returned zero output; `error` = explicit error. Record failures honestly — this log is the reliability baseline data source.

## Phase 5: Three-Layer Synthesis

### Layer 1: Divergence Summary

From the planning cards' "Expected divergence" fields and the reviews' annotation patterns (e.g., one persona REVISED where another CONFIRMED the same analysis), identify the top 2-3 genuine divergences. For each: state the two positions and which evidence (F-id/Q-id) discriminates between them — or note that the fact base cannot currently discriminate.

**Honesty check — low controversy topics.** If zero genuine divergences are found AND review annotations are overwhelmingly CONFIRMED, the personas are not disagreeing because there is likely a clear consensus answer. Add this flag to the Key Divergences section:

"⚠️ This topic produced near-complete agreement (0 divergences detected). Multi-perspective analysis may not add significant value here — the answer appears uncontroversial. Consider reframing your question to surface genuine disagreement, or accept that a direct model response may be sufficient."

This is an honesty mechanism — it tells the user when the framework's core value proposition (conflict → insight) is not firing, rather than silently producing a report that looks comprehensive but adds nothing.

**Semantic diversity record.** After identifying divergences, re-read every planning card's research directions and judge overlap SEMANTICALLY: two directions overlap when they would lead to substantially the same recommendation, even if worded differently (wording similarity is already covered by the lexical-floor metric — do not duplicate it). Write `.claude/skills/sherlock/semantic-diversity.json`:

```json
{"directions": [{"persona": "<name>", "summary": "<=15-word direction label"}],
 "overlap_pairs": [{"persona_a": "<name>", "persona_b": "<name>", "reason": "<one sentence>"}],
 "unique_directions": <int>, "total_directions": <int>}
```

`total_directions` = all directions across available cards; `unique_directions` = total minus directions absorbed into an overlap pair (count each overlapped cluster once). If cards are missing, count only available ones; if Phase 5 is skipped entirely, do not create the file (the harness reports it absent — non-gating). The run packager moves this file into the run dir. `directions` contains one entry per direction across all available cards, so its length equals `total_directions`.

### Layer 2: Blind Spot Synthesis

1. Collect every gap note from the planning cards and reviews (personas flag gaps per their Fact Base Constraint).
2. Identify dimensions that NO persona claims to cover adequately.
3. Also check: does the baseline cover angles that ALL personas missed?
4. Report these silences. They are often the most valuable findings.

### Layer 3: Action Pathway

Generate three tiers of next steps:

- **Immediate (24h)**: Ground in Holmes (deductive clarity) and Lestrade (pragmatic evidence). Must be specific and executable.
- **Short-term (1-2 weeks)**: Ground in Moriarty (stress-test the assumptions) and Adler (check the human dynamics).
- **Long-term**: Ground in Mycroft (structural view) and Hound (ongoing bias check).

## Phase 6: Output

### Full Report Format

```markdown
# 🔍 Sherlock Analysis: {one-line summary of the query}

---

## ⚡ Executive Summary

{≤250 字，给没时间读完全文的决策者。固定结构：}

**结论**：{3 条最重要的结论，每条一句话，大白话——禁止出现 p5/EV/p_die/Q-id 等术语}

**关键数字**：
| 数字 | 含义 |
|------|------|
| {≤6 行，每行一个对决策最重要的数字} | {它说明什么} |

**现在就该做的**：{24 小时内可执行的 1-2 件事}

{Executive Summary 是全报告唯一允许"结论先行"的章节——正文仍是证据先行。超过 250 字或出现术语即视为编写失败，重写。}

---

## 🔬 Core Findings

{3-5 bullet points. These are DISCOVERIES, not conclusions. Each one should be something the user might NOT have thought of on their own. Avoid generic observations — every finding should earn its place.}

---

## ⚔️ Key Divergences

| Divergence | Position A | Position B | Discriminating Evidence |
|-----------|------------|------------|-------------------------|
| {divergence} | {persona A's position} | {persona B's position} | {F-id/Q-id, or "fact base cannot discriminate"} |

{Only include substantive divergences from the Layer 1 Divergence Summary.}

## 📊 Quantitative Findings

{Readable summary of the package's key results — the numbers that actually changed or confirmed positions. Cite Q-ids.}
{If verification exists: one line summarizing its status, e.g. "Verification: 2/3 load-bearing results independently reproduced; Q003 diverged (original −$51K vs recomputed −$38K — both negative, conclusion unchanged)." Always state divergences explicitly.}

---

## 📐 Framework Delta

### What the baseline said (raw model, no personas)
{1-paragraph summary of the baseline agent's analysis}

### What the framework added
- **Novel angles:** {insights the personas surfaced that the baseline missed entirely}
- **Reframed assumptions:** {baseline assumptions that at least one persona challenged}
- **Resolved via evidence:** {what the quantitative package or the divergence analysis clarified that neither the baseline nor any single persona could}
- **Blind spots surfaced:** {dimensions that ALL agents — personas AND baseline — missed}

### Delta Assessment
**Framework Gain (qualitative):** {Low / Medium / High}

{Justification — be honest. If the framework didn't add much, say so.}

{If Low: "💡 The framework added limited novelty on this query. Consider re-running with --depth deep to activate all 7 personas, or --personas X,Y to bring in missing perspectives. The baseline alone may have been sufficient for this specific question."}

---

## 👁️ Silent Dimensions

{What did NO persona AND NOT the baseline cover? Be honest. If something important was not addressed, say so clearly.}

---

## 🧭 Perspective Signals

{One line per persona: their lens's core direction and whether data confirmed or challenged it. ≤2 lines each. Include the baseline as a final line.}

---

## 🎯 Action Recommendations

### ⚡ Immediate (next 24 hours)
- {Specific, executable action}
- {Specific, executable action}

### 📅 Short-term (1-2 weeks)
- {Verification or test}
- {Verification or test}

### 🔭 Long-term
- {Systemic change or deep investigation}
- {Systemic change or deep investigation}

---

## 📎 Evidence Appendix（证据清单）

| 核心结论 | 支撑事实（F-id） | 量化依据（Q-id） | 验证状态 | 来源 |
|----------|------------------|-------------------|----------|------|
| {每条 Core Finding 一行} | {F003, F017} | {Q001 或 —} | {verified / diverged / unverified / —} | {sources.md 同号行} |

{F-id 与 Q-id 在 Step 1.4 / Phase 3 已分配——直接引用，不要自创编号。无法溯源的结论必须显式标注"模型推断，无事实库支撑"。}
验证状态：verified（独立复算一致）/ diverged（复算分歧，见 verification.details）/ unverified（未复算或无替代方法）/ —（无量化依据）。（verification.details 中的 unverifiable 在表中记为 unverified）

## 📊 Analysis Metadata

| Field | Value |
|-------|-------|
| Research mode | {full / degraded (empty fact base)} |
| Research depth | {light/standard/deep} ({N} agents) |
| Fact base | {N} claims, avg confidence {0.0-1.0} |
| Anti-sycophancy | {N} counter-facts / {N} total facts = {X%} |
| Personas dispatched | {comma-separated list} |
| Depth | {quick/standard/deep} |
| Baseline | Ran successfully / ⚠️ Failed |
| Personas complete | {N}/{total} |
| Personas used tools | {N}/{total} (Bash: N, Web: N, File: N) |
| Divergences identified | {N} |
| Silent dimensions found | {N} |
| Direction uniqueness (lexical floor) | {unique clusters}/{total directions} = {x%} — 措辞差异下限，语义多样性可能更低 |
| Direction uniqueness (semantic, LLM-judged) | {unique}/{total} = {x%} — Phase 5 判定；措辞不同但实质同向已合并。若 semantic-diversity.json 缺失记 n/a |
| Review annotations (C/R/U) | {n}/{n}/{n} |
| Quant rounds | {1 or 2 (follow-up executed)} |
| Framework Gain | {Low/Medium/High} |

{Degradation notes — if any persona card or review failed or was unavailable, list each with the reason. If no degradation, omit this line.}
```

### TL;DR Mode (--tldr)

Output only:
- Core Findings
- Framework Delta (just the assessment line: "Framework Gain: Low/Medium/High — {one-line justification}")
- Action Recommendations
- Direction uniqueness (lexical floor) and degradation notes (if direction uniqueness < 40% or degradation present, otherwise omit)
- Self-correction hook (if Gain is Low or direction diversity < 40%)

### Self-Correction Hook

At the very end of EVERY report (full or TL;DR), include:

```markdown
---
💡 **Not satisfied with this analysis?** Reply **deep** to re-analyze with all 7 personas, **quick** for a 2-persona fast rescan, or name specific personas to add. Reply **reframe** if I misunderstood your question.
```

If Framework Gain is Low or direction diversity < 40%, tailor the warning to the specific issue:

```markdown
---
⚠️ **Analysis quality note:**

{If Framework Gain is Low:}
The framework added limited novelty on this query — the baseline was already strong.

{If direction diversity < 40%:}
⚡ **Persona overlap detected.** The selected personas produced highly overlapping directions (direction diversity = {x%}). This means the analysis did not benefit from the multi-perspective approach as intended.

Recommendations:
- `/sherlock --depth deep` — activate all 7 cognitive lenses to increase contrast
- `/sherlock --personas {suggest 2 personas with maximally different cognitive styles from those already used}` — add contrarian perspectives
- Reframing your question — the current framing may be too narrow for multi-perspective analysis to surface genuine disagreement
```

{If direction diversity ≥ 40% and Framework Gain is Medium or above:}
```markdown
💡 **Not satisfied?** Reply **deep** for all 7 personas, **quick** for a fast rescan, or name specific personas to add. Reply **reframe** if I misunderstood your question.
```

## Phase 7: Run Packaging（运行打包，v0.6.2）

报告输出给用户后，立即打包本次运行的全部产物：

1. 创建 run 目录：`sherlock-runs/YYYYMMDD-HHMMSS/`（在用户当前工作目录，用当前时间戳）。
2. 把最终报告写入 `{run_dir}/report.md`。
3. 执行打包（移动产物 + 生成溯源清单 + 清理 skill 目录）：
   ```bash
   python .claude/skills/sherlock/tools/packaging/make_run_package.py assemble sherlock-runs/YYYYMMDD-HHMMSS --skill-dir .claude/skills/sherlock
   ```
4. 验证 skill 目录零残留：`research-output-*.json`、`quant-*.json`、`persona-card-*.md`、`persona-review-*.md`、`run-log.json`、`baseline-output.md`、`scout-output.md`、`semantic-diversity.json`、`fact-base.json`、`sources.md`、`fact-base-merged.json` 应全部不存在于 skill 目录。
4.5. Wait ~60s after packaging, then re-check the skill dir for late-arriving artifacts (stragglers may still be writing). If new artifacts appeared, sweep them into the run dir and re-verify.
5. 在对话中告知用户 run 目录路径，说明 sources.md 是证据溯源入口。

打包失败（脚本错误、目录不可写）不阻塞——报告已交付；在对话中说明打包失败原因。

## Operating Principles

1. **Intake before analysis.** Never dispatch agents without user confirmation (unless `--auto`). The right configuration is worth a single round-trip.
2. **Real discovery over rearrangement.** If the analysis is just nicely formatted common sense, you have failed. Push each persona to produce genuinely non-obvious insights. The Framework Delta section is your accountability — if it reads "Low," ask yourself why.
3. **Conflict is a feature.** If all personas agree, either the problem is trivial or the personas aren't trying hard enough. Seek and amplify genuine disagreement. Direction uniqueness (lexical floor) (unique planning directions / total) is the quantitative measure — if it drops below 40%, the multi-perspective approach didn't deliver.（阈值按旧 Jaccard 指标校准，containment≥0.65 新指标下仅作参考线）
4. **Never auto-restart.** If direction diversity is low or Framework Gain is Low, report it honestly and suggest re-run parameters. Never restart analysis automatically — the user decides.
5. **Honesty about failure.** Never fabricate a review or a divergence. Never hide a failed persona. A failed review IS information — it means that persona's directions could not be verified against the data. Report this as a finding, not an error. The user trusts the integrity of the report more than its completeness.
6. **Never close early.** Do not finalize the report until ALL dispatched agents have returned or explicitly timed out. A missing review is not a license to truncate. Wait for your agents.
7. **Baseline as yardstick.** The framework's value is measured by what it adds OVER the raw model. The baseline is not optional — it is the control group that makes the experiment meaningful.
8. **Cost consciousness.** Only run the personas needed. Don't dispatch 7 agents when 2 will do. Report only divergences that affect the decision.
9. **Action matters.** Every analysis should end with something the user can DO. Pure contemplation without actionability is incomplete.
10. **Self-correction is built in.** Every report offers a path to improve. The framework should be able to critique its own output.