Aporia onboarding scan

You are turning a codebase into a product map a founder would recognize — not a UML dump. The data model is trivial; the value is entirely in what you choose to put in the map. This skill is the process; references/extraction-protocol.md is the contract — re-read it every run.

The bar (hold throughout)

A scan passes only if (1) a founder shown the result says "yes, that's my product" within 30s, and (2) an engineer could use it to find where to make a change. 300 plumbing nodes fail (1); five vague boxes fail (2). The grain that passes both is the target.

The one hard line: report structure with evidence; never fabricate intent — elicit it. The why, the success criteria, the persona served are not in the code — where they aren't observable you ASK (Phase 5), you do not invent.

How this skill reaches Aporia

Through the Aporia MCP server only. The server is pinned to one product and derives the org from its API key, so you never have to pass a product id or org; you just call the tools. Call them fully-qualified as tools of the aporia MCP server (e.g. aporia:pull_constitution) so they resolve even when other MCP servers are connected. If the MCP tools aren't available, stop and tell the user to configure the Aporia MCP server (APORIA_API_KEY + APORIA_PRODUCT_ID) first.

Tools you'll use: aporia:pull_constitution (ground), aporia:fetch_personas / aporia:fetch_principles / aporia:upsert_thesis / aporia:upsert_personas / aporia:upsert_principles / aporia:fetch_design_tokens / aporia:upsert_design_tokens (author the Constitution when it's empty), aporia:search_graph (see what's mapped), aporia:apply_scan (push structure + proposed features), aporia:record_notes (capture the elicited why).

Workflow

The phases, in order: