Constraint: Only use this skill when the user explicitly mentions "Stitch".
Purpose
This skill makes the uView 2.0 design spec executable in two modes:
- Prefix mode: output a paste-ready Hard constraints prefix for Stitch
[Context]. - Selector mode: output
CONTRACT_SELECTION_JSON_V1and 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-design-spec-uviewpro instead.
Chinese trigger keywords (only for triggering):
uview 风格美化优化
Source of Truth
references/contract.mdreferences/examples.mdreferences/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:
- Contract selection JSON:
{
"version": "CONTRACT_SELECTION_JSON_V1",
"designSystem": "uview2",
"mode": "selector",
"contracts": { "include": [] },
"states": { "include": [] }
}
- 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: confirm the current state and real capabilities first, 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 outputs are missing, explicitly mark them as
NOT_VERIFIED。 - Idempotency first: retain request identifiers and phase state; when results are 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 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 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 match the user intent, and adjacent tasks were not misrouted to this skill.
- Inputs, target objects, versions, and output locations are all clear, and no guessed values were used to replace required values.
- All write, paid, publish, or irreversible actions are within the scope authorized by the user.
- The results have been verified with an independent check; "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
- Treating the plan as the result: a document or prompt is not the same as actual execution; the actual execution level must be indicated.
- Retrying after an error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
- Implicit scope expansion: batch, full-scale, publish, overwrite, and paid actions are not natural extensions of ordinary reads and writes.
- Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
- 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 body text; hand off by skill name and preserve the current task context.
Progressive disclosure
- When you need to determine inputs/outputs, state, and authorization points, read
references/workflow-contract.md。 - When you need a pre-delivery self-check, 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。