stitch-ui-style

Stitch Visual Style Proposal

Quick Start

1. "Write a restrained Chinese visual proposal for a store appointment brand; provide a locally reviewable result first."
2. "Turn the operations dashboard's density/motion preferences into specifications; preserve the existing scope and sources."
3. "Propose typography and layout variants under the brand's existing colors; mark missing inputs and validation status."

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

Capability Boundaries

✅ Good At Handling

• Writing a restrained Chinese visual proposal for a store appointment brand.
• Turning the operations dashboard's density/motion preferences into specifications.
• Proposing typography and layout variants under the brand's existing colors.

⚠️ Requires Materials

• Brand materials and page purpose.
• Target audience, viewport, and existing constraints.
• Density, degree of variation, and motion preferences.

❌ Inapplicable Scenarios and Handoff

• Extract real tokens from an existing implementation → stitch-extract-design-md.
• Generate actual Stitch screens → stitch-ui-execute.
• Arbitrarily changing the brand or fabricating product results → preserve brand inputs; when data is missing, provide structural mockups rather than factual claims.

Workflow

1. Read the brand and goals, prioritize user-approved values, and distinguish observed facts from design recommendations.
2. Provide three adjustable directions—density, layout variation, and motion; by default these are recommendations, not hard brand rules.
3. Form color names/values/roles and a font hierarchy with Chinese fallbacks, and check readability and content density.
4. Write specific constraints for components, layout, breakpoints, and motion; disable non-essential motion with prefers-reduced-motion, and do not force infinite loops.
5. Output a seven-section DESIGN.md proposal and mark the decision rationale, pending items, and validation methods; for uploads, use the management skill separately.

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, output an assumption draft first, then list precisely what is missing and what it is for, 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 text, or signed download URLs into reports/repositories. Unverified parameters, visual effects, and business figures must not be fabricated; outputs must note sources, decision rationale, actual execution, and unverified parts.

• Brand takes precedence over example style bans.
• Chinese fonts and low motion have clear paths.
• Statistics, customer counts, and performance data are not fabricated.

Customizable: density, variation, motion intensity, brand-locked items, devices, and Chinese fonts. Value-added checks: adjustable style axes; brand difference explanations; low-motion solutions.

FAQ

Q1: What are the main deliverables? Store reservation proposal: retain brand #2563eb; density 5/10; Chinese system sans-serif; button press feedback; low-motion mode disables displacement; all are suggestions, not uploaded.

Q2: When should a different entry point be used instead? Extract real tokens from an existing implementation → stitch-extract-design-md; generate actual Stitch screens → stitch-ui-execute; arbitrarily change the brand or fabricate product results → retain brand input; when data is missing, provide a structural mockup rather than factual claims.

Q3: What happens when input is missing? First provide a clearly marked local assumption draft and list "needed additions: brand assets and page purpose; target audience, viewport, and existing constraints; density, degree of variation, motion preference". Write operations that depend on these inputs are not executed.

Q4: How is completion judged? Brand takes precedence over example style prohibitions; Chinese fonts and low motion have a clear path; statistics, customer counts, and performance data are not fabricated.

Q5: How is it customized? Density, variation, motion intensity, brand-locked items, device, and Chinese font; when not provided, use 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 call an upload successful, and without runtime verification, do not call it live. Additional installation or scope expansion requires first explaining the specific impact.

Reference as needed

• When executing detailed mappings, APIs, or templates, read Extended workflow。
• When encountering failures or abnormal input, read Anti-patterns and Gotchas。
• When involving edge cases, compatibility, customization, and authorization, read In-depth FAQ。
• When complete input/output and verification scenarios are needed, read Local application examples。
• The local implementation basis is the source code accompanying this skill and pinned upstream snapshot; the structure follows Agent Skills specification. The tool's current behavior is subject to 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, input, constraints, delivery format, and acceptance criteria from the request; the description summary is: write a DESIGN.md proposal with a clear visual direction for Stitch; trigger when the user requests more distinctive typography, color, layout, and motion options. Use stitch-design-md to audit existing design facts; it will not automatically override approved brand guidelines or generate remote screens.

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 the request identifier and phase state; when results are unclear, query first instead of blindly retrying.
• 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 only an adjacent need, hand it off to a more precise skill.

Step 2: Perform pre-checks

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

Step 3: Form a plan

List the tools to be invoked, the objects that will be changed, 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, unfinished items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with the user's intent, and no adjacent task was 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 writes, payments, publications, or irreversible actions are within the scope of user authorization.
• The results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and actionable next steps.

Gotchas

1. Mistaking the plan for the result: Documentation or prompts are not equal to actual execution; the actual execution level must be indicated.
2. Retrying on error: A timeout or lost response may already have produced a remote state; query first before deciding whether to retry.
3. Implicit scope expansion: Batch, full-scale, publication, overwrite, and payment actions are not a natural extension of ordinary read/write operations.
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; writes, payments, publications, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When inputs/outputs, states, and authorization points need to be determined, read references/workflow-contract.md。
• When a pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, authorization overreach refusals, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。