loft

Imported from yeachan-heo/oh-my-claudecode (skills/loft/SKILL.md). Install upstream with npx skills add yeachan-heo/oh-my-claudecode --skill loft. Copyright stays with the author.

name: loft description: Loft the shape before cutting steel — answer a design question that prose cannot settle by building a throwaway artifact: a pure logic module in a clickable shell, or structurally different UI variants behind one route. The captain reacts to the artifact; the answer folds into the decision; the artifact never docks. Use when a design question stalls in words, when a navigator map carries a loft ticket, or when a spec discussion reaches "we would have to see it". level: 3

Loft

Cut no steel until the shape is fair. Shipwrights loft the hull's lines full-scale and fair them before a single plate is cut. Loft applies the same order to design questions: when words have run out — two plausible answers, neither falsifiable by talk — build a cheap runnable artifact, let the captain react to it, and fold that reaction into the decision.

The role contract. The crew builds the artifact; the captain's only job is to react — and that reaction is the decision. The artifact is an instrument for seeing, never a head start on the deliverable.

When to loft

• a design question stalls in prose: repeatedly rephrased, still not settleable ("how should the path page look", "does this state model feel right")
• a navigator map carries a loft ticket
• a spec discussion reaches "we would have to see it first"

Do not loft when:

• the question is answerable from repo evidence or by asking the captain (that is interviewing, not lofting)
• the destination itself is unclear (that is fog — /oh-my-claudecode:ask-navigator)
• the answer already lives in an ADR (do not re-loft settled decisions)
• the "design question" is actually a bug (that is the debugger's jurisdiction)

Choose the fork

Pick by what the question is asking. A wrong fork wastes the whole artifact.

Logic fork — is the model right?

For questions about state, business rules, data shape, or algorithms ("does unlocking regress on a retake?", "does this reducer hold at the edges?"):

1. Isolate the decision-bearing core — the state machine, reducer, schema, or algorithm — as a pure module: no DOM, no I/O, no framework. Written so that, once the shape is confirmed, it moves into the real codebase unchanged.
2. Wrap it in a single clickable HTML shell: one button per scenario, the tricky edge cases walked through in order, full state visible after every click.
3. On confirmation the module is ready to lift — it re-enters as real work through launch. During the loft itself main stays untouched and the shell stays behind on the branch.

UI fork — what should it look like?

For questions of shape and arrangement ("steps or cards?", "where does progress live?"):

1. One route, three variants that differ in structure — information architecture, navigation model, density. Variants that differ only in styling answer nothing: three reskins are wallpaper.
2. A switcher on the page cycles the variants; embed into the existing product where possible, so real data density stresses the design instead of three tidy fake rows.
3. On confirmation, the decision transfers and the variants stay behind on the branch as the record of why it looks this way.

The discipline

• One command to run — the repo's simplest existing serve command; inline the module into the shell if file:// module CORS would bite. Loads in seconds; no build step beyond what the repo already has.
• No persistence, no tests, no abstractions, no error handling beyond the happy path. The artifact should be something you would not want to ship — the rules exist to keep it that way.
• Expect the first shape to be argued with: revise on the branch within the same session. The captain confirming the final shape is the decision; an artifact nobody argues with usually answered a question nobody had.
• The artifact's whole life is minutes to build and one session to decide. If it starts growing into production code, stop: that work is a launch effort, not a loft. Sunk cost is the failure mode this skill exists to prevent.
• One loft answers one question. Two questions are two lofts — or one question that was actually two.

Fold the answer

The artifact is evidence, not a landing. When the captain reacts:

1. Record the decision where it lives — the issue comment, the spec's Implementation Decisions, or the pending-decision note — in the captain's own words plus one line of why. A fragment more precise than prose (the reducer, the state machine, the schema) may be inlined there, marked as lofted.
2. Push the artifact to a loft/<name> branch. It never merges: it stays as the primary source a future reader can open when the decision's "why" matters.
3. Nothing from the artifact lands in main — for the logic fork the confirmed module re-enters as real work through launch, for the UI fork the real page is built fresh from the decision.

Scope and non-goals

• Loft produces answers, not deliverables: no runtime, no state files, nothing always-on.
• It does not diagnose (debugger), does not chart fog (/oh-my-claudecode:ask-navigator), does not approve its own answer (the captain's reaction is the only acceptance).
• It does not replace seam approval: a lofted UI shows the shape; the test seams for it are still approved at C2.

Completion definition

The captain reacted, the answer sits where the decision lives, the artifact sits on its branch — and no line of the artifact is in main.