SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsstitch-ui-contract-uview2

stitch-ui-contract-uview2

Design & creation

View repository

Updated 10-15 21:48

About this skill

uView Design Spec (uView 2.0 / uni-app / Vue2)

Constraint: Only use this skill when the user explicitly mentions "Stitch".

Contract ownership

This skill maintains the component, token, and state contracts of the target framework, and is used to generate constraint inputs before design; it does not generate business page code. Product specifications and the final prompt patterns are uniformly maintained by stitch-design-spec . The prefix/selector assembly hints below are framework examples and must be compiled by the unified entry point in combination with the current page and the inline/applied-system/targeted-edit modes, and must not directly override the already-applied system or local modification scope.

Use by name stitch-design-spec; installation instructions:npx skills add full-stack-skills/stitch-skills --skill stitch-design-spec, no automatic installation. Real code conversion uses the corresponding components skill; a framework-style design mockup cannot replace code verification.

Purpose

This skill makes the uView 2.0 design spec executable in two modes:

  1. Prefix mode: output a paste-ready Hard constraints prefix for Stitch [Context].
  2. Selector mode: output CONTRACT_SELECTION_JSON_V1 and then an assembled Stitch prompt that injects only the required component/state snippets.

Trigger Keywords

Prefer this skill when the user request includes any of:

  • uview, uview2, uview2.0, u-view

Negative Constraint: If the user says "uView Pro" or "uviewpro", DO NOT use this skill. Use stitch-ui-contract-uviewpro instead.

Chinese trigger keywords (only for triggering):

  • uview 风格
  • 美化
  • 优化

Source of Truth

  • references/contract.md
  • references/examples.md
  • references/official.md

Output (STRICT)

Decide the mode by the user intent:

  • If the user asks for beautify/polish/refine an existing screen, or asks for selector / JSON / contracts.include / states.include → use Selector mode.
  • Otherwise → use Prefix mode.

Prefix mode

Return exactly one code block:

[Hard constraints prefix]
- Framework: uView 2.0 (uni-app / Vue 2).
- Design Tokens:
  - Colors: Primary=#3c9cff, Success=#5ac725, Warning=#f9ae3d, Error=#f56c6c, Info=#909399.
  - Background: #f3f4f6. Border: #dadbde.
  - Spacing: 4, 8, 12, 16, 20, 24, 32, 40 (px).
  - Radius: 8, 12, 999 (px).
- Component Contracts:
  - Layout: Use <u-row> and <u-col span="...">.
  - Forms: Use <u--form> (note double dash), <u--input border="surround">.
  - Buttons: Use <u-button type="primary">.
  - Navbar: Use <u-navbar title="..." :autoBack="true">.
  - List: <u-swipe-action>, <u-index-list>, <u-waterfall>.
  - Feedback: Use this.$refs.uToast.show({...}), <u-code> (SMS).
- Layout Invariants:
  - No gradients as default style.
  - Minimal shadows.
  - Transitions: 200ms ease-out.

Selector mode

Return exactly two code blocks, in this order, with no extra prose:

  1. Contract selection JSON:
{
  "version": "CONTRACT_SELECTION_JSON_V1",
  "designSystem": "uview2",
  "mode": "selector",
  "contracts": { "include": [] },
  "states": { "include": [] }
}
  1. Final Stitch prompt:
[Context]
(Paste Hard Constraints Prefix here)
(Add "Layout Invariants" from contract.md if beautifying)

[Layout]
(Describe the macro layout structure, e.g., "Mobile Column Layout with Navbar")

[Components]
(Inject component snippets matching the JSON selection above)

References

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: uView 2 design spec for Stitch. Outputs hard-constraints prefix or selector JSON and assembled prompt.

Rules

  • Read before write: first confirm the current state and real capabilities, then execute 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 outputs are missing, explicitly mark them as NOT_VERIFIED。
  • Idempotency first: retain request identifiers and phase state; when the result is 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 only an adjacent need, hand it off to a more precise skill.

Step 2: Perform prechecks

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 called, 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, 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 write, paid, publishing, or irreversible actions are within the scope of user authorization.
  • The results have been verified with independent checks; only "the command succeeded" or "the file exists" does not count as complete acceptance.
  • The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

  1. Treating the plan as the result: a document or prompt is not equal to real execution; the actual execution level must be indicated.
  2. Retrying on error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
  3. Implicitly expanding scope: batch, full, publish, overwrite, and paid actions are not a natural extension of ordinary reads and writes.
  4. Version drift: When citing external resources, record the version, tag, or commit; do not treat mutable branches as release evidence.
  5. Evidence expiration: 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, publishing, 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 input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
  • When pre-delivery self-checks are needed, read references/validation-checklist.md。
  • When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
  • For first runs, privilege escalation refusal, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。