Why it has to be consistent

Putting the spec in the repo only helps if an agent can count on what it finds there. A different shape every time is no better than a ticket — the agent still has to guess where the goal is, what's out of scope, how "done" is defined. Consistency is what turns a folder of docs into something an agent can build from reliably.

So the bet demands three things, and they're the whole of what Specline provides:

• One fixed shape. Every feature is the same folder with the same files and the same sections, in the same order. Read one, you can read them all — and so can the agent. The sameness isn't tidiness; it's what lets the builder find the goal, the scope fence, and the acceptance bar in known places every time.
• A checker — Specline. A consistent shape is only real if something keeps it honest. Specline reads the spec's structure — never your code, never a model — and answers one question: does this spec have everything an agent needs to build it? It blocks only when the spec is structurally broken (no spec.md, a dangling link, a duplicate ID); a merely thin or half-formed spec it flags as advice and leaves the call to you.
• An assistant. You shouldn't have to memorize the shape. An agent that knows the methodology helps you write the spec and checks its own work with Specline as it goes — so producing a conformant spec is a conversation, not a form.

Shape, checker, assistant — together they make the in-repo spec dependable enough to hand to a builder. Specline's job is the planning phase: it guarantees the spec is answerable. It does not, and cannot, judge whether the built result is good — that comes later, from people and from review. Keeping those apart is the next chapter.