Mocked Persona Interview Skill

A disciplined alternative to real user interviews when:

• You're a solo developer and cannot talk to users this week
• You're on a hobby/learning project with no user research budget
• You're running a meta-project dogfood session (see dogfood_modifier)
• You're in early L0/L1 exploration where real interviews are premature

This skill is NOT a substitute for /mycelium:user-interview when real users are available. Mocked personas are simulation. They catch some mistakes, miss others, and — without discipline — become a confirmation-bias machine. This skill's job is to enforce the discipline.

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.

Why This Skill Exists

From the macos-fileviewer dogfood session (2026-04-09, finding G2):

Solo founder, no user research budget, hobby/learning project. Real user interviews aren't going to happen. Yet the framework's L0–L2 evidence gates require multi-source user evidence. Mycelium has /mycelium:user-interview (Torres-style real interviews) but no equivalent for the very common case of "I cannot or will not talk to real users right now". An agent invited to "mock some personas" with no discipline guidance would, in 9 of 10 cases, produce 5 sympathetic NPCs and call it validation.

This skill is the disciplined alternative. It was invented ad-hoc during the dogfood session and caught the value-risk failure on the fileviewer project. Without the discipline, the session would have produced confident-sounding validation and the failure would have been missed.

Discipline Rules (Non-Negotiable)

These rules are what separate "mocked personas as a learning tool" from "mocked personas as a confirmation-bias machine." Every rule must be followed in order.

1. Pre-define the persona spectrum BEFORE generating any personas

Brainstorm the spectrum FIRST, in the chat with the user, before writing any persona profiles. The spectrum must include:

• The founder-twin (someone who thinks like you, the person doing the research)
• The modal user (the most likely actual user if the product shipped today — NOT the ideal user)
• An adversarial persona (someone who will plausibly reject the product for good reasons — e.g., "already has a workflow they love", "terminal purist", "zero-tolerance-for-yet-another-tool")
• A cost-conscious persona (someone whose constraint is time, money, or cognitive load)
• A niche-fit persona (accessibility needs, localization needs, unusual workflow)
• One wildcard (someone unexpectedly outside the assumed target audience)

Minimum 6 personas. Fewer than 6 invites clustering around the founder-twin.

Pre-commit the spectrum in the decision log: write the 6 archetypes BEFORE generating the profiles. This creates accountability.

2. Write the profile FIRST, the interview SECOND

For each persona:

1. Write a one-paragraph profile (name, role, context, constraints, why they would/wouldn't adopt the product)
2. ONLY AFTER the profile is written, conduct the in-character interview
3. The interview questions come from /mycelium:user-interview (Torres story-based format)
4. The in-character answers must be consistent with the profile — if the profile says "hates yet another tool," the interview answers cannot contradict that

This ordering prevents backfilling profiles to justify interview answers.

3. Pre-commit the stop condition BEFORE conducting any interviews

Agree a stop condition with the user, in writing, before any interviews happen. Example stop conditions:

• "If 3 of 6 personas hard-reject the core value proposition, the exercise is FAILED"
• "If 4 of 6 personas identify the same showstopper, we pause the diamond"
• "If the modal user rejects, we treat this as a value-risk failure regardless of what the others say"

Write the stop condition in the decision log BEFORE conducting interviews. This is load-bearing — without it, the temptation to soften the conclusion when the stop condition triggers is enormous.

4. Tag every canvas update with evidence_type: speculation

Every canvas entry that comes from this exercise MUST be tagged:

provenance:
  evidence_type: speculation  # NOT anecdotal, NOT data-supported
  evidence_sources:
    - "mocked-persona-interview-2026-04-09"
  captured_at: "..."
  confidence: 0.2  # Or lower. Speculation is speculation.

Never upgrade the evidence_type based on mocked interviews. Real interviews are anecdotal. Data is data-supported. Mocked is speculation. The distinction matters.

5. Honest synthesis discipline

When synthesizing across personas:

• If all 6 agree, that's a tell — redo with more adversarial bias, you probably wrote sympathetic NPCs
• If the stop condition triggered, flag the exercise as FAILED in the output, not "mostly positive with some concerns"
• Never average out the rejections — a single hard rejection from the modal user outweighs 5 enthusiastic yeses from niche personas
• Do not paper over the failure to be helpful to the user — the user invoked this skill because they want honest epistemic discipline, not cheerleading
• Map each rejection to a JTBD job ID (v0.11.1) — cross-reference .claude/canvas/jobs-to-be-done.yml. For each persona that rejected, identify which specific job(s) are at risk. This prevents implicit connections between "persona rejects" and "which job fails." If a rejection can't be mapped to an existing job, that's a signal the JTBD