agentsclimarketplace
Sign in

Prototype

Skill panda850819/verbs/skills/engineering/prototype

Decision probe for one unresolved logic, state, or visual design question that is cheaper to experience than discuss. Build a throwaway terminal driver or UI variants, capture the verdict in the brief, then stop. `ui` implements a chosen visual direction; production work remains a separate human-selected task.From its SKILL.md

Install
npx -y skills add panda850819/verbs --skill prototype

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, as published. Nobody here has run it

Prototype

A prototype is throwaway code that answers a question. The question decides the shape; the verdict outlives the code.

Pick the branch

Identify the question from the prompt and the surrounding code. If genuinely ambiguous, ask when the user is present; otherwise match the surrounding code (backend module → logic; page or component → UI) and state the assumption at the top of the prototype. Getting the branch wrong wastes the whole prototype.

  • "Does this logic / state model feel right?" → LOGIC.md: a tiny interactive terminal app that pushes the state model through cases that are hard to reason about on paper.
  • "What should this look like?" → UI.md: several structurally different variants on one route, switchable via ?variant= and a floating bottom bar. Single round by default; UI.md's converge mode runs repeated rounds down the visual design tree when the user (or a Decision Map entry) asks for it. Converge still only chooses a direction, at finer grain — it never becomes the production build.

Rules (both branches)

  1. Throwaway from day one, clearly marked. Locate it next to the module or page it prototypes so context is obvious; name it so a casual reader sees prototype, not production. Obey the project's existing routing and task conventions — invent no new top-level structure.
  2. One command to run, via the project's existing task runner. The user starts it without thinking.
  3. No persistence by default. State lives in memory. If the question is explicitly about persistence, hit a scratch store named "PROTOTYPE — wipe me".
  4. Skip the polish. No tests, no error handling beyond what makes it runnable, no abstractions. The point is to learn fast.
  5. Surface the state. After every action (logic) or variant switch (UI), show the full relevant state so the user sees what changed.

Capture when done

Done means the question is answered AND captured:

  • Fold the validated decision into the real code, or into the brief/plan driving the work.
  • Record the verdict — the question and its answer — on the tracking issue or brief that spawned the prototype.
  • Commit the prototype itself to a throwaway prototype/<slug> branch as the primary source, never the default branch. The default branch keeps only the validated decision.

Relationship to other skills

  • prototype diverges cheap to choose a direction — UI.md's converge mode just repeats that choice level by level, still on throwaway mocks; ui then builds the committed direction for production.
  • A Grilling Session question of the shape "how should it look / behave" is often fastest resolved here; feed the verdict back into the brief.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.