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

single-page-mockup

スター1

フォーク0

更新日2026年7月16日 21:01

Create a single self-contained HTML file that mocks a feature using inline React and CSS. Use when the user asks to prototype a UI flow, build a mockup, create a shareable demo, or iterate on a feature's look and feel before implementation.

インストール

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

Manusで実行

ソース

Kestral-Team

Kestral-Team/kstack

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

ダウンロード

Manusで実行

Single-Page Mockup

Build a single .html file that mocks a feature flow with inline React, CSS, and fixture data. The file is shareable (email, Slack, repo link) and opens in any browser with no build step.

When to use

Stakeholders want to see a flow before eng builds it
Iterating on layout, copy, states, or interaction patterns
Validating a multi-step UX (e.g. upload → processing → triage)

Output

One file in a scratch/mockups directory (see context.md for project-specific output path). Mockups are ephemeral and should not be committed.

Step 1: Understand the feature

Before writing anything, read the relevant production components to extract:

User flow — the sequence of states/screens (e.g. empty → ready → running → results)
Data shape — the GraphQL types or component props that drive the UI
Copy — exact button labels, helper text, empty states, error messages
Layout — master-detail, card grid, wizard, sidebar, etc.
Interaction patterns — keyboard shortcuts, selection model, approve/reject/edit

If a plan or requirements doc exists, use it as the source of truth for scope.

Step 2: Write the HTML file

Use this skeleton:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>[Feature] — Mock</title>
  <style>
    /* :root tokens, layout, component styles — all inline */
  </style>
</head>
<body>
  <div id="root"></div>
  <script src="https://unpkg.com/react@18/umd/react.production.min.js" crossorigin></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js" crossorigin></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
  <script type="text/babel" data-presets="react">
    // All React code here: fixtures, helpers, components, mount
    ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

CSS rules

Extract design tokens from the project's design system (see context.md for token source locations).
Port class names from production styles so the mock visually matches the real app.
Include relevant keyframe animations (spin, pulse, glow).
System font stack, max-width: 1200px centered, subtle gray page background.
Light mode only. No external component library or icon library imports.

React rules

All code in one <script type="text/babel"> block.
Destructure hooks at the top: const { useState, useCallback, useMemo, useEffect, useRef } = React;
Inline SVG icon components instead of Lucide (keep them small, stroke-based, 24x24 viewBox).
Fixture data as top-level const arrays/objects matching the production GraphQL shape.
Local useState for all interactions — no GraphQL, no fetch, no auth.
Use setTimeout to simulate async operations (analysis, saves).
Actions that would trigger backend work (apply, sync) use window.alert() or a small toast.

Page chrome

Every mockup includes:

Page header — <h1> with feature name + "Playground", subtitle "Mock flow for product review."
Network banner — note that React/Babel load from CDN and internet is needed on first open.
Tab bar or segmented control — if the feature has multiple views/phases.

Step 3: Build realistic fixtures

Use plausible names, dates, content — not "Lorem ipsum" or "Test item 1".
Include enough items (6-10 for lists, 2-3 for tabs) with mixed statuses so all visual variants are visible.
Mirror the production GraphQL type fields so mock props match real components.

Step 4: Implement interactions

Priority order:

Navigation — tabs, back/forward, selection
Primary actions — the main CTA the user evaluates (approve, submit, learn)
State transitions — loading → complete, empty → populated
Keyboard shortcuts — if the production feature has them, include them
Secondary actions — edit, reject, restore, remove
Feedback — toasts, inline status badges, count updates

Stub anything that would require a backend with window.alert('Would [action]') or an inline toast.

Step 5: Verify

Open the file directly in a browser (open scratchpad/mockups/<name>.mock.html or double-click).
Walk through the full flow end to end.
Check all states: empty, loading, populated, all-reviewed.
Verify keyboard shortcuts work.
Confirm no console errors.

Constraints

One file only. No separate JS, CSS, or JSON files.
No production imports. Do not import from production codepaths, GraphQL clients, etc.
No changes to production code. The mockup is standalone.
CDN-dependent. Recipients need internet on first open. Document this in the banner.
Disposable. The mockup will drift from production. It is a sketch, not a source of truth.

Project Context

Read context.md and apply it as additional project-specific constraints layered on top of this workflow. If it does not exist, skip this section.

このリポジトリの他の Skills

同じリポジトリ

acceptance-check

Kestral-Team/kstack

Validate the branch diff against the task's acceptance criteria before marking it done. Use when implementation looks complete, before a status update to done/awaiting_review, or when the user asks "did we cover everything?"

2026-07-241

code-review

Kestral-Team/kstack

One-pass AI code review of a PR or branch diff (tech-lead style). Use when the user asks for a code review, PR review, AI review, or wants code quality, architecture, bugs, and patterns reviewed.

2026-07-241

code-simplify

Kestral-Team/kstack

Simplify changed code in a PR or branch for readability while preserving behavior. Use when the user asks to simplify code, reduce complexity, clean up a PR, or improve readability of recent changes.

2026-07-241

context-evolve

Kestral-Team/kstack

Capture new project-specific learnings into context files. Runs during reviews or after debugging to evolve the project's skill knowledge base. Use when the thread reveals patterns, anti-patterns, conventions, or codebase gotchas that should be remembered.

2026-07-241

debug-pipeline

Kestral-Team/kstack

Debug pipeline: investigate (prod or local) → fix-issues → scoped polish (deslop + code-simplify) → pattern-check → kestral-sync retroactive capture. Only invoked by the kstack subagent.

2026-07-241

decision-capture

Kestral-Team/kstack

Capture the decision when a spike, prototype, or investigation concludes. Use when a prototype or spike wraps up, the user makes a go/no-go call after de-risking, or an investigation answers its question — prompts "what did you decide?" and writes the decision + rationale to the task tracker.

2026-07-241

name	single-page-mockup
kstack	true
description	Create a single self-contained HTML file that mocks a feature using inline React and CSS. Use when the user asks to prototype a UI flow, build a mockup, create a shareable demo, or iterate on a feature's look and feel before implementation.
disable-model-invocation	true

Single-Page Mockup

Build a single .html file that mocks a feature flow with inline React, CSS, and fixture data. The file is shareable (email, Slack, repo link) and opens in any browser with no build step.

When to use

Stakeholders want to see a flow before eng builds it
Iterating on layout, copy, states, or interaction patterns
Validating a multi-step UX (e.g. upload → processing → triage)

Output

One file in a scratch/mockups directory (see context.md for project-specific output path). Mockups are ephemeral and should not be committed.

Step 1: Understand the feature

Before writing anything, read the relevant production components to extract:

User flow — the sequence of states/screens (e.g. empty → ready → running → results)
Data shape — the GraphQL types or component props that drive the UI
Copy — exact button labels, helper text, empty states, error messages
Layout — master-detail, card grid, wizard, sidebar, etc.
Interaction patterns — keyboard shortcuts, selection model, approve/reject/edit

If a plan or requirements doc exists, use it as the source of truth for scope.

Step 2: Write the HTML file

Use this skeleton:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>[Feature] — Mock</title>
  <style>
    /* :root tokens, layout, component styles — all inline */
  </style>
</head>
<body>
  <div id="root"></div>
  <script src="https://unpkg.com/react@18/umd/react.production.min.js" crossorigin></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js" crossorigin></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
  <script type="text/babel" data-presets="react">
    // All React code here: fixtures, helpers, components, mount
    ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

CSS rules

Extract design tokens from the project's design system (see context.md for token source locations).
Port class names from production styles so the mock visually matches the real app.
Include relevant keyframe animations (spin, pulse, glow).
System font stack, max-width: 1200px centered, subtle gray page background.
Light mode only. No external component library or icon library imports.

React rules

All code in one <script type="text/babel"> block.
Destructure hooks at the top: const { useState, useCallback, useMemo, useEffect, useRef } = React;
Inline SVG icon components instead of Lucide (keep them small, stroke-based, 24x24 viewBox).
Fixture data as top-level const arrays/objects matching the production GraphQL shape.
Local useState for all interactions — no GraphQL, no fetch, no auth.
Use setTimeout to simulate async operations (analysis, saves).
Actions that would trigger backend work (apply, sync) use window.alert() or a small toast.

Page chrome

Every mockup includes:

Page header — <h1> with feature name + "Playground", subtitle "Mock flow for product review."
Network banner — note that React/Babel load from CDN and internet is needed on first open.
Tab bar or segmented control — if the feature has multiple views/phases.

Step 3: Build realistic fixtures

Use plausible names, dates, content — not "Lorem ipsum" or "Test item 1".
Include enough items (6-10 for lists, 2-3 for tabs) with mixed statuses so all visual variants are visible.
Mirror the production GraphQL type fields so mock props match real components.

Step 4: Implement interactions

Priority order:

Navigation — tabs, back/forward, selection
Primary actions — the main CTA the user evaluates (approve, submit, learn)
State transitions — loading → complete, empty → populated
Keyboard shortcuts — if the production feature has them, include them
Secondary actions — edit, reject, restore, remove
Feedback — toasts, inline status badges, count updates

Stub anything that would require a backend with window.alert('Would [action]') or an inline toast.

Step 5: Verify

Open the file directly in a browser (open scratchpad/mockups/<name>.mock.html or double-click).
Walk through the full flow end to end.
Check all states: empty, loading, populated, all-reviewed.
Verify keyboard shortcuts work.
Confirm no console errors.

Constraints

One file only. No separate JS, CSS, or JSON files.
No production imports. Do not import from production codepaths, GraphQL clients, etc.
No changes to production code. The mockup is standalone.
CDN-dependent. Recipients need internet on first open. Document this in the banner.
Disposable. The mockup will drift from production. It is a sketch, not a source of truth.

Project Context

Read context.md and apply it as additional project-specific constraints layered on top of this workflow. If it does not exist, skip this section.