원클릭으로 Manus에서 모든 스킬 실행

loft-codegen

스타6

포크0

업데이트2026년 6월 25일 06:17

The discipline for ANY loft compiler/codegen work — fixing a store-lifetime or codegen bug, adding/altering bytecode, parser IR, the interpreter, or the native generator, or implementing a language feature that emits ops — OR restructuring any of those without meaning to change what they emit (extracting a selector, folding a special case, deleting a redundant condition). USE THIS the moment you are about to edit src/parser/, src/state/codegen.rs, src/fill.rs, src/generation/, src/compile.rs, or scopes.rs to change OR reshape what code is emitted — ESPECIALLY when a fix looks obvious and you're tempted to "just patch the generator and run the suite." The one load-bearing instrument is the same in both modes — `loft introspect` on BOTH backends BEFORE you touch the compiler — but the gate flips: a BUG FIX proves the WORKING bytecode standalone beside the broken one; a behaviour-PRESERVING REFACTOR proves the emitted IR + native Rust BYTE-IDENTICAL before/after. Skipping it is how codegen work flails and regres

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

loft-lang

loft-lang/loft

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

loft-codegen — Prove the Working Bytecode First

The one gate (do not pass it)

Do NOT edit the compiler until you have the WORKING bytecode/IR for THIS situation, captured beside the current/broken bytecode, and proven correct on BOTH backends (--interpret AND --native).

This is the step that, skipped, wrecks codegen work. The proof is cheap (a /tmp source shape + loft introspect + a run on each backend); skipping it is what costs hours. A patch to src/generation/ or gen_set_* written before you can point at the exact ops you intend to emit is a guess — and guesses in codegen regress the suite, because every new shape needs another condition and the conditions interact.

The anti-example (internalize it): @PLN85 probe 05 was fixed correctly — working bytecode proven standalone (bytecode-comparisons/ rungs, the hand-correct a:vec=[]; a+=enc() form) → types → codegen → clean on both backends. Probe 04 was NOT — a parser change went in with no working IR proven first; it regressed loft_suite and never closed the case. Same method, opposite outcomes. The difference was this gate.

The method — bytecode → types → code, smallest scale first

Bytecode first (the target, proven). Write the minimal case. Capture the WORKING bytecode/IR beside the current/broken one for the same situation — loft introspect prog.loft, or LOFT_LOG=static. The diff IS the spec. Get the working form from a hand-correct SOURCE shape (or hand-write it), so it's a real runnable artifact, never a guess. Prove it on BOTH backends before any compiler edit. Save the pair (e.g. under a plan's bytecode-comparisons/).
- Static dumps don't show runtime identity (stack-ref vs owned heap). When the two IRs look identical but behaviour differs, the fault is value-delivery — reach for LOFT_LOG=ref_debug / LOFT_TRACE_*, not another static read.
Types next (make the target OBVIOUS). What must the type carry (ownership / transfer-vs-borrow, nullability, layout) so codegen reads ONE clear fact and emits the working bytecode mechanically? If the types already carry it → no type change. If not → that gap is the type change, and it lands before the codegen change.
Code last (translation, not re-derivation). Codegen reads the type fact + the parse-tree node and emits the ops. Local translation logic is fine; the red flag is codegen re-deriving a non-local fact (the has_ref_params && … && … shape) — that fact belongs back in step 2.

Then validate at this scale on both backends (correct result · clean exit · no leak via LOFT_STORES=warn / LOFT_NATIVE_LEAK_CHECK · suite) and grow: minimal → bigger → full functions, comparing working-vs-broken at each rung.

Mode B — behaviour-preserving refactor (flip the gate to before/after)

Steps 1–3 above are the BUG-FIX mode: the reference is the working bytecode, the diff against broken is the spec. When instead you RESHAPE emitting code that should emit exactly the same ops — extract a selector, fold a special case into a cell, delete a redundant condition, route two sites through one dispatch — the same instrument (loft introspect) stays, but the reference flips: the gate is a byte-identical before/after diff, and an EMPTY diff is the proof.

Build a one-fn-per-path corpus FIRST. Write one .loft file with one small function per code path the change touches (each delivery/emit branch), plus a main that runs them all so the file is also a clean end-to-end check. This is what makes the diff exercise the branches you restructured — a corpus that misses a path can't catch a regression in it. Save it under the plan's bytecode-comparisons/.
Capture BEFORE. loft introspect corpus.loft > before.txt (it carries the IR
- bytecode AND the native Rust, so one capture covers both backends). Confirm the corpus runs clean on --interpret and --native (LOFT_STORES=warn / LOFT_NATIVE_LEAK_CHECK).
Refactor, then prove AFTER == BEFORE. loft introspect corpus.loft > after.txt; diff before.txt after.txt — empty means you changed nothing emitted, on both backends, which is the whole claim of a behaviour-preserving refactor. Re-run after cargo fmt (it touches the file). One commit per sub-step; if the diff is non-empty and you didn't intend it, that line is the bug — bisect by sub-step, don't push through.

When a refactor SURFACES a real behaviour change (a latent bug shows up mid- collapse — e.g. a leak the old structure hid): the two gates run TOGETHER. The byte-identical corpus proves "I changed nothing on the paths I didn't mean to," and a boundary matrix (the engineering-rigor skill) proves "the path I did mean to change is now correct" — value + length + leak on both backends, not leak alone (a delivery that doubles a vector reads as leak-free; only a length/value check catches it). Keep the corpus byte-identical for the untouched paths even as the matrix cells change.

Worked example: the @PLN85 D-own-1 block_result collapse — doc/claude/plans/85-store-lifetime-retirement/bytecode-comparisons/D-own-1-corpus.loft is the corpus; the collapse stayed byte-identical step by step, and the two leaks it surfaced (c5, h4) were closed under the matrix.

The diagnostic

Complex deduction in codegen (accumulating conditions to recompute ownership / nullability / layout per site) is a SYMPTOM of a missing type fact — fix the type, not the generator. But don't over-correct into a 1:1 type→codegen map: facts in types, translation in codegen. Test: would this be a simple read if the type carried one more fact? Yes → the fact belongs in the type.

The both-backends rule

Interp (src/state/codegen.rs → bytecode) and native (src/generation/ → Rust) are separate generators reading the same IR. A rung is closed ONLY when BOTH emit the proven bytecode and pass (correct + clean + no leak). An interp fix that breaks native compile is NOT landable. When they diverge on the same IR (one clean, one wrong/E0425), that divergence is the bug — neither "the suite is green" nor "interp works" closes it.

Stop conditions (revert, don't push through)

You're editing the compiler but cannot point at the working bytecode you intend to emit → STOP, go do step 1.
A change makes one backend pass and the other regress/hang/crash → revert; it is not landable.
The patch is growing per-shape conditions → the fact belongs in the type (step 2).

Anchors

Keep git diff main a usable codegen compass — ONE branch held close to main, rebased on origin/main often (the engineering-rigor skill § "Keep git diff main usable"); a diverged branch loses the working-vs-broken comparison this method depends on.
CODEGEN_METHOD.md — the full method
OWNERSHIP_MODEL.md — deps as loft's borrow checker (the north star for store-lifetime work)
Worked example + rungs: doc/claude/plans/85-store-lifetime-retirement/ (bytecode-comparisons/, type-ownership-design.md); probe 05 = method followed (clean), probe 04 = method skipped (regressed) — read both
DEBUG.md § Introspection CLI — loft introspect / LOFT_LOG
DESIGN/diagnosis siblings: the engineering-rigor and design-protocol skills

이 저장소의 다른 Skills

같은 저장소

draw

loft-lang/loft

Make a considered image or 3D scene from a described intent the iterative-craft way — block in, render, measure, critique against the intent, refine across passes — instead of trying to emit a finished result in one shot. Use this whenever the user wants to DRAW, sketch, illustrate, depict, compose, or paint a 2D picture, OR model / build / lay out a 3D scene, asset, or environment (e.g. a game prop, a room, a character, a landscape), ESPECIALLY when they give a subject, a mood, or a composition to hit ("an old woman at dusk", "a cosy tavern interior", "a low-poly pine tree", "make it feel ominous"). Also use when iterating on or critiquing such an image/scene. Reach for it even if the user doesn't say "iteratively" — the loop is the point, and one-shot guessing is what it replaces. Do NOT use for text-to-image prompts handed to a diffusion model, for charts / plots / diagrams / dashboards (data visualisation), or for UI / web layout.

2026-07-246

loft-write

loft-lang/loft

Reference for writing correct loft code. Apply whenever writing, editing, or reviewing .loft files. Covers types, syntax, known bugs, workarounds, naming rules, and error→fix table.

2026-07-246

loft-plan-workflow

loft-lang/loft

Procedures for plan-shaped work — opening a plan, closing/deferring one, promoting a doc to a plan, choosing the lightest workflow, applying value categories. Apply when the task involves plans, plan directories, a roadmap, or doc-to-plan promotion. The method is tree-agnostic; the concrete paths/templates/tracker that bind it to this repo live in one § at the bottom. Cites source docs for definitions; does not restate.

2026-07-236

engineering-rigor

loft-lang/loft

The shared discipline for any non-trivial change — fixing a bug OR designing/refactoring a load-bearing algorithm. USE THIS when about to fix a non-trivial bug (crash, silent corruption, wrong result), design or refactor a load-bearing algorithm (core representation, runtime, memory, codegen, a public contract or data format), when a change feels fragile or "longer than expected for what it does", or when reaching for an approximation in an exact-invariant domain (geometry, caching, hashing, round-trips) and can't pin the exact construction — ESPECIALLY when a fix already looks obvious (that's the cue, not the exception). It is a SPEED tool, not a brake: a coherent explanation is a hypothesis, not a conclusion, and the fastest route to a fix that sticks is the cheapest probe that could prove your idea wrong (a timing, a grep of a count, one --emit-and-look — seconds). So the moment you can state a cause or a fix, that fluency is the cue to GATHER first, not act — which also lets you fix the SOURCE and delete

2026-07-146

design-protocol

loft-lang/loft

Design Protocol 1 — a design is a testable HYPOTHESIS about an invariant, not a plan you execute. The DESIGN-mode counterpart to the engineering-rigor skill (which routes here for the design half). USE THIS whenever you are about to commit to a load-bearing design — a core representation, runtime, memory model, codegen, a public contract, a data format, or any algorithm that will carry weight: name the ONE invariant, count its re-assertion sites, build the cheapest probe that could FALSIFY each load-bearing claim, then build and validate against the written prediction. And for exact-invariant domains where you cannot even form the invariant (geometry, caching, hashing, store/memory lifetime, round-trips), flip to the constructive instrument — plot a concrete instance of the ANSWER and read the invariant off it. Reach for it when a design feels too clean, when you keep reaching for an approximation, or whenever you catch yourself about to build the first coherent design without probing it.

2026-07-076

loft-ship

loft-lang/loft

Write, bridge, verify, and publish a loft library so it behaves IDENTICALLY on all four targets — the interpreter, --native, --native-wasm, and --html (browser). Use this skill whenever the user is creating, packaging, cross-compiling, or publishing a loft library or package; mentions loft.toml, the target matrix, a wasm bridge, `loft new` / `loft install`, the registry, the sha256/signature, or making a library "work in the browser" / "work in wasm"; or is debugging native-vs-wasm-vs-interpret divergence in a library. Trigger it even when the user doesn't say "all four platforms" — any loft library that has to ship beyond the interpreter belongs here, because the cross-target parity gate and the wasm-bridge pitfalls are exactly where this work silently goes wrong.

2026-07-046

name	loft-codegen
description	The discipline for ANY loft compiler/codegen work — fixing a store-lifetime or codegen bug, adding/altering bytecode, parser IR, the interpreter, or the native generator, or implementing a language feature that emits ops — OR restructuring any of those without meaning to change what they emit (extracting a selector, folding a special case, deleting a redundant condition). USE THIS the moment you are about to edit src/parser/, src/state/codegen.rs, src/fill.rs, src/generation/, src/compile.rs, or scopes.rs to change OR reshape what code is emitted — ESPECIALLY when a fix looks obvious and you're tempted to "just patch the generator and run the suite." The one load-bearing instrument is the same in both modes — `loft introspect` on BOTH backends BEFORE you touch the compiler — but the gate flips: a BUG FIX proves the WORKING bytecode standalone beside the broken one; a behaviour-PRESERVING REFACTOR proves the emitted IR + native Rust BYTE-IDENTICAL before/after. Skipping it is how codegen work flails and regresses the suite (see the probe-04 anti-example). The DESIGN/diagnosis counterparts are the engineering-rigor and design-protocol skills; this is the EMIT-mode sibling. Routes to CODEGEN_METHOD.md (the method) and OWNERSHIP_MODEL.md (the ownership beacon).
user-invocable	true

loft-codegen — Prove the Working Bytecode First

The one gate (do not pass it)

Do NOT edit the compiler until you have the WORKING bytecode/IR for THIS situation, captured beside the current/broken bytecode, and proven correct on BOTH backends (--interpret AND --native).

The method — bytecode → types → code, smallest scale first

Bytecode first (the target, proven). Write the minimal case. Capture the WORKING bytecode/IR beside the current/broken one for the same situation — loft introspect prog.loft, or LOFT_LOG=static. The diff IS the spec. Get the working form from a hand-correct SOURCE shape (or hand-write it), so it's a real runnable artifact, never a guess. Prove it on BOTH backends before any compiler edit. Save the pair (e.g. under a plan's bytecode-comparisons/).
- Static dumps don't show runtime identity (stack-ref vs owned heap). When the two IRs look identical but behaviour differs, the fault is value-delivery — reach for LOFT_LOG=ref_debug / LOFT_TRACE_*, not another static read.
Types next (make the target OBVIOUS). What must the type carry (ownership / transfer-vs-borrow, nullability, layout) so codegen reads ONE clear fact and emits the working bytecode mechanically? If the types already carry it → no type change. If not → that gap is the type change, and it lands before the codegen change.
Code last (translation, not re-derivation). Codegen reads the type fact + the parse-tree node and emits the ops. Local translation logic is fine; the red flag is codegen re-deriving a non-local fact (the has_ref_params && … && … shape) — that fact belongs back in step 2.

Mode B — behaviour-preserving refactor (flip the gate to before/after)

Build a one-fn-per-path corpus FIRST. Write one .loft file with one small function per code path the change touches (each delivery/emit branch), plus a main that runs them all so the file is also a clean end-to-end check. This is what makes the diff exercise the branches you restructured — a corpus that misses a path can't catch a regression in it. Save it under the plan's bytecode-comparisons/.
Capture BEFORE. loft introspect corpus.loft > before.txt (it carries the IR
- bytecode AND the native Rust, so one capture covers both backends). Confirm the corpus runs clean on --interpret and --native (LOFT_STORES=warn / LOFT_NATIVE_LEAK_CHECK).
Refactor, then prove AFTER == BEFORE. loft introspect corpus.loft > after.txt; diff before.txt after.txt — empty means you changed nothing emitted, on both backends, which is the whole claim of a behaviour-preserving refactor. Re-run after cargo fmt (it touches the file). One commit per sub-step; if the diff is non-empty and you didn't intend it, that line is the bug — bisect by sub-step, don't push through.

The diagnostic

The both-backends rule

Stop conditions (revert, don't push through)

You're editing the compiler but cannot point at the working bytecode you intend to emit → STOP, go do step 1.
A change makes one backend pass and the other regress/hang/crash → revert; it is not landable.
The patch is growing per-shape conditions → the fact belongs in the type (step 2).

Anchors

Keep git diff main a usable codegen compass — ONE branch held close to main, rebased on origin/main often (the engineering-rigor skill § "Keep git diff main usable"); a diverged branch loses the working-vs-broken comparison this method depends on.
CODEGEN_METHOD.md — the full method
OWNERSHIP_MODEL.md — deps as loft's borrow checker (the north star for store-lifetime work)
Worked example + rungs: doc/claude/plans/85-store-lifetime-retirement/ (bytecode-comparisons/, type-ownership-design.md); probe 05 = method followed (clean), probe 04 = method skipped (regressed) — read both
DEBUG.md § Introspection CLI — loft introspect / LOFT_LOG
DESIGN/diagnosis siblings: the engineering-rigor and design-protocol skills