Przejdź do treści
Biblioteka skilli
Programowanie · Budowanie i kod

frontend-prototype-explorer

/frontend-prototype-explorer

Tworzy jednorazowe eksperymenty, gdy kod i dokumenty nie rozstrzygają kwestii UI lub stanu, pomijając zatwierdzoną implementację.

Licencja
Apache-2.0
Ostatnia zmiana repozytorium
23.10.2026

Ocena i bezpieczeństwo

90/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść25 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
2
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 23.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

Co robi i kiedy

Tworzy jednorazowe eksperymenty, gdy kod i dokumenty nie rozstrzygają kwestii UI lub stanu, pomijając zatwierdzoną implementację.

Oryginalny opis (EN)

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

Jak działa

  1. Purpose
  2. When To Use
  3. When Not To Use
  4. Required Context
  5. Tool Contract
  6. Workflow
  7. Output Contract
  8. Validation Gates
  9. Trigger Evals
  10. Reference Map
Sekcje z nagłówków SKILL.md, w oryginale · 102 linii, 640 słów
Podgląd 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`
Pliki w paczce (2)
  • SKILL.md 5 KB
  • agents/openai.yaml 1 KB

Wersje

W bazie nie ma innych skilli o nazwie frontend-prototype-explorer.

Migawka bazy z 13.11.2026 · wersja paczki fc552059318b (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 81prototype
    Prowadzi ograniczony eksperyment, gdy istniejące dowody nie rozstrzygają ważnego pytania projektowego, technicznego lub wykonalnościowego.
  • 100prototype
    Buduje jednorazowe warianty, by rozstrzygnąć jedną decyzję: układ, interakcję, maszynę stanów lub model danych, przed pracą produkcyjną.
  • 90prototype
    Przygotowuje jednorazową wersję do sprawdzenia modelu stanów i logiki biznesowej przed inwestowaniem w pełną implementację.
  • 90prototype-lab
    Buduje jednorazowe prototypy odpowiadające na konkretne pytanie o produkt, UI, automat stanów, model danych lub workflow, zanim powstanie kod produkcyjny.
  • 90prototype
    Buduje jednorazowy prototyp, który odpowiada na skupione pytanie o logikę, model stanu lub UI, zanim zapadnie decyzja o projekcie produkcyjnym.
  • 90prototype
    Buduje jednorazowy prototyp, który odpowiada na pytanie projektowe, np. czy model stanu lub logika działa dobrze albo jak powinien wyglądać interfejs.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.