Interview Skill

Progressive onboarding through structured discovery conversation.

Preflight: Read target canvas file(s) before any Write/Edit

Hard rule. Before issuing Write or Edit against any .claude/canvas/*.yml, use the Read tool on that file in this session. Claude Code's Read-before-Write check requires the Read tool specifically — cat/head/grep via Bash do NOT satisfy it.

Edit vs Write — different cost profiles (verified 2026-05-14):

• Edit (exact-string replacement): Read with limit: 1 satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent Edit calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., purpose.yml at 800+ lines).
• Write (full replacement): do a full Read first. Write obliterates the file; you should see what you're about to replace. The limit:1 shortcut is not appropriate here.

ID-bearing entries — scan the ID space before assigning (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:

grep "^  - id: <prefix>-" .claude/canvas/<file>.yml | sort -u

Replace <prefix> with the canvas's ID prefix (comp for landscape, opp for opportunities, sol for solutions, ht for human-tasks, etc.). Then pick the next free integer. validate_canvas.py has a duplicate-ID check (lines 230-239) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery — see roadmap-repo corrections.md 2026-05-15 "Duplicate canvas ID created in landscape.yml" for the worked example.

Original failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash head with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The limit:1 discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent correctly follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).

If this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.

See CLAUDE.md Canvas writes — Read before Write for the canonical rule.

When to Use

• Starting a new product or project.
• Joining an existing product that lacks documented context.
• Context has changed significantly and needs refreshing.

Workflow

Phase 0: Canvas state detection (ALWAYS FIRST)

Read .claude/canvas/purpose.yml and .claude/diamonds/active.yml at session start. Determine state:

• Canvas empty (template-only fields, no diamonds in active_diamonds): proceed to Universal Brief Flow below.
• Canvas populated (purpose statement set OR diamonds present): proceed to Continuing-Project Routing below.

This replaces the prior intent check ((a) try for 10 min / (b) onboard real project) and the prior time-budget routing (<8h / 8-48h / 48+h). Both were predict-the-future questions asked before any value was delivered. The brief is now universal for empty-canvas entry; depth and time-cost are chosen post-brief, when the user has the data to choose.

Universal Brief Flow (canvas empty)

Goal: the user walks away in ~10 minutes with a one-page brief on their idea that they can paste into a notes app and feel was worth the time. Then they choose what comes next, with each option declaring its time cost.

State the deal in one line, then ask the four questions (one at a time, follow the energy):

"I'll ask 4 short questions about your idea, then give you a one-page brief. ~10 minutes. Nothing leaves your machine. I won't ask how much time you have for the whole project right now — depth and time-cost are chosen after the brief, when you have data to choose."

1. (one sentence, hard limit) "What are you trying to build, and for whom?"
2. "Tell me about the last time someone in that group hit the problem you're trying to solve. What did they actually do?" (Torres past-behavior — not "would they want X")
3. "If you had to bet on one thing being wrong about this idea, what would it be?"
4. "What's the smallest move you could make this week to find out?"

Format constraint discipline (per ht-012 cohort-log f4, shipped v0.23.21): the format spec (e.g., "one sentence") MUST appear before the question text and as a bolded mechanical constraint, not as a prose prefix that can be read as a rhetorical politeness. The "In one sentence, X?" framing was misread as "succinctly, X?" — the user answered in 2-3 sentences before discovering the constraint was hard. Render format specs as parenthetical or bolded prefixes; do not rely on prose to carry the constraint.

Phase-index narration discipline (per ht-012 cohort-log f9, shipped v0.23.21): the Phase 1–6 structure below is internal skill organization. Do NOT narrate phase numbers ("Phase 4 Landscape", "Phase 6 product-type") to the user. When routing or referencing a later step in user-facing output, use the outcome label ("we'll explore the landscape next", "the project-type question comes later"). Same discipline applies in /mycelium:diamond-assess and any skill that surfaces routing decisions.

After Q4, in this exact order:

Step 1 — Render the brief FIRST (before any tool calls)

Output the brief markdown to the chat. This is the visible payoff and it MUST appear before canvas writes — Claude Code clutters the TUI with tool-call blocks if writes come first.

# Brief: <one-line idea name>

## Who it's for
<one paragraph synthesizing Q1+Q2 in JTBD shape: who they are, what job they're trying to get done, what they do today>

## Biggest assumption
<one paragraph from Q3, ending with: "This is risky because…">

## Biggest risk
<one of: value | usability | feasibility | viability — Cagan's lens, named in plain language without using "Cagan" or "four risks">

## Your next concrete move
<one paragraph sharpened from Q4: what to do, what you'll learn, when you'd know>

Step 2 — Side-effect canvas + decision-log writes (after brief is rendered)

Hard requirement: all FOUR files below must be written before Step 3. This is not optional or "best-effort" — downstream skills (/mycelium:diamond-assess, /mycelium:jtbd-map, /mycelium:ost-builder) AND the auto-dogfood verification all assume the brief flow produces this complete artifact set. The brief flow's "10-min first value" promise IS this four-file write.

Read+Edit in parallel where possible (one tool batch for Reads, one for Edits) to minimize TUI noise. Order does not matter, but ALL FOUR must land:

• (1 of 4) .claude/harness/decision-log.md — APPEND a minimal entry naming the brief's substance. Do NOT defer to the "After the Interview" section below; that section EXTENDS this minimal entry, it does NOT replace it. If you skip this write, the audit trail has a hole for any user who stops after the brief (which is most of them). Format (literal — do not paraphrase the section headers):

  ### YYYY-MM-DD - Interview brief: <Q1 idea name>
  - **Decision**: Conducted 4-question brief on <Q1 idea name>. Purpose, JTBD-functional, and biggest risk captured. Tagged as internal_stakeholder evidence pending external validation.
  - **Theory**: Sinek (purpose), Christensen (JTBD-functional from Q1+Q2), Torres (riskiest assumption from Q3), Cagan (four-risks classification on Q3).
  - **Evidence**: User-supplied Q1-Q4 answers (paraphrase Q1+Q3 in 1-2 sentences each, mentioning the project name and the user's own words about what they're building).
  - **