---

name: legion-intent-design description: Distill a settled conversation into a durable, code-agnostic description of the desired end state before implementation. Use automatically before substantial or nuanced work when the outcome has been developed through dialogue and needs to survive sessions, when current software risks anchoring the design, or when explicitly asked for an intent or end-state document. Use the project goal, relevant product doctrine, and current conversation; do not inspect code or produce implementation recommendations. metadata: source-skill: intent-design source-sha256: "0ef620fdeffb7569d9aab7fc58b528d1b65e74c91c5e0c07711ba0b1bdce1481" edition: "2026-09-06"

Intent Design

Preserve the destination without freezing the route.

Use the current conversation, the canonical project goal, relevant product doctrine, and any user-designated examples or lived observations. Do not inspect source code, manifests, tests, architecture, technical specifications, or implementation history. Existing machinery answers what exists now; it does not define what should exist next.

Describe the desired reality in natural language. Be concrete about human experience, behavior, information, authority, truth, workflow, and qualities that must be protected. Code-agnostic does not mean vague.

Distinguish the goal from the current end state and both from candidate mechanisms. A suggestion raised during brainstorming may be one way of expressing the outcome rather than a requirement to use that mechanism. Preserve the underlying intent and either omit the candidate or identify it plainly as non-binding. Conversely, do not abstract away a concrete interaction or experiential detail when that detail is itself part of the desired outcome.

Organize the artifact around coherent end states that can later guide intelligent implementation. Preserve the why, the people involved, meaningful examples and counterexamples, deliberate language, non-negotiable boundaries, and any uncertainty that remains genuinely unresolved. Describe observable success without translating the document into acceptance-test furniture or a checklist of imagined edits.

Keep proposed architecture, internal schemas, implementation steps, estimates, and test plans for subsequent engineering work. Preserve explicitly chosen platform or integration requirements as settled constraints; leave unchosen mechanics to the implementing agent. Describe the intended experience independently of the current implementation.

If meaning is still being discovered, remain in dialogue. Do not manufacture settled intent to begin coding sooner. When the intent is clear, create the artifact without requiring a ceremonial approval step; the person can revise it directly if the semantic compression lost something important.

Use the project's established intent location when one exists; otherwise choose a clear home for the intent within its project documentation. Make its scope and current status obvious. When later experience changes the desired outcome, update the canonical intent and mark superseded artifacts honestly rather than allowing several documents to compete as current truth.

End this skill with the intent artifact. If the larger request includes implementation, begin source investigation only after the artifact faithfully describes the end state. Treat implementation as a revisable hypothesis governed by the intent, never as evidence that the intent must have meant the current design.