penpot-router — the dispatcher

1. Title + How it works

penpot-router is a thin entry point. It does not draw, tokenize, or restructure anything — it reads the user's intent and hands off to exactly one downstream skill or workflow. Every mutation goes through execute_code; validate visually with export_shape; read structure with penpotUtils.shapeStructure (full tool surface: shared/penpot-mcp-tool-reference.md). This skill only ever uses high_level_overview plus read-only execute_code discovery calls (penpotUtils.shapeStructure, penpotUtils.tokenOverview()). Every mutation belongs to the skill it routes to; this router validates nothing visually because it changes nothing. If the host client already auto-selects skills by their description, this router degrades gracefully to documentation — the intent taxonomy in references/01-intent-taxonomy.md becomes a reference map rather than an active dispatcher.

2. The One Rule That Matters Most

Route to exactly one target, and run preflight before doing so. Never start mutating from inside the router, and never fan a single request out to multiple mutating skills in parallel. One request → one preflight (overview + a quick structure/token read) → one target skill or workflow → handoff. If intent is ambiguous between two targets, ask one disambiguating question; do not guess and act.