Aporia persona mapper

This skill turns a vague idea of a customer into one typed Persona in Aporia's living map. A persona here is a real person caught in a real struggle, not a demographic sketch — modern practice moved away from "35-year-old, likes apps" toward behavior, motivation, and the moment a problem bites, because age and income don't explain why someone adopts a product; a struggling moment does. Every field must help a team or an agent make a decision, or it doesn't belong.

In Aporia a persona is Ring 0 — part of the Constitution (the why: thesis, principles, personas). It is the lens every feature is judged against, and features bind to it by id (relatedPersonaIds). That makes it the most human-owned layer in the system, so it is authored only through a human interview — you map their answers to the typed record; you never invent one.

You reach Aporia through the MCP server only. It is pinned to one product, so you never pass a product id — the server injects it. Call the tools fully-qualified as tools of the aporia server (aporia:fetch_personas, aporia:upsert_personas) so they resolve when other MCP servers are connected. If they aren't available, tell the user to configure the Aporia MCP server first.

The hard line

Never invent a persona — elicit it. If the human didn't establish a field, it isn't filled from assumption or from the code. The agent is the scribe in a human interview; the human is the author. No struggling moment, no persona — keep probing. (This mirrors aporia-onboard's rule: report structure with evidence, never fabricate intent.)

The data model (authoritative)

Map to exactly these fields — the Persona record in Aporia's data model. Enums are closed; reject any value outside the set. Field names are camelCase (the wire contract).