stitch-ui-react-vite-dashboard

Stitch Data Dashboard Implementation

Quick Start

1. "Implement the store operations mockup as an appointment volume dashboard; first provide a locally reviewable result."
2. "Add query and empty/error/loading states to the order table; preserve the existing scope and sources."
3. "Display on-chain read-only data under explicit requirements; mark missing inputs and validation status."

For designers, frontend developers, and teams maintaining this workflow. Designers provide intent and assets, developers provide engineering/tooling, and the team preserves sources and acceptance status during handoff.

Capability Boundaries

✅ Good At

• Implementing the store operations mockup as an appointment volume dashboard.
• Adding query and empty/error/loading states to the order table.
• Displaying on-chain read-only data under explicit requirements.

⚠️ Requires Assets

• Target React/Vite project and locked versions.
• Stitch HTML/screenshots and DESIGN.md.
• API contracts, pagination rules, and demo data.

❌ Not Applicable Scenarios and Handoff

• Ordinary single card conversion → stitch-ui-react-components.
• shadcn primitive migration → stitch-ui-shadcn-components.
• Signed transactions or financial advice → hand off to an explicitly authorized business process, and deliver read-only data requirements first.

Workflow

1. Read the actual project versions and screen assets; do not upgrade React/Vite by default.
2. Map DESIGN.md colors, fonts, and spacing to project CSS variables, and record the sources.
3. Split pages/presentational components/hooks, preserving semantic table, label, focus, and routing.
4. Set queryKey, query functions, pagination, and loading/empty/error/retry states according to the API contract; when there is no API, use a clearly marked demo adapter.
5. Run the project type/lint/build and interaction validation; use a local token consistency check, and do not use an unverified external linter as a gate.

Order by dependency: source verification → local artifacts → authorized external operations → validation handoff. For multiple tasks, do the current main path first; when information is missing, first output a draft of assumptions, then precisely list what is missing and its purpose, without using vague prompts like "please provide more context."

Security and Result Validation

Do not read unrelated account configurations or collect user passwords; credentials are provided only by the environment or authorized connectors. Use only demo data in examples; before uploading, replace customer names, phone numbers, and order numbers with demo values, and check HTML, screenshots, and file metadata. Do not write keys, session cookies, full base64 content, or signed download URLs into reports/repositories. Do not fabricate unverified parameters, visual effects, or business figures; in the output, note sources, decision rationale, what was actually executed, and what has not yet been verified.

• Filtering/pagination changes queryKey, and mocks are not passed off as a backend.
• Semantic tables and keyboard focus are usable.
• VITE_* contains only public configuration.

Customizable: API adapters, queryKey, pagination strategy, breakpoints, currency/units. Value-added checks: asynchronous state matrix; data source labeling; public configuration boundaries.

FAQ

Q1: What is the main result to be delivered? Appointment filter = pending confirmation, API demo returns [] → table headers and filters are retained, "No appointments" is displayed, and no fabricated statistics are shown.

Q2: When should a different entry point be used instead? Ordinary single-card conversion → stitch-ui-react-components; shadcn primitive migration → stitch-ui-shadcn-components; signed transactions or financial advice → hand off to an explicitly authorized business process, and first deliver the read-only data requirements.

Q3: What happens when input is missing? First provide a clearly marked local-assumption draft, and list "Needed additions: target React/Vite project and locked versions; Stitch HTML/screenshots and DESIGN.md; API contract, pagination rules, and demo data." Write operations that depend on these inputs are not executed.

Q4: How is completion determined? Filters/pagination change queryKey, and mocks are not passed off as a backend; the semantic table and keyboard focus are usable; VITE_* contains only public configuration.

Q5: How is it customized? API adapter, queryKey, pagination strategy, breakpoints, currency/units; when not provided, follow existing project values and state the assumptions.

Q6: Does it automatically upload, install, or go live? Only perform actions covered by the current request and existing authorization; without a remote receipt, do not claim upload success, and without run verification, do not claim go-live. Additional installation or scope expansion requires explaining the specific impact first.

Reference as needed

• When performing detailed mapping, API, or template work, read Extended Workflow。
• When encountering failures/abnormal input, read Anti-Patterns and Gotchas。
• When edge cases, compatibility, customization, and authorization are involved, read In-Depth FAQ。
• When complete input/output and verification scenarios are needed, read Local Application Examples。
• The local implementation is based on the source code accompanying the current skill and pinned upstream snapshot; the structure follows the Agent Skills specification. The tool's current behavior is governed by the actual schema; when not connected, do not claim that online behavior has been verified.

When to use

Load this skill when the user needs to select and execute a verifiable, recoverable professional workflow for the current request . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: implement the Stitch design as a React/Vite data dashboard; trigger when TanStack Query, tables, filtering, async state, and design token consistency are needed. Use stitch-ui-react-components only for ordinary presentational components; add on-chain reads only when explicitly requested..

Rules

• Read before write: first confirm the current state and real capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope needed to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test output are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage status; when results are unclear, query first and do not blindly retry.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is merely an adjacent need, hand it off to a more precise skill.

Step 2: Run pre-checks

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be invoked, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute in minimal sufficient steps, and record evidence at key state changes; retain an associable state or receipt for every external call.

Step 5: Verify delivery

Output the results, verification evidence, incomplete items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with user intent, and adjacent tasks were not misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope authorized by the user.
• The results have been verified with independent checks; "the command succeeded" or "the file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Treating a plan as a result: A document or prompt is not equal to actual execution; the actual execution level must be specified.
2. Retrying on error: A timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: Batch, full-scale, publish, overwrite, and paid operations are not natural extensions of ordinary reads and writes.
4. Version drift: When referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Stale evidence: Caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Do not exceed the scope given by the user; write, paid, publish, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its main text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When self-checking before delivery is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, refusal of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。