kotonoha 0.2.0 → 0.3.0

package/skills/consulting-analyst/SKILL.md

@@ -0,0 +1,241 @@
+---
+name: consulting-analyst
+description: >-
+  Structures ambiguous business and technical problems before writing or
+  presentation design. Uses consulting frameworks selectively—not
+  mechanically—to define the decision question, build issue trees, form and
+  test hypotheses, compare current and target states, evaluate alternatives,
+  and synthesize evidence into an actionable recommendation. Use for requests
+  like "structure this problem", "build an issue tree", "analyze the root
+  cause", "compare these options", "create a transformation roadmap",
+  "prepare the analysis for a Blueprint or White Paper",
+  「課題を構造化して」「論点を整理して」「仮説を検証して」
+  「現状と目標のGapを分析して」「選択肢を比較して」
+  「BlueprintやWhite Paperの分析を準備して」. Produces analysis artifacts
+  and handoff inputs for tech-writer and presentation-planner. Does not own
+  final document prose, slide design, implementation design, or factual
+  research that has not been supplied or independently verified.
+license: MIT
+argument-hint: "[analyze|review|handoff] <problem, decision, or source files>"
+---
+
+# consulting-analyst
+
+Turns an ambiguous problem into a defensible chain from question to evidence,
+conclusion, and action. Frameworks are tools for reducing uncertainty, not
+formats that must be filled.
+
+## Responsibility boundary
+
+This skill owns:
+
+- Decision-question and success-condition definition
+- Issue decomposition and MECE review
+- Hypotheses, evidence needs, confidence, and falsification conditions
+- Current-state, target-state, and gap analysis
+- Explicit option criteria, weighting, scoring, and sensitivity analysis
+- Synthesis into findings, implications, recommendations, and next actions
+- Structured handoff to `tech-writer` or `presentation-planner`
+
+This skill does not:
+
+- Invent facts, customer evidence, market data, estimates, or citations
+- Treat assumptions as verified findings
+- Write the final technical document when `tech-writer` is available
+- Design slide narratives or visual systems when `presentation-planner` is
+  available
+- Replace requirements, system design, project planning, financial modeling,
+  legal review, or domain-expert judgment
+
+When the user asks directly for a Blueprint, White Paper, proposal, or
+presentation and the underlying analysis is incomplete, complete this
+analysis pass first, then hand the result to the owning writing or
+presentation skill.
+
+## Modes
+
+- `analyze` (default): create or revise the analysis artifacts and produce a
+  synthesis handoff.
+- `review`: challenge an existing analysis for missing branches, unsupported
+  claims, hidden assumptions, biased criteria, weak evidence, and conclusions
+  that do not follow.
+- `handoff`: normalize existing analysis into the handoff contract without
+  repeating completed work.
+
+## 1. Gather context one question at a time
+
+Ask only the single most informative missing question, then wait. Stop when
+the following are known or explicitly recorded as unknown:
+
+1. The decision-maker or actor who will use the analysis
+2. The exact decision, problem, or question to resolve
+3. The measurable outcome or decision deadline
+4. Scope, constraints, and excluded topics
+5. Available evidence, source files, and known data gaps
+6. Required destination: analysis only, document, Blueprint, White Paper,
+   proposal, or presentation
+
+Do not ask the user which framework to use unless they have a mandatory
+method. Select the smallest framework set that resolves the question.
+
+## 2. Create the analysis workspace
+
+Write artifacts under `.consulting/<analysis-slug>/` unless the user specifies
+another directory. Use a stable, filesystem-safe slug so separate analyses do
+not overwrite one another.
+
+In `analyze` mode, create:
+
+1. `analysis-brief.md`
+2. `issue-tree.md`
+3. `hypothesis-evidence-ledger.md`
+4. `synthesis-handoff.md`
+
+Start from the matching files under `assets/templates/`.
+The packaged templates use English canonical field names. Translate headings
+and instructions into the requested output language while preserving artifact
+filenames, IDs, statement types, status values, and table semantics.
+
+Create `decision-analysis.md` only when Current–Target–Gap analysis or option
+comparison is in scope. Record omitted artifacts and the reason in
+`synthesis-handoff.md`. In `review` mode, update only artifacts affected by
+the findings. In `handoff` mode, normalize the supplied analysis without
+creating empty framework artifacts.
+
+## 3. Select frameworks by decision need
+
+Read `references/framework-selection.md`. Use no more than three primary
+frameworks in one analysis unless the user explicitly requests a broader
+study.
+
+| Decision need | Primary framework |
+|---|---|
+| Decompose an ambiguous question | Issue Tree / logic tree |
+| Test an explanation or proposed answer | Hypothesis–Evidence–Falsification |
+| Explain cause rather than symptoms | Causal tree / 5 Whys with evidence |
+| Define a future state and transformation path | Current–Target–Gap |
+| Compare alternatives transparently | Weighted decision matrix |
+| Communicate the final reasoning | Pyramid Principle / SCQA |
+
+SWOT, 3C, PESTLE, Five Forces, capability maps, and impact/effort matrices
+may be supporting lenses. Do not use them unless each field changes a
+decision, hypothesis, criterion, or action.
+
+## 4. Build a testable issue tree
+
+Use `references/evidence-and-hypotheses.md`.
+
+1. Write one decision question at the root.
+2. Decompose by one explicit logic at each level, such as causes, options,
+   capabilities, lifecycle stages, or economics.
+3. Make sibling branches collectively sufficient for the parent question and
+   remove material overlap.
+4. Mark branches as `priority`, `supporting`, `out of scope`, or `unknown`.
+5. Define what evidence would answer every priority leaf.
+
+Do not claim perfect MECE when the domain is uncertain. Record residual
+overlap and known omissions.
+
+## 5. Form hypotheses and manage evidence
+
+For each priority issue:
+
+- State the hypothesis as a falsifiable proposition
+- Record why it is plausible without presenting that rationale as proof
+- Define evidence that supports and weakens it
+- Identify source, date, owner, and confidence
+- Separate `fact`, `estimate`, `assumption`, `interpretation`, and
+  `recommendation`
+- Set the next evidence-gathering action and owner
+
+Never upgrade an assumption to a finding because it appears in several
+frameworks. Repetition is not corroboration.
+
+## 6. Analyze gaps or alternatives
+
+Use the path that fits the decision:
+
+### Current–Target–Gap
+
+Describe current and target states with the same dimensions and evidence
+standard. Map each material gap to an intervention, dependency, owner,
+measure, and transition risk. Do not jump directly from aspiration to a
+roadmap.
+
+### Weighted decision matrix
+
+Define criteria before scoring options. State:
+
+- Criterion definition and direction
+- Weight and rationale
+- Scoring scale with anchors
+- Evidence behind each score
+- Mandatory thresholds or disqualifiers
+- Sensitivity to plausible changes in weights or scores
+
+The arithmetic supports judgment; it does not replace it.
+
+## 7. Synthesize without overclaiming
+
+Build the synthesis in this order:
+
+1. **Answer**: the current best answer to the decision question
+2. **Because**: two to four mutually distinct supporting findings
+3. **Evidence**: traceable sources and confidence for each finding
+4. **So what**: implication for the decision-maker
+5. **Now what**: action, owner, timing, and validation checkpoint
+6. **Uncertainty**: assumptions, counterevidence, and conditions that would
+   change the recommendation
+
+Use the Pyramid Principle for the final reasoning structure. Use SCQA only
+when it clarifies the audience's path to the question; do not manufacture
+dramatic tension.
+
+## 8. Handoff to the owning skill
+
+Read `references/handoff-contract.md`.
+
+- For a technical or business document, pass `synthesis-handoff.md` to
+  `tech-writer`, including the target doctype.
+- For a presentation, pass it to `presentation-planner`, including the exact
+  audience decision and evidence status.
+- When both are requested, write the source document first unless the user
+  explicitly prioritizes the presentation.
+
+The receiving skill may restructure the communication, but it must preserve
+evidence IDs, confidence, assumptions, disconfirming evidence, decision
+criteria, and unresolved questions.
+
+## 9. Quality gate
+
+Before reporting completion, confirm:
+
+- The root question names an actor and decision
+- Every recommendation traces to findings and evidence
+- Every priority issue has an answer, explicit unknown, or next action
+- Facts, estimates, assumptions, and interpretations remain distinguishable
+- A hypothesis marked `Supported` cites at least one `Fact` or `Estimate`;
+  that evidence must support the specific hypothesis. Assumptions and
+  interpretations may guide analysis but never count as supporting evidence
+- Criteria and weights were defined before option scoring
+- Decision-matrix weights sum to 100%, and sensitivity checks follow the
+  minimum procedure in `decision-analysis.md`
+- Current and target states use comparable dimensions
+- Counterevidence and uncertainty are visible
+- No framework section exists only because a template contained it
+- Every omitted artifact is named with the reason it was unnecessary
+- The handoff identifies what the next skill may and may not change
+
+If evidence is insufficient, report `analysis incomplete` with the unresolved
+decision-critical gaps. Do not create a success-shaped recommendation.
+
+## Completion report
+
+Report:
+
+- Mode and selected frameworks with reasons
+- Artifacts created or reviewed
+- Decision question and current answer
+- Confirmed findings, assumptions, and unresolved evidence gaps
+- Handoff destination, if any
+- `analysis completed` or `analysis incomplete`

package/skills/consulting-analyst/assets/templates/analysis-brief.md

@@ -0,0 +1,58 @@
+# Analysis brief: <analysis title>
+
+<State what decision this analysis supports and what the decision-maker will
+be able to decide after reading it.>
+
+- Analysis owner: <person or team>
+- Decision-maker: <role or forum>
+- Decision deadline: <YYYY-MM-DD>
+- Destination: Analysis / Blueprint / White Paper / Proposal / Presentation
+- Status: Draft / In Analysis / Ready for Handoff / Blocked
+
+## Decision question
+
+<Write one question naming the actor, choice or problem, scope, and time
+horizon.>
+
+## Intended outcome
+
+<State the decision or action this analysis must enable and how success will
+be measured.>
+
+## Scope and exclusions
+
+### In scope
+
+- <Scope item>
+
+### Out of scope
+
+- <Excluded item and where it will be handled>
+
+## Constraints
+
+| Constraint ID | Constraint | Source | Consequence |
+|---|---|---|---|
+| CON-001 | <Constraint> | <Source> | <Impact on analysis or options> |
+
+## Available evidence
+
+| Source ID | Source | Statement type | Date | Owner | Known limitation |
+|---|---|---|---|---|---|
+| SRC-001 | <File, data set, interview, or URL> | Fact source / Estimate source / Context | <Date> | <Owner> | <Limitation> |
+
+## Decision-critical unknowns
+
+| Unknown ID | Question | Why it matters | Collection method | Owner | Deadline |
+|---|---|---|---|---|---|
+| UNK-001 | <Unknown> | <Decision impact> | <Method> | <Owner> | <Date> |
+
+## Framework selection
+
+| Framework | Decision need | Expected output | Reason selected |
+|---|---|---|---|
+| <Framework> | <Need> | <Artifact field> | <Reason> |
+
+## Frozen requirements
+
+- <Facts, definitions, criteria, deadlines, or constraints that may not change>

package/skills/consulting-analyst/assets/templates/decision-analysis.md

@@ -0,0 +1,62 @@
+# Decision analysis
+
+Use the Current–Target–Gap section, the option-comparison section, or both
+only when they are required by the decision.
+
+## Current–Target–Gap
+
+| Dimension | Current state and evidence | Target state and measure | Gap ID | Intervention ID | Required intervention | Dependency | Owner |
+|---|---|---|---|---|---|---|---|
+| <Capability, process, data, technology, governance, people, or operations> | <State and EVD IDs> | <State and target> | GAP-001 | INT-001 | <Intervention> | <Dependency> | <Owner> |
+
+### Transition risks
+
+| Risk ID | Gap or intervention IDs | Risk | Trigger | Mitigation | Decision owner |
+|---|---|---|---|---|---|
+| RSK-001 | GAP-001 / INT-001 | <Risk> | <Trigger> | <Mitigation> | <Owner> |
+
+## Option criteria
+
+Define criteria and weights before scoring options.
+
+| Criterion ID | Criterion | Definition | Direction | Weight | Scoring anchors | Mandatory threshold |
+|---|---|---|---|---:|---|---|
+| CRT-001 | <Criterion> | <Definition> | Higher / Lower is better | <Percent> | 1=<anchor>, 3=<anchor>, 5=<anchor> | <Threshold or none> |
+
+The weights must sum to 100%. Record and resolve any exception before scoring.
+
+## Option score details
+
+Use one row per option and criterion so every score has its own evidence.
+
+| Option | Criterion ID | Score | Weight | Weighted score | Evidence | Rationale and caveat |
+|---|---|---:|---:|---:|---|---|
+| <Option> | CRT-001 | <1–5> | <Percent> | <Score × weight> | <EVD IDs> | <Why this anchor applies> |
+
+## Option summary
+
+| Option | Weighted total | Mandatory threshold result | Disqualified | Rank | Material caveat |
+|---|---:|---|---|---:|---|
+| <Option> | <Total> | Pass / Fail | Yes / No | <Rank> | <Caveat> |
+
+## Sensitivity analysis
+
+At minimum, test:
+
+1. Equal weights across all criteria
+2. A one-anchor increase and decrease for the top-weighted criterion scores
+3. A plausible weight shift away from the highest-weighted criterion
+4. Every case where a change causes a rank flip or threshold failure
+
+| Scenario | Exact perturbation | Recalculated ranking | Rank or threshold change | Decision impact |
+|---|---|---|---|
+| Base case | None | <Ranking> | None | <Impact> |
+| Equal weights | <Weights> | <Ranking> | <Change> | <Whether recommendation changes> |
+| Score stress | <Option, criterion, ±1 anchor> | <Ranking> | <Change> | <Impact> |
+| Weight stress | <Criterion and weight change> | <Ranking> | <Change> | <Impact> |
+
+## Decision interpretation
+
+- Recommended option or intervention set: <Answer>
+- Why the arithmetic supports but does not determine the judgment: <Reason>
+- Conditions that would change the ranking: <Conditions>

package/skills/consulting-analyst/assets/templates/hypothesis-evidence-ledger.md

@@ -0,0 +1,48 @@
+# Hypothesis and evidence ledger
+
+<State which decision question these hypotheses test and how the ledger will
+prevent unsupported conclusions.>
+
+## Hypotheses
+
+| Hypothesis ID | Issue ID | Falsifiable proposition | Rationale, not proof | Confidence | Decision if true | Decision if false |
+|---|---|---|---|---|---|---|
+| HYP-001 | Q1.1 | <Proposition> | <Why plausible> | High / Medium / Low | <Consequence> | <Consequence> |
+
+## Evidence
+
+Use one evidence row per hypothesis pairing, or explicitly list multiple HYP
+IDs when direction and limitations apply equally to all of them. If they
+differ, use separate rows with the same EVD ID; repeated evidence is not
+independent corroboration.
+
+Preserve interpretations as `Interpretation` rows linked to their underlying
+EVD IDs. Interpretations do not count as supporting evidence.
+
+| Evidence ID | Hypothesis IDs | Direction | Statement type | Source ID and date | Finding or interpretation and underlying EVD IDs | Quality | Limitation |
+|---|---|---|---|---|---|---|---|
+| EVD-001 | HYP-001, <other applicable HYP IDs> | Supports / Weakens / Neutral | Fact / Estimate / Interpretation | SRC-001, <date> | <Finding, or interpretation with underlying EVD IDs> | High / Medium / Low | <Limitation> |
+
+## Assumption register
+
+Assumptions may guide analysis but do not count as supporting evidence.
+
+| Assumption ID | Related issue or hypothesis | Assumption | Impact if false | Validation method | Owner | Deadline |
+|---|---|---|---|---|---|---|
+| ASM-001 | Q1.1 / HYP-001 | <Unverified condition> | <Impact> | <Method> | <Owner> | <Date> |
+
+## Hypothesis decisions
+
+A `Supported` hypothesis must cite at least one `Fact` or `Estimate` EVD row
+whose direction is `Supports` for that hypothesis. Assumptions and
+interpretations alone cannot establish `Supported` status.
+
+| Hypothesis ID | Status | Reason | Remaining uncertainty | Next evidence action | Owner | Deadline |
+|---|---|---|---|---|---|---|
+| HYP-001 | Supported / Weakened / Rejected / Open | <Reason with EVD IDs; Supported requires at least one Fact or Estimate> | <Uncertainty> | <Action> | <Owner> | <Date> |
+
+## Contradictions and alternative explanations
+
+| ID | Related hypothesis | Counterevidence or alternative | Materiality | Resolution |
+|---|---|---|---|---|
+| ALT-001 | HYP-001 | <Alternative> | High / Medium / Low | <How handled> |

package/skills/consulting-analyst/assets/templates/issue-tree.md

@@ -0,0 +1,35 @@
+# Issue tree: <root decision question>
+
+<State how this tree decomposes the root question and which decision it is
+intended to support.>
+
+## Decomposition logic
+
+- Logic used at level 1: <Causes / Options / Capabilities / Lifecycle / Economics>
+- Reason: <Why this logic is collectively sufficient for the root>
+- Known overlap or omission: <Residual limitation>
+
+## Tree
+
+```text
+Q0 <Root decision question>
+├── Q1 <Branch>
+│   ├── Q1.1 <Priority leaf>
+│   └── Q1.2 <Supporting leaf>
+└── Q2 <Branch>
+    ├── Q2.1 <Priority leaf>
+    └── Q2.2 <Out-of-scope leaf>
+```
+
+## Leaf register
+
+| Issue ID | Parent | Question | Status | Priority | Evidence needed | Decision consequence |
+|---|---|---|---|---|---|---|
+| Q1.1 | Q1 | <Answerable question> | Open / Answered / Unknown / Out of scope | High / Medium / Low | <Evidence> | <Why the answer matters> |
+
+## MECE review
+
+- Material overlap: <Overlap and resolution>
+- Missing branch risk: <Possible omission>
+- Scope boundary: <Why excluded branches do not block the decision>
+- Review owner: <Person or role>

package/skills/consulting-analyst/assets/templates/synthesis-handoff.md

@@ -0,0 +1,68 @@
+# Synthesis and handoff: <analysis title>
+
+<State the decision this handoff enables and what the receiving writing or
+presentation skill must communicate.>
+
+- Decision-maker: <Role or forum>
+- Decision question: <Question>
+- Decision deadline: <YYYY-MM-DD>
+- Current answer: <Recommendation, conclusion, or explicit unknown>
+- Confidence: High / Medium / Low
+- Destination: <Skill and target doctype or presentation purpose>
+- Analysis status: Completed / Incomplete
+- Omitted artifacts and reason: <Artifact: reason, or none>
+
+## Answer first
+
+<State the current best answer and the action it implies.>
+
+## Supporting findings
+
+| Finding ID | Issue IDs | Hypothesis IDs | Finding | Evidence | Related Gap, Intervention, or Criterion IDs | Confidence | So what |
+|---|---|---|---|---|---|---|---|
+| FND-001 | <Q IDs> | <HYP IDs> | <Finding> | <EVD IDs> | <GAP / INT / CRT IDs, or N/A with reason> | High / Medium / Low | <Decision implication> |
+
+## Recommended actions
+
+| Action ID | Supporting Finding IDs | Related Issue and Hypothesis IDs | Gap, Intervention, or Criterion IDs | Action | Owner | Timing | Success measure | Validation checkpoint |
+|---|---|---|---|---|---|---|---|---|
+| ACT-001 | <FND IDs> | <Q / HYP IDs> | <GAP / INT / CRT IDs, or N/A with reason> | <Action> | <Owner> | <Date or phase> | <Measure> | <Checkpoint> |
+
+Preserve the Q / HYP → FND / EVD → GAP / INT / CRT → ACT chain where
+applicable. Use only IDs defined in the analysis; mark inapplicable links
+`N/A` with a reason rather than inventing gaps, interventions, or criteria.
+
+## Options or transformation path
+
+- Selected option or target state: <Option, capability, or intervention>
+- Criteria, Gap, or Intervention IDs: <CRT / GAP / INT IDs, as applicable>
+- Rejected alternatives and reasons: <Options and reasons>
+- Sensitivity or sequencing conditions: <Conditions>
+
+## Assumptions, counterevidence, and uncertainty
+
+| ID | Type | Statement | Decision impact | Validation or response |
+|---|---|---|---|---|
+| UNC-001 | Assumption / Estimate / Counterevidence / Unknown | <Statement> | <Impact> | <Action> |
+
+## Evidence gaps
+
+| Gap ID | Missing evidence | Decision blocked or conditional | Owner | Deadline |
+|---|---|---|---|---|
+| EGP-001 | <Evidence> | <Impact> | <Owner> | <Date> |
+
+## Communication handoff
+
+- Target audience and prior knowledge: <Audience>
+- Target doctype or scenario: <Doctype or presentation purpose>
+- Required conclusion or call to action: <Outcome>
+- Evidence that must appear: <FND and EVD IDs>
+- Material caveats that must appear: <UNC IDs>
+- Frozen criteria, weights, scores, confidence, and wording: <Items>
+- Sections or slides that are optional: <Items>
+- Questions to return to consulting-analyst: <Return conditions>
+
+If `Analysis status` is `Incomplete`, the receiving skill must either return
+the decision-critical gaps to `consulting-analyst` or preserve the incomplete
+status, evidence gaps, confidence, and conditional wording visibly in the
+output.

package/skills/consulting-analyst/references/evidence-and-hypotheses.md

@@ -0,0 +1,80 @@
+# Evidence and hypothesis discipline
+
+The analysis must preserve the difference between what is known, estimated,
+assumed, interpreted, and recommended.
+
+## Statement types
+
+| Type | Meaning | Required handling |
+|---|---|---|
+| Fact | Directly supported by a traceable source | Record source, date, scope, and limitations |
+| Estimate | Quantified approximation | Record method, range, sensitivity, and owner |
+| Assumption | Unverified condition used to proceed | Record validation plan and impact if false |
+| Interpretation | Meaning inferred from facts or estimates | Show the reasoning and alternatives |
+| Recommendation | Proposed action | Trace to findings, constraints, and decision criteria |
+
+## Hypothesis record
+
+A useful hypothesis includes:
+
+- A specific proposition
+- The issue-tree leaf it answers
+- Why it is plausible
+- Supporting evidence expected
+- Disconfirming evidence expected
+- A confidence level
+- A decision consequence if true or false
+
+Do not write confidence as a percentage unless it comes from a defined model
+or elicitation method. Use `High`, `Medium`, or `Low` with a short rationale.
+
+## Evidence quality
+
+Assess evidence by:
+
+- Directness: does it measure the claimed phenomenon?
+- Reliability: can the source and method be trusted?
+- Recency: is it current enough for the decision?
+- Representativeness: does it cover the relevant population and context?
+- Independence: does it corroborate rather than repeat another source?
+- Materiality: could it change the conclusion or action?
+
+Record contradictory evidence beside supporting evidence. Do not relegate it
+to an appendix that the synthesis ignores.
+
+Use one evidence row per hypothesis pairing, or explicitly list multiple HYP
+IDs if the direction and limitations are the same for each hypothesis. Where
+they differ, reuse the EVD ID in separate pairing rows; this does not create
+independent corroboration.
+
+Preserve interpretations as `Interpretation` rows with links to underlying
+EVD IDs and alternative explanations. Interpretations do not count as
+supporting evidence. A `Supported` hypothesis requires at least one `Fact` or
+`Estimate` EVD row marked `Supports` for that hypothesis; assumptions and
+interpretations alone are insufficient.
+
+## Causal claims
+
+Before stating that one factor caused another, check:
+
+- Temporal order
+- Plausible mechanism
+- Alternative explanations
+- Selection and measurement bias
+- Whether an intervention changed the outcome
+
+When these conditions are not met, use association or contribution language
+instead of causation.
+
+## Evidence gaps
+
+For every decision-critical gap, record:
+
+- Missing evidence
+- Why it matters
+- Best available collection method
+- Owner
+- Deadline
+- Decision that must wait or proceed conditionally
+
+An explicit unknown is better than a fabricated conclusion.

package/skills/consulting-analyst/references/framework-selection.md

@@ -0,0 +1,84 @@
+# Framework selection
+
+Choose frameworks from the decision need, not from familiarity or prestige.
+The smallest sufficient set is usually one analytical framework and one
+communication framework.
+
+## Selection sequence
+
+1. Name the actor and decision.
+2. Identify the uncertainty blocking that decision.
+3. Choose the framework that exposes or reduces that uncertainty.
+4. Define the artifact or decision field the framework must populate.
+5. Remove the framework if its output will not change the decision.
+
+## Primary frameworks
+
+### Issue Tree
+
+Use when the root question is too broad to answer directly. Select one
+decomposition logic per level. Good branches are answerable and decision
+relevant.
+
+Avoid mixing causes, solutions, departments, and project phases as siblings.
+That structure creates overlap without revealing what is missing.
+
+### Hypothesis–Evidence–Falsification
+
+Use when an explanation, forecast, or proposed solution must be tested.
+Define what would make the hypothesis less likely before collecting only
+supporting evidence.
+
+Avoid hypotheses that cannot fail, such as "improving quality may help".
+
+### Causal tree and 5 Whys
+
+Use for a specific observed outcome when the causal mechanism matters. Each
+link requires evidence; asking "why" repeatedly does not establish causality.
+
+Avoid forcing one root cause when several interacting causes fit the evidence.
+
+### Current–Target–Gap
+
+Use for Blueprint, transformation, capability, operating-model, or roadmap
+work. Describe current and target states with comparable dimensions before
+identifying gaps and interventions.
+
+Avoid target states made only of product names or aspirational adjectives.
+
+### Weighted decision matrix
+
+Use when several viable alternatives must be compared across competing
+criteria. Define scoring anchors and disqualifiers before assigning scores.
+
+Avoid false precision. Run sensitivity analysis when small weight changes can
+reverse the ranking.
+
+### Pyramid Principle
+
+Use to communicate a supported conclusion. Start with the answer, group
+mutually distinct reasons, then show evidence.
+
+Avoid using the pyramid to hide uncertainty or omit contradictory evidence.
+
+### SCQA
+
+Use when the audience needs a short path from shared context to a decision
+question. Keep the complication factual and proportional.
+
+Avoid manufacturing urgency or conflict that the evidence does not support.
+
+## Supporting lenses
+
+Use these only when their outputs feed a hypothesis, criterion, gap, or
+action:
+
+- PESTLE for external conditions
+- Five Forces for industry economics
+- 3C for customer, competitor, and company fit
+- SWOT for summarizing evidenced internal and external conditions
+- Capability Map for future-state abilities and ownership
+- Impact/Effort Matrix for sequencing already defined interventions
+
+Never stack several lenses to make an analysis look comprehensive. Coverage
+comes from the issue tree and evidence, not the number of framework names.