Skip to content
Back to skills

Frontend Prototype Explorer

ASecurity

Build disposable experiments for unresolved UI or state decisions. Use when code and documentation cannot settle the question; exclude approved implementation and small edits.

  • 6 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added October 14, 2026
ai-agentsfrontendbackenddocumentation

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 14, 2026

npx -y skills add ytvee-dev/webdev-agent-kit --skill frontend-prototype-explorer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Frontend Prototype Explorer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Frontend Prototype Explorer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/ytvee-dev-frontend-prototype-explorer/badge)](https://www.skillsdirectory.com/skills/ytvee-dev-frontend-prototype-explorer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: frontend-prototype-explorer
description: "Build disposable experiments for unresolved UI or state decisions. Use when code and documentation cannot settle the question; exclude approved implementation and small edits."
id: "agents.skills.frontend-prototype-explorer.skill"
title: "Frontend Prototype Explorer"
doc_type: "skill"
layer: "skill"
status: "active"
publishable: true
local_only: false
skill: "frontend-prototype-explorer"
tags: []
parent:
  - "[[AGENTS|Canonical Agent Policy]]"
related:
  - "[[common/domain-glossary-rules]]"
  - "[[templates/decision-log]]"
depends_on: []
---

# Frontend Prototype Explorer

Maturity: experimental. Validate a consequential UI or state decision through
a disposable experiment before production implementation.

## Purpose

Answer one unresolved question with the cheapest runnable artifact. Preserve
the decision and evidence, not an accidental production implementation.

## When To Use

- Compare interactive UI alternatives when descriptions cannot settle usability.
- Exercise a state model through cancellation, delayed responses, or recovery.
- Investigate a consequential choice that source and documentation cannot settle.

## When Not To Use

- Implementing an already approved layout or feature.
- A small style edit, routine bugfix, or question answered by existing source.
- Planning-only requests that do not authorize building an experiment.
- Backend, production data, benchmarking, or new infrastructure outside scope.

## Required Context

1. Apply the active runtime entrypoint (`AGENTS.md` for project targets or
   the native runtime prelude for plugin targets) and the confirmed question
   and constraints.
2. Inspect only the existing stack, commands, and affected ownership needed.
3. Read `common/domain-glossary-rules.md` when domain terms matter.
4. Read `common/verification-loop-rules.md` for executable observations and
   `common/rendered-visual-verification-policy.md` if UI interaction is needed.

## Tool Contract

Use available project-file and command capabilities. A callable browser is
required for claims about rendered interaction, not for a headless state probe.
Use existing dependencies. Tool or package installation, external mutations,
and production access retain their existing authorization boundaries.

## Workflow

1. State one question, what observation would change the decision, and the
   bounded experiment scope. Resolve facts from code before asking questions.
2. Choose an isolated scratch directory or disposable worktree outside production
   source and build inputs. Never overwrite an existing experiment. State the
   allowed files, stop condition, and attempt/time budget before implementation.
3. Build the minimum probe with synthetic in-memory data and one launch command.
   For usability, compare meaningfully different interactions on the same data;
   for logic, expose transitions and resulting state. Avoid production services,
   durable user storage, test infrastructure, and speculative abstractions.
4. Run the relevant cases and record observations. If a tool is unavailable,
   record blocked evidence. For subjective usability, present the alternatives
   and collect user judgment; agent preference alone is not user validation.
5. Stop when the question is answered, the budget is exhausted, or evidence is
   blocked. Report inconclusive results without defaulting to a preferred option.
6. Record Question, Observations, Decision, Limitations, and Evidence reference
   in the existing local decision log when durable work warrants it. Include
   rejected alternatives only when actually considered.
7. Hand the decision to the design/architecture or execution planner. Production
   implementation is a separate approved slice with its own acceptance checks.
   Do not silently promote prototype code, merge its branch, publish it, or
   delete artifacts owned by the user. Keep an evidence pointer for resumption.

## Output Contract

Final response: return only facts that affect the user's understanding, confidence, or next action. Omit empty fields and workflow narration.

Report the answered question, launch command or artifact, observations,
decision or pending user judgment, limitations, and next implementation step.
State experimental maturity. Do not report production readiness from a probe.

## Validation Gates

- One question and explicit budget bound the experiment.
- Production source, dependencies, and real data remain outside the experiment.
- Claims are tied to executed observations or clearly marked user judgments.
- Blocked or inconclusive evidence is not success.
- A decision survives the session, with the scope of what was actually tested.

## Trigger Evals

Should trigger:

- "Compare two interactive filter placements using disposable data before we choose."
- "Prototype cancel and retry transitions to decide whether this state model works."
- "Try a throwaway preview interaction; stop after answering the navigation question."

Should not trigger:

- "Implement the approved preview layout."
- "Change the prototype button color in this one file."
- "Explain this existing state reducer without making changes."

## Reference Map

- `common/domain-glossary-rules.md`
- `common/verification-loop-rules.md`
- `common/rendered-visual-verification-policy.md`
- `templates/decision-log.md`

Files in this skill

  • SKILL.md5.2 KB
  • agents/openai.yaml299 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.