personas-writelisted

# personas-write Specs in this standard are written against named personas, so a repo with no roster writes specs against "the user" - and "the user" wants everything, which is why those specs never settle anything. ## Where the names come from Ask which of these the repo actually has, because the work differs completely. - **Real users the team knows.** Interview - below. Best case. - **Nobody remembers / nobody asked.** Reconstruct **candidates** from evidence: roles in the auth model, permission tiers, distinct entry points, admin surfaces, differently-shaped API consumers, support tickets if present. Present them as candidates to confirm or reject, never as findings. The code shows who the system was built for, which is a good hypothesis and not the same thing as who uses it. - **Only a founder's intuition.** Write it, mark it, and say plainly that it is untested. An honest guess labelled as one is usable; a guess dressed as research is not. **A repo may legitimately have one persona.** Do not manufacture a roster for symmetry - three thin personas are worse than one real one, and they will produce three thin specs. ## What to ask for, field by field `docs/personas.md` fixes the fields; this skill decides how to ask for them. Do not invent a field the template does not have, and do not skip one because the user did not volunteer it - a persona missing its anti-goals is the one that gets gold-plated for. - **Who / context** - role, environment, tech comfo