---

name: legion-spec-design description: Design a lightweight coordination spec for multiple independent workers executing genuinely separable implementation packets concurrently. Use when concurrent work needs durable shared intent, ownership, interfaces, dependencies, collision boundaries, and an integration plan. Do not use as the default planning step for substantial work, for sequential single-agent implementation, or to discover or manufacture product intent. metadata: source-skill: spec-design source-sha256: "2ae7aa88fe3a4d2f28d477214761df37f0e8e6bbf4aec765ad45a2411a4862b3" edition: "2026-09-06"

Spec Design

Create a map of seams, not a script of steps.

A coordination spec exists so independent intelligent workers can exercise local judgment without developing incompatible understandings of the larger work. It does not replace the controlling intent, predict implementation, or translate an intelligent worker's task into a checklist.

Use an existing settled intent as the destination. Reference it rather than rewriting it into technical language. If the intended reality is still being discovered, remain in dialogue; concurrency would only multiply an unresolved assumption.

Let concurrency earn its cost

Parallelize only where the work has genuine seams and independent progress creates a meaningful benefit. Keep closely coupled discovery, central architecture, and decisions whose answers reshape every packet under one owner until those seams become real.

Inspect current source only enough to establish truthful boundaries, shared contracts, dependencies, and likely collisions. Do not perform each worker's investigation in advance or summarize local mechanics the worker can understand more accurately from current source while implementing.

Preserve alignment without prescribing implementation

Give every worker enough context to understand the whole capability, its bounded contribution, and the assumptions it must not silently change. Make clear:

• the controlling intent and how the packet contributes to it;
• the outcome and responsibility the worker owns;
• shared truths, interfaces, invariants, or data that must remain compatible;
• dependencies on other packets and what may be assumed about them;
• ownership and collision boundaries, including decisions reserved for another worker or the integrator;
• what evidence will let the integrator determine that the contribution is real;
• who owns integration and any ordering that is genuinely required.

Describe ownership by capability, responsibility, and canonical truth. Mention files or code surfaces only when doing so prevents real collisions or identifies an established contract. Do not prescribe algorithms, call sequences, file lists, internal architecture, or anticipated edits unless that exact shape is itself a shared constraint.

Assume each worker is an intelligent engineer. Let the worker inspect its surface, choose local mechanics, revise weak existing abstractions, and respond to evidence. A discovery that remains local belongs to that worker's judgment. A discovery that changes shared intent, an interface, another packet's assumptions, or the validity of the decomposition must return to the integrator rather than being silently resolved inside one packet.

Keep integration whole

The primary agent retains responsibility for the capability as a whole. Parallel completion reports do not establish integrated success. Reconcile the contributions against current source, shared contracts, and the controlling intent; resolve contradictions; and judge the resulting system in the reality where it will be used.

Treat the coordination spec as active working state, not a second source of product truth or a permanent architectural authority. Update it when cross-packet reality changes, and retire it when integration is complete. Preserve consequential decisions in the artifact that properly owns them rather than leaving the completed spec to govern future work.