SuperAPI AI Directory

stitch-ui-design-spec-layui

Design & creation

View repository

Updated 10-15 21:48

About this skill

Layui Design Spec (Layui-Vue / Vue 3.0)

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

Purpose

This skill makes the Layui-Vue 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:

  • layui, layui-vue, layui vue

Chinese trigger keywords (only for triggering):

  • layui 风格
  • layui admin

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: Layui-Vue (Vue 3).
- Design Tokens:
  - Colors: Primary=#16baaa (Cyan-Green), Secondary=#16b777, Nav-bg=#393D49.
  - Functional: Success=#16b777, Warning=#FFB800, Danger=#FF5722, Info=#31BDEC.
  - Spacing: 10px / 15px grid system.
  - Radius: Small=2px (Classic Layui), Medium=4px. No large radius.
  - Typography: Base size 14px. Titles font-weight 500.
- Component Contracts:
  - Buttons: layui-btn (Height 38px, Radius 2px).
  - Inputs: layui-input (Height 38px, Border #e2e2e2).
  - Cards: layui-card (White bg, Header border-bottom #f6f6f6).
  - Tables: layui-table (Header #f2f2f2, Border #e2e2e2).
  - Others: <lay-page-header>, <lay-result>, <lay-skeleton>, <lay-timeline>, <lay-space>.
- Layout Invariants:
  - Style: Minimalist, Flat, Clean, "Classic Admin Design".
  - Keep logo placement and alignment exactly as-is.

Selector mode

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

  1. Contract selection JSON:
{
  "version": "CONTRACT_SELECTION_JSON_V1",
  "designSystem": "layui-vue",
  "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., "Admin Layout with Sidebar and Header")

[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: Layui-Vue 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 required to complete the current step.
  • Evidence first: when run results, resource IDs, versions, hashes, or test outputs are missing, clearly mark them as NOT_VERIFIED。
  • Idempotency first: retain the request identifier and stage status; 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: Run 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 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 a correlatable status 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's intent, and adjacent tasks were not misrouted to this skill.
  • Inputs, target objects, versions, and output locations are all clear, and guessed values were not used in place of required values.
  • All write, paid, publish, or irreversible actions are within the user's authorization scope.
  • 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. 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, publish, overwrite, and paid operations are not natural extensions of ordinary read/write.
  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; write, paid, publish, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body; hand off by skill name and preserve the current task context.

Progressive disclosure

  • When it is necessary to determine inputs/outputs, state, and authorization points, 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。