stitch-ui-design-spec-vant

Vant Design Spec (Vant 4 / Vue 3)

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

Purpose

This skill makes the Vant 4 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:

• vant, vant4, vant-ui, vant ui

Chinese trigger keywords (only for triggering):

• vant 风格
• vant 组件库

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: Vant 4 (Vue 3 / Mobile).
- Design Tokens:
  - Colors: Primary=#1989fa (Blue), Success=#07c160, Warning=#ff976a, Danger=#ee0a24.
  - Background: Page=#f7f8fa, Card=#ffffff.
  - Typography: Base 14px.
  - Radius: sm=2px, md=4px, lg=8px.
- Component Contracts:
  - Layout: Use <van-row>, <van-col span="...">. Container: <van-config-provider>.
  - List/Card: Use <van-cell-group inset> for card style groups.
  - Buttons: Use <van-button type="primary" round block>.
  - Forms: Use <van-form>, <van-field>, <van-search>, <van-picker>, <van-date-picker>.
  - Business: <van-card> (Product), <van-submit-bar>, <van-address-list>, <van-coupon-list>.
  - Navigation: <van-nav-bar>, <van-tabbar>, <van-sidebar>, <van-tabs>.
  - Feedback: <van-action-sheet>, <van-swipe-cell>, <van-empty>.
- Layout Invariants:
  - Mobile First (375px base).
  - Use Flexbox for alignment.
  - Respect Safe Area.

Selector mode

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

1. Contract selection JSON:

{
  "version": "CONTRACT_SELECTION_JSON_V1",
  "designSystem": "vant4",
  "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

• Contract
• Examples
• Official Docs

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: Vant 4 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 perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required 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 the result is unclear, query first and do not retry blindly.
• 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 preflight 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 called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute in the minimum sufficient steps, and record evidence at key state changes; retain an associable state or receipt for each 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 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 to replace 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 executable next steps.

Gotchas

1. Mistaking the plan for the result: a document or prompt is not equivalent to real execution; the actual execution level must be indicated.
2. Erroneous retry: 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, publication, overwrite, and payment 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; 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 retain 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 timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation denial, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。