This is the practical piece: no theory, just the sequence of moves that takes you from nothing to a finished prediction report — and past the beginner mistakes we see most often. Total time for a first run: about half an hour, most of it thinking, not waiting.

Step 1: pick a question with a decision inside it

Open with a real choice you’re facing, not a curiosity. “What will people think of us next year?” gives the simulation nothing to bite. The shape that works is one decision, one audience, one time window:

Weak:   How will people feel about our changes?
Strong: If we paywall the export feature next month, how do our
        free-tier users react in the first two weeks — and does
        the reaction reach our paying customers?

The strong version names the trigger (paywall), the primary cast (free-tier users), a horizon (two weeks), and a specific fear worth testing (contagion to paying customers). Everything downstream inherits this sharpness.

Step 2: assemble a small, dense seed

Attach documents — PDF, Markdown, or plain text — that name the actors and their stakes. One focused page beats fifty generic ones. The five-minute version that covers most first runs:

  • The artifact itself. The draft announcement, changelog entry, or policy text, in its real wording.
  • A cast sheet. Every group or person who plausibly reacts: one line each with their role, what they want, and any relevant history.
  • One page of ground truth. A few real forum comments, reviews, or support tickets, so the tone of your community is in the room.

Why density beats bulk is its own article — knowledge graph seeding — but the short version: the graph is built from named actors and visible incentives, and unnamed context mostly evaporates.

Step 3: run it

Go to mirofish.us — the main MiroFish site — paste your question, attach the seed files, and start the run. MiroFish builds the knowledge graph, spins each node up into a persona agent, and lets the cast react to your trigger round by round on a simulated social surface.

While it runs, do the single most useful thing a first-timer can do: write down what you expect the report to say before you read it. Two minutes, three bullet points. The gap between your written expectation and the actual report is where all the value hides — without the note, hindsight will quietly convince you that you knew it all along.

If you want to preview the whole flow before committing, there’s a recorded end-to-end run on Bilibili, and a second video showing what comes after the report.

Step 4: read the report against your note

The report arrives in four parts — executive summary, risk signals, narrative paths, follow-up questions. Read it in reverse order of temptation: signals and paths first, summary last, so one confident sentence doesn’t anchor you before the texture arrives. The full field guide is at reading a prediction report; the one rule that matters on day one is that this is exploratory decision support — a rehearsal, not a prophecy.

Now compare against your pre-run note. Matches confirm instincts; mismatches are leads. Both are worth having in writing.

Step 5: interrogate, then iterate

The simulated world is still alive after the report, and the follow-up chat is where first runs become second-nature. Ask the questions your mismatches raised: which agent started the objection thread? what if the announcement had named the reason honestly? did anyone defend us unprompted? Answers come from the run you just watched, not from general knowledge.

Then iterate deliberately. Change one thing — the wording of the announcement, a group in the cast, the timing — and run again. One variable per run, like any experiment. Two or three iterations in, you’re no longer asking “what happens?” but “which version of this plan behaves best?”, which is the question the tool is actually for.

Common first-run mistakes, quickly

  • The encyclopedia seed. Fifty pages of background, zero named actors. The graph starves politely.
  • The verdict reading. Treating the executive summary as a forecast to bet on rather than reconnaissance to act on.
  • The lonely run. Running once and filing it away. The compounding value is in iteration and the follow-up chat.
  • The rigged question. Phrasing the scenario so only one answer is possible (“how much will everyone love this?”). Ask the version you’re afraid of.

Your second run, and the habit that compounds

The first run teaches you the interface; the second teaches you the method. Take the same scenario — don’t switch topics yet — and change exactly one input based on what the report showed you. If the report said the objection compresses into “they punished loyal users,” rewrite one sentence of your announcement to pre-empt that framing and run again. Now compare reports side by side: did the risk signal soften? Did a new one appear? That comparison, not either report alone, is the first genuinely decision-grade output you’ll produce.

From there, two habits are worth institutionalizing. Keep the pre-run note ritual from step 3 — a running document of expectation-versus-report gaps becomes, over months, a map of exactly where your team’s instincts are reliable and where they aren’t. And keep the cast sheet alive: every run’s seed teaches you something about who actually matters in your audience, and folding that back in means each simulation starts smarter than the last. The tool rewards accumulation; treat runs as entries in a lab notebook, not one-off questions.

Where to go from here

If you’d rather adapt than invent, the MiroFish scenario library has ready-made cards — setup, prompt, seed suggestions — for common situations. The engine itself is open source; the GitHub repository and its README cover running it yourself. And the conceptual companion to this walkthrough is how MiroFish works, which explains what each stage of the pipeline is doing while you wait.

Your first question is probably already in your head. Take it to MiroFish and let the crowd argue about it before the real one does.