bearings

bearings

!checklist init ${CLAUDE_SKILL_DIR} --force

Before you sail you fix your bearings — and stage zero of a frontend build is the same: it writes no business code, yet it decides the project's fate, because it is where the decisions that are brutal to reverse once written get made while there is still no sunk cost to fight. bearings is the first skill of the surface suite — the lens you hold over a frontend product before the first line. Its product is five one-page artifacts — a journey map, a perception contract, a source-of-truth table, a rendering decision, and an objective-function charter — that every later stage (keel builds the skeleton against them, wellspring refines the source-of-truth table into the full state classification) honors. It runs across gated stages and will not advance past a GATE until the checklist tool clears it. That gate enforces order — each decision made before the next — not the substance of the judgment inside it; the rigor is yours to supply.

Three ruling principles govern every call downstream — internalize them first. (1) Boundaries > frameworks. The framework is the most-discussed and least-durable decision you will make — it gets swapped, and behind a clean boundary the swap is cheap; the boundaries themselves (the network/trust line, the classification of state, the split of modules) are discussed least and fossilize into the foundation. The novice spends 80% of the deliberation on React-or-X; the master treats that as a two-hour reversible call and spends the judgment on the boundaries. (2) Allocate caution by reversibility. Decisions are one-way doors (data model, rendering architecture, network boundary — expensive to walk back) or two-way doors (a color, a component's internals — revert anytime). Most analysis-paralysis is one-way-door caution misapplied to a two-way door. Go slow and deliberate on the one-way doors; go fast and cheap on everything else. (3) The source of truth lives in the user's mind, not the database. Model how the thing works in the user's head — and what "feels right" means — first, then make the data structures serve that model, never the reverse.

This is where the agent era bites hardest, because the spec is not in any document. Frontend is the one discipline whose correctness benchmark is a wet human nervous system — 16ms is a fusion threshold, 100ms is "I touched it directly," not an SLA — so a piece of "correct" here can never be checked against a formal spec, and taste is load-bearing: it cannot be outsourced to the agent, which has no access to the brain on the other side of the membrane. As the agent writes more of the code, the cheap part — typing — devalues, and the leverage migrates to the membrane: which boundary, whose source of truth, what causal story forms in the user's head, and whose interest the optimizer serves. Left alone the agent will pick the popular framework, model the database instead of the mind, skip the one-way-door decisions because they earn no green, and never set an objective function — so every one of those must be decided and gated here, on paper, before the dashboard exists to pull you.

Read references/the-membrane.md first — it is the heart: the seven axes (state, identity, the two graphs, scope, medium, mind, ethics) that the whole suite rests on, each reframed for a world where the agent writes the code and is blind to the reader on the far side. Load it at the start and re-check the relevant axis at every gate. If $ARGUMENTS is a genuine throwaway — a prototype that ships nothing and dies in a week — this machinery is overkill; say so. The bar is sized to how long the thing must live.

Speak the user's language. Almost every call here is a trade-off the user owns — is realtime worth the architecture it forces, is this the right north-star, is this default honest. Read their fluency and gloss a term on first use (a one-way door, JTBD, the perception contract, source of truth, SSR/SPA/RSC/islands, an objective function, a guardrail metric, the reflective vs impulsive self). A decision the user can't evaluate is an architecture imposed, not a judgment shared.