Constraint: Only use this skill when the user explicitly mentions "Stitch".
Contract ownership
This skill maintains the target framework's components, tokens, and state contracts, and is used to generate constraint input before design; it does not generate business page code. Product specifications and the final prompt schema 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 the scope of local modifications.
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; framework-style design mockups cannot replace code verification.
Purpose
This skill makes the uView Pro 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-pro,uviewpro,uview pro
Chinese trigger keywords (only for triggering):
uview prouview 3.0
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 Pro (uni-app / Vue 3).
- Design Tokens:
- Colors: Primary=#3c9cff, Success=#5ac725, Warning=#f9ae3d, Danger=#f56c6c, Info=#909399.
- Typography: Unit rpx. Main Title 32rpx. Content 28rpx.
- Radius: Base 8rpx, Card 16rpx, Circle 9999px.
- Component Contracts (Prefix: u-; uView Pro uses same tag prefix as uView 2, package uview-pro):
- Buttons: <u-button type="primary" shape="circle">.
- Layout: <u-row>, <u-col span="...">, <u-gap>.
- Forms: <u-form :model="form">, <u-form-item>, <u-input border="none">, <u-code>.
- Navbar: <u-navbar title="..." :autoBack="true">.
- List: <u-swipe-action>, <u-index-list>, <u-waterfall>, <u-list>, <u-grid>.
- Icons: <u-icon name="photo">.
- JS Utilities:
- Use uni.$u.toast(), uni.$u.route(), uni.$u.http.post().
- Use <script setup lang="ts">.
Selector mode
Return exactly two code blocks, in this order, with no extra prose:
- Contract selection JSON:
{
"version": "CONTRACT_SELECTION_JSON_V1",
"designSystem": "uview-pro",
"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, input, constraints, delivery format, and acceptance criteria from the request; the description summary is: uView Pro 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 outputs are missing, explicitly mark them as
NOT_VERIFIED。 - Idempotency first: retain the request identifier and phase state; 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 only an adjacent need, hand it to a more precise skill.
Step 2: Perform precheck
Confirm the goal, input, 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 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 each 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's intent, and adjacent tasks have not been misrouted to this skill.
- The input, target object, version, and output location are all clear, and no guessed values have been 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 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
- Mistaking the plan for the result: a document or prompt is not the same as real execution; the actual execution level must be indicated.
- Erroneous retry: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
- Implicit scope expansion: batch, full-volume, publish, overwrite, and paid actions are not natural extensions of ordinary read/write.
- Version drift: When citing 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; 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 you need to determine inputs/outputs, states, and authorization points, read
references/workflow-contract.md。 - When you need to self-check before delivery, read
references/validation-checklist.md。 - When encountering timeouts, partial success, or recovery scenarios, read
references/error-recovery.md。 - For first runs, denial of privilege escalation, and failure recovery, refer respectively to
examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。