ワンクリックでManusで任意のスキルを実行

taste-to-rubric

スター35

フォーク2

更新日2026年6月16日 12:38

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.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

H1an1

H1an1/idea-to-shipped

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Taste to Rubric

The single place the pipeline turns a reaction into a rule. Taste is revealed on contact: every time the owner sees a concrete thing and reacts, a piece of their tacit standard surfaces. This skill's only job is to catch that piece before it evaporates and write it where it will be reused.

It is called from every stage that shows the owner something — capturing only at the front leaks every preference revealed later:

idea-to-prototype — reactions to the rough cut (front of the pipeline)
roadmap-to-loop — every 【本人】 stop, and final acceptance (the back of the pipeline)
loop-to-goal — any mid-build checkpoint the owner judges (future)

This is a file plus one shared rule, not a system. Any skill runs it inline; it lives here so all of them run it the same way.

The carrier: RUBRIC.md (one per project)

Each project owns a RUBRIC.md, created on the first capture and appended to forever after. It is the project's accumulated taste, in checkable form. Minimal format:

# RUBRIC — <project>
> Taste rules distilled from the owner's reactions. Each line was a "no, not that" that generalized.

- [revealed] One clip is surfaced as "today's", never a backlog. — from: "I want one clip waiting for me, not a backlog" (prototype, 2026-06-16)
- [known] Destructive actions always confirm first. — from: "wait, that deleted without asking" (本人 stop, 2026-06-17)

type — revealed (owner only knew it on sight — the majority) or known (could have been said up front). Tagging this is how you learn, over projects, how much is genuinely un-mineable.
the rule — one line, phrased so someone else (a 【评委】 subagent) could check it. If you can't phrase it checkably yet, write it anyway and mark it (本人-only) — it's still a real rule.
provenance — the actual reaction it came from, and where in the pipeline. This is what later lets a cross-project pass diff rules and distill the master rubric.

The procedure (this IS taste-to-rubric)

For each owner reaction to a concrete artifact:

Gate it. One-off ("move that button left") → just apply it, do not record. Standing preference ("I always want X") → continue.
Distill the standing preference into one checkable line.
Append it to the project's RUBRIC.md with its type and provenance.
Aim to graduate it. Phrase it so a 【评委】 subagent could judge it. A rule that starts as a 【本人】 stop ("only the owner can tell") should, once captured, become a 【评委】 criterion next round — that is how the loop stops needing the owner for that fork. Moving rules from 本人 → 评委 over time is the point.

Reading it back

At the start of a run, load the project's RUBRIC.md and feed it forward: let idea-to-prototype skip asking about things already settled, and let roadmap-to-loop pre-seed its criteria from the rules (settled taste enters as 【评委】, not 【本人】). For a brand-new project with no RUBRIC.md yet, also load the master rubric (below) if one exists, as a starting prior.

Deliberately NOT built yet

The master / global rubric (level 2). Distilled by diffing many projects' RUBRIC.md files to find the owner's cross-project constants. Gated by data: you cannot diff across projects until several RUBRIC.md files exist. It is a later pass over those files, not a thing to design now.
Auto-loading / scoring machinery. Its shape is revealed by watching real rules get captured and reused. Run a couple of real projects first; let the need define the tool.

Boundaries

Never record a one-off tweak as a rule — it bloats the file into noise.
Never invent a rule the owner didn't actually react to. No reaction, no rule.
Never build the cross-project synthesis layer before multiple RUBRIC.md files exist.
This is v0. Expect the first real run to make the owner say "no, the format should be…" — when it does, that reaction is itself a taste-to-rubric event about taste-to-rubric. Catch it.

このリポジトリの他の Skills

同じリポジトリ

loop-to-goal

H1an1/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.

2026-06-1735

idea-to-prototype

H1an1/idea-to-shipped

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.

2026-06-1635

idea-to-shipped

H1an1/idea-to-shipped

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.

2026-06-1635

prototype-to-roadmap

H1an1/idea-to-shipped

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.

2026-06-1635

roadmap-to-loop

H1an1/idea-to-shipped

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.

2026-06-1635

name

taste-to-rubric

description

Taste to Rubric

It is called from every stage that shows the owner something — capturing only at the front leaks every preference revealed later:

idea-to-prototype — reactions to the rough cut (front of the pipeline)
roadmap-to-loop — every 【本人】 stop, and final acceptance (the back of the pipeline)
loop-to-goal — any mid-build checkpoint the owner judges (future)

This is a file plus one shared rule, not a system. Any skill runs it inline; it lives here so all of them run it the same way.

The carrier: RUBRIC.md (one per project)

Each project owns a RUBRIC.md, created on the first capture and appended to forever after. It is the project's accumulated taste, in checkable form. Minimal format:

# RUBRIC — <project>
> Taste rules distilled from the owner's reactions. Each line was a "no, not that" that generalized.

- [revealed] One clip is surfaced as "today's", never a backlog. — from: "I want one clip waiting for me, not a backlog" (prototype, 2026-06-16)
- [known] Destructive actions always confirm first. — from: "wait, that deleted without asking" (本人 stop, 2026-06-17)

type — revealed (owner only knew it on sight — the majority) or known (could have been said up front). Tagging this is how you learn, over projects, how much is genuinely un-mineable.
the rule — one line, phrased so someone else (a 【评委】 subagent) could check it. If you can't phrase it checkably yet, write it anyway and mark it (本人-only) — it's still a real rule.
provenance — the actual reaction it came from, and where in the pipeline. This is what later lets a cross-project pass diff rules and distill the master rubric.

The procedure (this IS taste-to-rubric)

For each owner reaction to a concrete artifact:

Gate it. One-off ("move that button left") → just apply it, do not record. Standing preference ("I always want X") → continue.
Distill the standing preference into one checkable line.
Append it to the project's RUBRIC.md with its type and provenance.
Aim to graduate it. Phrase it so a 【评委】 subagent could judge it. A rule that starts as a 【本人】 stop ("only the owner can tell") should, once captured, become a 【评委】 criterion next round — that is how the loop stops needing the owner for that fork. Moving rules from 本人 → 评委 over time is the point.

Reading it back

Deliberately NOT built yet

The master / global rubric (level 2). Distilled by diffing many projects' RUBRIC.md files to find the owner's cross-project constants. Gated by data: you cannot diff across projects until several RUBRIC.md files exist. It is a later pass over those files, not a thing to design now.
Auto-loading / scoring machinery. Its shape is revealed by watching real rules get captured and reused. Run a couple of real projects first; let the need define the tool.

Boundaries

Never record a one-off tweak as a rule — it bloats the file into noise.
Never invent a rule the owner didn't actually react to. No reaction, no rule.
Never build the cross-project synthesis layer before multiple RUBRIC.md files exist.
This is v0. Expect the first real run to make the owner say "no, the format should be…" — when it does, that reaction is itself a taste-to-rubric event about taste-to-rubric. Catch it.