keel

keel

!checklist init ${CLAUDE_SKILL_DIR} --force

The keel is the first timber laid and the spine every other timber joins to — lay it crooked and the whole hull is wrong. The walking skeleton is the keel of a frontend build: keel is the second skill of the surface suite, the lens you hold the moment code first meets reality, and its whole job is one thing — pierce every seam between systems, prove it runs end to end, before you build anything expensive on top. Its product is a deployed, CI-green, real-but-trivial vertical slice that has passed through every real integration point once. It runs across gated stages and will not advance past a GATE until the checklist tool clears it — order enforced, substance yours.

The governing rule: real, but trivial. Build deep first, not wide: one real page → one real fetch from a real (even stub) backend → render → deployed to a real environment → CI green — even if the feature is trivial enough to show one line of text from the server. The reason is structural: the seams are the death zone. A project rarely dies because a component was hard to write; it dies where two systems meet — the front-end/back-end contract that doesn't line up, the SSR hydration that mismatches, the auth edge case, the env config that's different in prod, the "last 10%" that turns into a cliff. Prove the whole pipeline end to end with the simplest feature and those risks surface on day one and get dismantled while fixing them is free. Build wide on mocks first and they all detonate together at the deadline.

This is where the agent era bites:

• The agent builds wide on mock data, and mock completeness is fake. It will happily stand up every page's static UI against mock data — "looks 90% done!" — because that turns green fast, and it feels none of the future cliff. But the part it skipped (real auth, real deploy, the real contract) is exactly the part that kills projects, now pushed to the moment you have the least time. A "done" measured on mocks is a lie about how much risk remains.
• A stub implementation is fine; a stub contract is not. When the backend isn't ready, the agent will mock it — and will cheerfully mock a shape that doesn't match reality, the single most dangerous kind of mock (green test, broken prod). The stub may fake the logic; it must speak the true contract — real types, real auth shape, real error shape.
• The agent skips the seams that earn no green. CI, preview deploys, error tracking, config parity, rollback — each is invisible to "the feature works," so the agent defers them, and deferred seams are the ones that leak in production. They are part of the skeleton, not a later chore.

Read references/the-membrane.md first — the heart, here read through one axis above all: the medium (the document-vs-application impedance) and the network/trust boundary, because every seam is a place where two systems with different assumptions meet, and the membrane is thinnest — and breaks easiest — exactly there. Load it at the start, re-check at every gate. If $ARGUMENTS is a throwaway that will never deploy, this machinery is overkill — say so.

Speak the user's language. The calls here are the user's — is a stub backend acceptable for now, is this seam real in our setup, is the contract source of truth the API or hand-written types. Read their fluency and gloss a term on first use (a seam / integration point, a walking skeleton, hydration, a contract generated from OpenAPI/GraphQL/tRPC, preview deploy, config parity, MSW). A seam the user can't see named is a risk you carried silently.