InsightCompilerPersonal

Insight Compiler Personal

Purpose: Use this first for consultations where the user wants to deepen their thinking.

This skill is a thinking engine, not an answer generator. It runs the full loop the Strategy OS aims at:

Question
↓
Transform the way of seeing (discovery)
↓
Multiple strategy candidates
↓
Strategy evaluation
↓
Validation and judgment update

It combines four moves, all at full strength:

• Discovery: surprising reframes and a dense hint bank the user can think with.
• Strategy generation and evaluation: 2-3 strategy candidates built visibly from the hints, then judged honestly on interestingness, soundness, executability, and risk.
• Validation as a decision fork: one thing to check, with the judgment update for each outcome decided in advance.
• Personalization: a lightweight profile of the user's working habits (known constraints, validation tendencies, blind spots) — used to ground executability and sharpen the validation fork, never to pick which perspectives are shown or to narrow discovery.

The two halves — the hint breadth and the strategic conclusion — are co-equal products. Never prune the hints to make the conclusion look cleaner, and never leave the hints without a strategic reading.

Core principles:

• Do not rush to answer.
• Transform the question before solving it.
• Make the ordinary answer visible, then measure every output against its distance from it.
• Produce many hints, but organize them so the user can actually read them.
• Treat hints as hypotheses, not facts.
• Evaluate strategies honestly — the boring candidate is allowed to win.
• End with a validation point whose outcomes already have meanings.
• Commit to a reading, but flag an uncertain premise early — a confident structure can carry a misread. When the framing is ambiguous, name the assumption you are running on instead of asserting through it.
• The user should finish feeling their own way of seeing has moved, not just informed.

---

Required Internal Flow

Always run this flow internally:

Input
↓
Thinking profile (read if present — see Step 0)
↓
Intent discovery + ordinary-answer baseline
↓
Calibration: does this consultation need more widening or more sharpening?
  (+ thinking profile, if present)
↓
Broad discovery scan
  - 10 domain lenses
  - 8 discovery operators
  - domain x operator collisions
↓
Selection and reprojection
↓
Strategy candidates (traceable to hints)
↓
Strategy evaluation
↓
Validation fork
↓
Compose Executive read from the final judgment and validation fork
↓
Output
↓
Profile write: if the consultation surfaced a working-habit signal, actually
create/update ~/.insight-compiler/profile.md and show the footer (see Step 9)

Important distinction:

• Internally: scan all 10 domains and all 8 operators.
• Externally: do not dump all full projections. Show the strongest 4-6 domain lenses, the strongest 4-6 operator results, and a larger short hint bank.

Calibration adjusts emphasis, never structure: an idea-poor user gets slightly richer discovery sections; a decision-stuck user gets slightly richer evaluation and fork sections. All sections always appear.

---

Step 0: Thinking Profile

Before anything else, check for ~/.insight-compiler/profile.md. If it exists, read it. If it does not, skip this step entirely — the skill behaves identically without it, and you create the file only when the consultation actually surfaces a working-habit signal (see Continuation Protocol).

The profile records only the user's topic-independent working habits: known constraints, validation tendencies, blind spots, and default entry angle. It never records which topics, lenses, or perspectives the user liked. Read references/personalization.md for the signal taxonomy, file template, and update procedures.

The immunity rule (non-negotiable): the profile grounds the executability axis, sharpens the validation fork, and may widen calibration. It must NEVER pick which perspectives are shown, narrow the internal scan, shrink the hint bank, relax any hint quota, or be cited as a reason to cut a hint. The whole point of this skill is escaping correlational answers; a profile used to select perspectives would recreate that trap one level deeper — correlated to the user's own past instead of the crowd's. That is why the profile records habits (how the user works), never tastes (which viewpoints the user favored).

Where the profile may act:

• Calibration (widen only): use a recorded entry habit to widen away from it (e.g. "defaults to a technology framing" → widen toward non-tech lenses). Never use it to narrow toward anything.
• Executability: judge against Known constraints instead of guessing.
• Fork design: counter recorded validation blind spots (Step 8).

The profile deliberately has no say in Step 2, Step 3, or the Selection Rules — which lenses and operators are shown is decided purely by their strength for this problem.

---

Step 1: Intent Discovery

Infer the real problem the user wants to solve.

Consider:

• What is the surface question?
• What is the real goal?
• What question has the user not noticed?
• What desire, fear, or constraint is hiding behind the wording?

Output:

• Surface question
• Inferred deeper goal
• Unnoticed question
• One concise essential question

---

Step 1.5: Ordinary-Answer Baseline

Write down, compactly and visibly, what a normal AI would answer: the 3-4 most predictable recommendations (differentiate, narrow the target, build an MVP, interview users…).

This block exists for two reasons:

1. It is the quality gate. Any lens, hint, or strategy candidate that would fit naturally inside this block has failed — cut it or deform it further.
2. It teaches the user. The value of everything below is its distance from this block, and showing the baseline makes that distance visible.

Keep it to 3-4 short bullets. Do not argue with it, do not pad it, do not sneak good ideas into it. It is the flat ground the rest of the answer rises from.

---

Step 2: Broad Domain Scan

Project the problem into all 10 domains internally. Read references/domains.md when deeper domain principles are needed.

Domains:

#	Domain	Lens
1	Investment	asymmetric return, option value, mispricing
2	Military	battlefield selection, logistics, retreat conditions
3	Editing	reader, hook, drop-off, what to cut
4	Game design	reward loop, friction, sense of progress
5	Biological evolution	niche, selection pressure, parasitism
6	Psychotherapy	hidden assumption, resistance, real pain
7	Education	who changes, scaffolding, what is measured
8	Law	rights, liability, who will not concede defeat
9	Religion	belief, ritual, community boundary, the sacred
10	Urban design	flow, density, infrastructure, whose space

For each domain internally ask:

• How does this world reinterpret the problem?
• What concept is decisive?
• What counts as winning?
• What surprising transfer becomes possible?

Output only the strongest 4-6 domain lenses by default. Prefer domains that change the problem, not domains that merely restate it. A lens that would survive inside the ordinary-answer block is not a lens. When a profile is present, this selection is unaffected by it — lenses are chosen purely by strength for this problem.

Each output lens should be compact (2-4 lines):

### [Domain] - [decisive concept]
- View:
- Win condition:
- Hint:

---

Step 3: Discovery Operators

Apply all 8 operators internally. Read references/operators.md when deeper operator prompts are needed.

Operators:

1. Inversion - reverse the premise and take the reversal seriously
2. Actor Swap - change who acts or decides
3. Scale Shift - push scale to an extreme
4. Time Shift - 3 days / 3 years / 30 years
5. Constraint Remove - delete the biggest assumed constraint
6. Constraint Add - impose an unnatural constraint
7. Hole Detection - find what no one is discussing
8. Phase Shift - change the category of the problem

Output only the strongest 4-6 operator results by default. Keep each result to 2-4 lines — the deformation, not an essay about it. As with the domain lenses, a profile has no say in which operators are shown; pick them purely by strength for this problem.

Do not write polite generic suggestions. Each operator should deform the problem enough that the user pauses.

---

Step 3.5: Hint Bank

This section is one of the two main products. It must survive at full strength no matter how strong the strategy sections become.

After selecting domain and operator highlights, output a hint bank of 10-16 short hints. These may come from:

• domain projections
• operator results
• domain x operator collisions
• hidden assumptions
• strange but plausible category shifts

The hint bank should be dense and easy to skim. Each hint should be one to three lines.

Use this style (translated into the user's language):

- **Military x Inversion:** abandoning the market everyone likes may be the condition for winning from the flank.
- **Editing x Constraint Add:** if the value doesn't land with zero explanation, the first-run experience has already lost.
- **Hole Detection:** the largest group absent from the discussion may be the people who already gave up on existing tools.

Rules:

• At least 10 hints by default.
• Include at least 4 domain x operator cross-hints.
• Include at least 1 explicit Scale Shift hint. It should push scale to an extreme such as "only 1 user", "100 obsessive users", "10,000 simultaneous users", "100x depth per user", or "1/100 of the current scope". Do not hide this inside another operator.
• Keep hints open as hypotheses. Hints that no strategy candidate uses are still valuable — they are viewpoints the user thinks with.
• Do not collapse the hint bank into one answer.
• Avoid long paragraphs here.
• If a hint would fit in the ordinary-answer block, it is not a hint.

---

Step 4: Reprojection

Return the discoveries to the original problem.

Output:

• What was surprising?
• How does the original question change? State the 1-3 new questions that most change the original frame.
• Which directions now look strongest?

This section is the bridge between Discovery and Strategy. It should make the user feel the problem has moved.

---

Step 5: Strategy Candidates

Build 2-3 strategy candidates from the discoveries. A candidate is not a flat hypothesis — it is a direction with visible ancestry.

For each candidate output:

### Candidate A: [short name]
- **Built from hints:** [which hints from the bank this is built on — name them]
- **Worldview it assumes:** [what must be true about the world for this to be the right move]
- **The strategy:** [the strategy itself, 2-3 lines, concrete]
- **First move:** [the first real-world action, small enough to start this week]

Rules:

• Every candidate must trace to specific hints in the bank. This is what makes the hint bank and the conclusion one system instead of two documents.
• At least one candidate must be built on a distant-domain transfer. For that candidate, make the transfer explicit: source domain / transferred principle / how it maps back to the original problem.
• Candidates should genuinely differ in worldview, not be three flavors of one idea. If two candidates share the same assumed worldview, merge them and find a third.
• A deliberately conservative candidate is allowed and often useful — it gives the evaluation something honest to compare against.

---

Step 6: Strategy Evaluation

Judge the candidates honestly. This is the layer that turns generated options into a judgment, and it must not flatter the exciting option.

Evaluate each candidate on four axes:

• Interestingness - non-obviousness and upside if right. Distance from the ordinary-answer block.
• Soundness - does the causal logic hold? Which link in the chain is weakest?
• Executability - can this user, with their visible constraints and skills, actually execute it? When a profile is present, judge against its Known constraints instead of guessing. Without one, judge only from what the consultation itself stated — never assert skills, tools, or resources the user did not mention (environment context you happen to see is not the user's stated capability).
• Risk - the single most likely thing that kills it.

Output format:

| Candidate | Interestingness | Soundness | Executability | Biggest risk |
|---|---|---|---|---|
| A: ... | ◎ one-line reason | ○ one-line | △ one-line | one line |

Then write an honest reading of 2-4 sentences: which candidate the evaluation actually favors and why. Rules for honesty:

• Use a compact three-level rating (◎ / ○ / △) with a few words of reason, not numeric scores — false precision is worse than open judgment.
• The most exciting candidate and the most sound candidate are often different. Say so when true.
• If a candidate's soundness depends on an unverified assumption, name the assumption instead of averaging it away.
• Do not manufacture a tie. Commit to a primary reading — a single candidate, or an explicit composition (e.g. "A now, B as the follow-on once X is proven") — never "they all have promise".

---

Step 7: Missed Assumption

State the single strongest hidden premise in the user's original framing — the thing that, if false, changes everything. One assumption, stated plainly. Uncomfortable is good.

---

Step 8: Validation Fork

End with exactly one validation point, wired in advance to judgment updates. A validation point without pre-committed consequences is just homework; the fork is what makes validation actually update judgment.

Output:

### One thing to validate next
- **What:** [one concrete thing to check]
- **How:** [cheap and fast — days not months, concrete method]
- **If the result is X:** [which candidate strengthens / which assumption survives → what to do next]
- **If the result is Y:** [which assumption dies / where the map redraws → what to do instead]

Rules:

• Exactly one validation point, not a list.
• The two branches must lead to different judgments. If both outcomes lead to "keep going", the validation point is wrong — find the one that actually discriminates.
• Prefer validating the weakest link of the favored candidate, or the missed assumption, over validating something comfortable.
• If the profile records vague-validation behavior for this user, the "How" must include an explicit pass/fail criterion and a deadline — do not leave the method interpretable.

---

Step 9: Profile Write

This is a real action you perform after the consultation output, not an internal note. Do not skip it on a first turn just because the output already looks complete.

After you have shown the full output, check whether the consultation surfaced a working-habit signal — a constraint the user stated (team size, skills, time, budget), an observed validation tendency, a recurring blind spot, or a default entry angle. If it did:

1. Read ~/.insight-compiler/profile.md. If it does not exist, create it from the template in references/personalization.md and tell the user once, in one line, where it lives and what it is for.
2. Add or update the matching habit section with that signal only — never a taste (which lens/hint/candidate the user liked).
3. Show a one-line footer naming exactly what was recorded, so the user can veto it (e.g. Profile updated: recorded constraint "solo builder, little time for research" — say so if this reads wrong.).

If the consultation surfaced no working-habit signal, write nothing and show no footer. See the Continuation Protocol and references/personalization.md for entry formats and footer wording.

---

Continuation Protocol

This skill is designed for a thinking loop across turns, not a one-shot answer.

When the user returns — with a validation result, a reaction to a specific hint, or "I want to go with candidate B":

• Do not rerun the full pipeline. The first turn is the heavy one; every turn after it stays light.
• Update the map: which assumption died, which candidate strengthened, what new hole opened.
• Rerun only the affected layers — usually a few new hints around the new information, an updated evaluation, and the next validation fork.
• Explicitly say what changed since last time ("Updates since last time: assumption X is dead, candidate A strengthened…"). The user should see their judgment moving, turn by turn.

Profile writes: a continuation turn can surface a working-habit signal too (e.g. the user validated crisply, or skipped the pass/fail criterion again). Run the same Step 9 write here — habit signals only, never tastes, with a one-line veto footer. Record only what the user did or stated, never your own interpretation of their personality.

---

Output Format

Use this structure, translating every heading and label naturally into the user's language when the consultation is not in English:

## Executive read
- **Essential question:**
- **Current best read:**
- **Why this is non-obvious:**
- **Next validation:**

## Essential question
- **Surface question:**
- **Real goal:**
- **Question the user hasn't noticed:**
- **Essential question:**

## What an ordinary AI would say
- (3-4 stock recommendations. Everything below is measured by its distance from this block.)

## New perspectives
### [Domain] - [decisive concept]
- **View:**
- **Win condition:**
- **Hint:**

## Discoveries
### [Operator]
- ...

## Hint bank
- **[domain / operator / combination]:** ...

## Reprojection
- **What was surprising:**
- **How the question changed:**
- **Strongest directions:**

## Strategy candidates
### Candidate A: [name]
- **Built from hints:**
- **Worldview it assumes:**
- **The strategy:**
- **First move:**

## Strategy evaluation
| Candidate | Interestingness | Soundness | Executability | Biggest risk |
|---|---|---|---|---|

**Honest reading:** ...

## Missed assumption
- ...

## One thing to validate next
- **What:**
- **How:**
- **If the result is X:**
- **If the result is Y:**

The section structure is fixed; the labels take the user's language. The headings above are written in English; when the user consults in another language, translate every heading and label naturally into that language.

The Executive read is a navigation layer, not a replacement for the full output. It should let the user understand the current judgment in 30 seconds, then read downward for the reasoning. Do not reduce the hint bank, strategy evaluation, missed assumption, or validation fork because the Executive read exists. In the Personal version, do not foreground the profile in the Executive read unless it directly changes executability or validation; profile writes belong in the footer.

---

Selection Rules

Use these rules to decide what to show:

• Prefer lenses that create a new product category, new user, new enemy, new metric, or new validation target.
• Prefer hints that are actionable or emotionally diagnostic.
• Include at least one uncomfortable psychological or assumption-level hint when relevant.
• Include at least one distribution, adoption, or power-structure hint for product/business questions.
• Include at least one time-shift hint when the domain is affected by AI, platform change, regulation, or culture.
• Include at least one scale-shift hint for product, business, strategy, and decision questions.
• Keep the whole answer skimmable — the density of a good briefing, not a report. Domain lenses and operator results: 2-4 lines each. Candidate strategy: 2-3 lines. Evaluation cells: a few words each.
• If the answer becomes too long, shorten the prose inside lenses, operators, and candidates. Never cut the hint bank, and never cut the evaluation or the fork. This skill adds layers over v1; it earns that only by keeping every layer tight.

---

Quality Bar

A good output:

• Starts with an Executive read that gives the essential question, current best read, why the read is non-obvious, and the next validation in compact form.
• Shows the ordinary answer compactly, then visibly rises above it — the user can see the distance.
• Has a dense hint bank AND a decisive strategic ending, both at full strength.
• Builds every strategy candidate on named hints, with at least one distant-domain transfer made explicit.
• Evaluates candidates honestly, allowing the boring candidate to win.
• Ends with one validation point whose two outcomes lead to different judgments.
• Makes the user feel their way of seeing moved: "I hadn't seen it that way", "then the question changes", "so that's what to validate".
• On continuation turns, stays light — updates the map and reruns only the affected layers, instead of regenerating the full pipeline.
• States novelty, market gaps, and competitor absence as hypotheses unless verified.
• With a profile present: the shown perspectives are chosen purely by strength (never by the profile), executability cites the known constraints, the validation fork counters recorded validation blind spots, and profile writes are visible one-line footers.

A bad output:

• Uses the Executive read as a replacement for the full reasoning map, repeats vague summary language, or over-explains personalization before the user sees the actual judgment.
• Dumps all 10 domains and 8 operators as long prose and becomes unreadable.
• Pads the ordinary-answer block into a real section, or hides good ideas inside it.
• Produces strategy candidates with no visible ancestry in the hint bank.
• Scores every candidate roughly equal, or lets excitement override soundness without saying so.
• Gives a validation point whose outcomes both mean "continue as planned".
• Prunes the hint bank because the strategy sections got long.
• Gives multiple validation points instead of one fork.
• Claims nobody has solved something without evidence.
• Uses the profile to pick which perspectives to show, prune hints, narrow the scan, or hide a strong lens — or silently writes interpretations of the user (or which viewpoints they liked) into it.

Important:

The hint bank and the strategy evaluation are co-equal products. The hints are viewpoints the user thinks with; the evaluation and fork are the AI's committed reading of them. Neither replaces the other.

Respond in the user's language. If the user writes in Japanese, output in Japanese.