/mocked-persona-interview

name: mocked-persona-interview
description: "Use when real user interviews aren't possible (solo/hobby/dogfood projects) but persona work is still needed. Enforces epistemic discipline: adversarial spectrum, pre-committed stop conditions, speculation tagging. NOT a substitute for /mycelium:user-interview when real users are available."
metadata:
  instruction_budget: "70"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

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 -o "<prefix>-[0-9][0-9]*" .claude/canvas/<file>.yml | sort -u -t- -k2 -n | tail -3

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, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `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** (someon