idea-to-shipped

Launcher for executing a LOOP.md. Use whenever the owner wants to run or execute a loop, work through a LOOP.md item by item, "run my loop", "start the build loop", or autonomously develop the items in an existing LOOP.md. It does NOT do the work itself — it fires the loop-runner engine (a workflow that runs each item in its own fresh agent, verifies independently, commits locally, and stops at 【human】 gates). The execute stage of the idea-to-shipped pipeline, after roadmap-to-loop.

Take a vague, half-formed idea and produce the cheapest, roughest, disposable prototype whose only job is to provoke the owner's tacit taste — "no, not that, I want X". Built for people whose taste is revealed on contact ("I'll know it when I see it"), not specifiable up front. Runs a short warm-up only until the next question would be better answered by pointing at a screen than by talking, then builds an ugly-fast mockup (one screen, fake data, deliberately incomplete) to react to, harvests every reaction, and distills the generalizable ones into reusable rules. Use this at the very FRONT of a build — whenever the owner says "I have an idea for…", "help me figure out what I actually want", "mock something up so I can react", "I'll know it when I see it", or keeps telling agents "no, redo it" because outputs don't match a picture they can't describe. The step before roadmap-to-loop: this firms up the picture, then roadmap-to-loop makes it runnable.

Front door and router for the taste-driven build pipeline (idea-to-prototype → prototype-to-roadmap → roadmap-to-loop → loop-to-goal, with taste-to-rubric capturing taste throughout). Use when the owner wants to build, make, or ship something and you need to enter the pipeline at the right stage — a vague idea starts at the front; an already-firm concept, an existing roadmap, or an existing LOOP.md enters later. Also use to explain or run "the pipeline / the build loop / my dev process" as one system. It dispatches to the member skills; it does not do their work. Its job is to start at the correct stage (never skip the front on a vague idea), keep RUBRIC.md flowing through every stage, and protect the principles the pipeline is built on.

Turn a firmed-up concept from idea-to-prototype (the picture the owner has stopped saying "no" to, plus its RUBRIC.md of captured taste rules) into a prioritized roadmap that roadmap-to-loop can consume. Slices the validated concept into the smallest shippable increments, orders them (surfacing the order as a proposal, never deciding scope silently), and wires every captured taste rule into the roadmap as a global gate or a per-item criterion seed so settled taste enters the loop as 【verifier】 checks rather than 【human】 stops. Use right after idea-to-prototype reaches "firm" and before roadmap-to-loop. Do NOT re-mine or re-prototype — the picture is already stable; this only slices, sequences, and loads the rules.

Convert a product roadmap, backlog, feature wishlist, or TODO list into an executable LOOP.md that drives autonomous agent iteration (loop engineering). The user writes what they want in plain product language; this skill scans the project for feedback signals (tests, CI, QA scripts), translates each roadmap item into observable acceptance criteria tagged by judge (machine / verifier subagent / human), and writes the loop file with global gates, boundaries, a run protocol, and a log. Use this whenever the user shares a roadmap, plan, or wishlist and wants a loop, rubric, acceptance criteria, a /goal setup, or "something Claude can work through on its own" — even if they only say "write me a loop" or "turn my roadmap into tasks you can run unattended". Especially valuable when the user is a non-coder describing features in product terms.

The canonical taste-capture procedure for the build pipeline. Whenever the owner reacts to a concrete artifact anywhere in the process — a rough prototype, an intermediate build, a 【本人】 stop in a loop, a final acceptance — this turns that reaction into a written, checkable rule and records it in the project's RUBRIC.md, so taste is captured completely and consistently from the front of the pipeline to the back, not just at idea time. Other skills (idea-to-prototype, roadmap-to-loop) call this rather than each reinventing capture. Use whenever an owner says "no, not that" or "yes, like this" about something concrete and the preference should be remembered. Does NOT cover distilling the cross-project master rubric — that is a later pass over many projects' RUBRIC.md files, gated on several existing.