# Sample: Roast my README

Synthetic focus group for Pi Troupe README. Not real user research.

## Panel

- **Impatient Hacker** — AI power user, demo-driven, direct.
- **Skeptical Engineer** — security-minded developer, wants boundaries and data-flow clarity.
- **Indie Builder** — solo product builder, wants fast landing-page/pricing/docs feedback.
- **OSS Maintainer** — docs/package maintainer, wants provenance and ecosystem fit.

## Transcript excerpt

**Moderator:** “You read the README. What do you think Pi Troupe does?”

**Impatient Hacker:** “I get it fast: simulated people roast my stuff before I waste time. That is useful. But the README buries the dopamine. Show me one command, one output snippet, one ‘ouch, that helped’ example immediately.”

**Skeptical Engineer:** “The value proposition is clear enough, but the trust model is thin. You say local artifacts exist, but not what is sent to the model, where images go, or how logs can be cleaned. For a simulation tool, data handling is not a footnote.”

**Indie Builder:** “This is aimed at me. Landing pages, pricing, docs, onboarding tests — that is exactly the pre-build feedback loop I want. The phrase ‘before you spend time building the wrong thing’ lands well.”

**OSS Maintainer:** “The TinyTroupe comparison helps, but it needs sharper boundaries. Is Pi Troupe a port, wrapper, alternative, or Pi-native workflow inspired by the same pattern?”

**Moderator:** “Would you install it? What blocks you?”

**Impatient Hacker:** “`pi install npm:pi-troupe; pi` is admirably short. But I want proof before setup. Put sample output near the quickstart.”

**Skeptical Engineer:** “I would not run it on private docs until safety is explicit. Add ‘what leaves your machine,’ ‘where artifacts are written,’ and ‘how to avoid secrets.’”

**Indie Builder:** “The feature list is strong, especially share cards and survey exports. But I need examples by job: test pricing page, compare ads, roast README.”

**OSS Maintainer:** “The Pi subscription/config angle is the biggest differentiator. Make it a headline: no separate API-token plumbing, model config reuse, Pi-native install and commands.”

## Findings

- Core idea is understandable: LLM-powered simulated personas for feedback before real research.
- Strongest line: “surface risks before you spend time building the wrong thing.”
- Install command is concise, but quickstart needs visible payoff.
- Feature list is credible, but examples should be grouped by workflow.
- TinyTroupe relationship is useful, but should say “inspired by,” not fork/wrapper.
- Pi subscription/config benefit matters; do not bury it.
- Safety disclaimer is good, but operational privacy details need more prominence.

## Recommended README changes

- Add sample output from `roast-my-readme` near the quickstart.
- Promote Pi-native advantage: existing Pi models/config/subscription.
- Add privacy/safety box: inputs, outputs, artifacts, model calls, local paths.
- Reframe features around workflows: docs, pricing, ads, onboarding, surveys.

## Limitations

Synthetic panel. Useful for critique and hypothesis generation, not evidence of real user behavior.
