菜单
Use before dispatching more than one delegate against the same repo, or whenever a work list has more than two items. Produces the lane table — ownership, phase, and merge order — that has to exist before any dispatch happens, not after a collision is discovered.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use at the polish stage of a design direction, once structure is settled, to turn a prototype's own tokens into a small panel of eye-decidable knobs a designer drives by hand, and to route what they settle back into the token system and the taste rules. Emits an altitude-appropriate facet spec, and at polish a self-contained tunable playground. Skip it when the artifact has no eye-tunable surface.
Use when onboarding a new person or a new repo to this pack — constants files don't exist yet, need regenerating, or a repo needs its own landmine list captured. Also use when a standing correction keeps recurring and hasn't been turned into a candidate rule yet.
Use before grounding a design or technical direction in external references — comparing tools, evaluating approaches, gathering prior art — before committing to a direction. Produces a source index, a synthesis, and concrete candidate directions instead of a pile of links.
Use before writing any planning artifact a human has to approve - a spec, an implementation plan, or a long dispatch brief. Gate the full artifact behind a tight stub the human will actually read, get approval on the stub, then elaborate and adversarially review the full thing.
Use when receiving a design or code review to execute, or when writing a review someone else will execute. Splits every review item into one of four buckets before any work starts, so parked items don't get silently rebuilt and outgoing reviews arrive pre-executable.
Use any time more than one lane of work (delegate, agent, or workstream) is active against the same project. Maintains board.json as the single source of truth for lane state — written on every lane transition, not batched — so status reporting, "what's running", handoffs, and kill decisions are all queries against one file instead of reconstructed from memory.
| name | lane-planner |
| description | Use before dispatching more than one delegate against the same repo, or whenever a work list has more than two items. Produces the lane table — ownership, phase, and merge order — that has to exist before any dispatch happens, not after a collision is discovered. |
Before dispatching more than one delegate against a repo, produce a lane table. The table is the plan; it exists before the first delegate starts, not as a retrospective explanation of what went wrong.
A lane table has, per lane: lane name → model tier → owned files/dirs → dependency phase → merge order. One owner per file or directory, no exceptions — if two lanes' work would touch the same file, that is not two lanes, it is a phase-ordering problem or a single lane.
This triggers whenever more than one delegate is about to run against the same repo concurrently, or whenever a work list has more than two items — even if you intend to run them one at a time in a single delegate. A serial work list still needs the ownership map if any two items would touch the same file; write the table before the first dispatch either way.
A work list of two items or fewer with zero file overlap may collapse the formal table into a single line: lane, tier, files, done. The ownership check still has to happen — you're skipping the table's ceremony, not the judgment behind it.
An explicit, in-session acknowledgment of collision risk for a specific one-off dispatch — stating which file might be touched twice and why you're accepting that risk anyway — is permitted. An unstated assumption that "it'll probably be fine" is not; that's the exact failure mode this skill exists to catch.
