This skill uniformly replaces the content rules of stitch-ui-design-spec-generator and stitch-ui-prompt-architect . For product, design, frontend, and Agent orchestration personnel; new tasks should use this entry point directly.
The prompt enhancements and vocabulary library are adapted from the fixed snapshot of google-labs-code/stitch-skillsby Google LLC and contributors, Apache-2.0, see LICENSE.txt. This upstream is not an officially supported Google product. For sources and local integration records, see Sources and Boundaries。
When to use
- "Organize this PRD into a set of page-by-page design specs and prompts that can be handed to Stitch."
- "Write the Instance Center Stitch design prompt in the module directory of full-stack-doc."
- "Convert the existing page contracts into prompts; follow the design system used in the application."
- "Polish 'make an appointment page', give a draft first." / "Only modify the search box on the existing page."
Inputs and Paths
| Input | Work Path | Deliverable View |
|---|---|---|
| PRD / feature design package / multi-page requirements | Inventory sources -> page-by-page contracts -> compile prompts -> coverage and tasks | Full package |
| Spec only | Organize only spec contracts and gaps, do not compile prompts | README/design overview/page-by-page contracts or equivalent single file |
| Existing specs | Preserve original IDs and business rules, fill gaps -> compile prompts | Full package or module documents |
| full-stack-doc module | Follow its document directory, module name, and version, write only Stitch content | Module single file |
| Vague idea | Convert vague terms into components, real copy, and states, mark assumptions | prompt-only draft |
| Precise local modification | Clarify the target page, area, and modification delta | prompt-only edit |
First distinguish product scope from output view. Small prompt tasks do not require completing the full product PRD. Missing platform, brand, or data are only explicit suggestions; conflicts involving business permissions, dangerous operations, or page responsibilities are listed as to be confirmed, and confirmed requirements are not changed on one's own initiative.
Workflow
Step 1: Verify Sources
Read the user-specified PRD, feature list, NAVIGATION, UI-STRUCTURE, USER-FLOWS, MASTER-PLAN, module UI, DESIGN.md; read only relevant materials, record source paths/versions/sections and "confirmed, suggested, to be confirmed." Check existing artifacts first, update incrementally, do not generate a second source of truth.
Step 2: Define Contracts
According to Artifact Contracts organize fixed fields for page responsibilities, entry/return, shell/business area/Agent sidebar, data and actions, permissions, states, recovery, responsiveness, accessibility, and acceptance. A page is not equal to a modal, sidebar, or state variant. Follow the original page/feature/flow IDs.
Step 3: Connect Flows
Draw navigation and key operations in Mermaid; for each path write the trigger, preconditions, actions, feedback, next step, and cancellation/failure/recovery. Define the shared shell only once, and write the differences page by page. Do not substitute a few good-looking happy-path pages for complete coverage.
Step 4: Compile prompts
According to compilation rules choose inline / applied-system / targeted-edit; each prompt strictly uses [Context] → [Layout] → [Components], layout numbering, controls with actual labels, states, and behavior. One prompt binds one page and the specified states; related variants may be grouped, but each item must be traceable.
Step 5: Split tasks
Bidirectional association among pages/states → prompts → tasks; tasks include prerequisite dependencies, inputs, artifacts, acceptance, and evidence, reuse existing OpenSpec/Spec Kit tasks, and do not create a conflicting plan of your own. Proceed in the order of shared structure → main paths → exception recovery → cross-platform verification.
Step 6: Verify handoff
According to acceptance checklist check coverage, links, patterns, and business semantics; for a complete package run this skill scripts/validate_package.py. Report three levels: structural validation, semantic review, and actual generation; document completion does not equal remote design or runtime acceptance completion.
Default viewports: Mobile 390×884, Tablet 768×1024, Desktop 1280×1024. When the user explicitly specifies otherwise, comply and record the reason for the override. Viewports are design targets, not MCP deviceType enumerations or server-side guarantees.
Fixed output
- Complete package:
README.md、DESIGN-SPEC.md、pages/<page-id>.md、prompts/<prompt-id>.md、COVERAGE.md、MASTER-PLAN.md、manifest.json. For directories, prefer the existing location; otherwise recommenddocs/stitch-design/。 - Module documentation: use module template, include the same semantic sections, maintain only one copy of the content; do not write a duplicate set of files at the same time.
- prompt-only: metadata/assumptions outside the prompt code block, and inside the code block only the three sections of body text; can be saved as
next-prompt.mdas requested by the user, compatible with stitch-ui-loop. - JSON input can also be normalized; JSON output is provided when the user requests it, and fields must be marked as local semantics, not freezing runtime enumerations such as models, devices, or fonts.
For first full use, first read instance center end-to-end example; for Agent execution confirmation, read Agent Browser conversion example; for short requests and recovery, see pattern examples. These are teaching materials; example data and historical completion states must not be carried into the target project.
Rules and inapplicable boundaries
- No credentials, network access, or Stitch MCP are required throughout; this skill does not create projects, apply design systems, generate screens, upload data, or implement business code.
DESIGN.mdonly proves that a visual definition exists locally; it cannot prove that the remote project has applied the system. The applied-system mode must be provided by the executor with matching application evidence for the current project.- Do not fabricate APIs, statistics, role permissions, real customer information, or success receipts. Mark example values as demonstrations; do not copy keys, cookies, signed download URLs, or machine absolute paths.
- Do not override approved business rules. For source conflicts, preserve the evidence from each side, and keep the output affected by that part as a draft; independent pages may continue.
- When writing local artifacts fails, keep the existing files, verify the current content before retrying, and do not mark a partial write as complete. In the revision record, note the affected ID and reason.
Handoff
full-stack-doc: Has rules for document layering, naming, and placement; this skill only provides module Stitch content. Upstream feature design is responsible for feature scope and product decisions, and is not copied or rewritten here.stitch-design-md: Extracts visual language from existing assets; this skill consumes its results.stitch-ui-execute: Executes authorized generation/editing, receives specifications, prompts, and independent system metadata; the current tool schema is verified by it.stitch-design-harness: Post-generation comparison, approval, and archiving; the local manifest is not its.stitch/specsexecutable schema, and is not directly overwritten.- See the compilation rules for the on-demand framework contract. Installation entry (description only, not automatically executed):
npx skills add full-stack-skills/stitch-skills --skill <skill-name>. full-stack-doc belongs to document-skills:npx skills add full-stack-skills/document-skills --skill full-stack-doc。
Gotchas and FAQ
Can it still be polished without a spec? Yes. The output is explicitly marked as a prompt-only draft of suggestions, and guessed permissions/APIs must not be written as facts.
Can a read-only old name continue to be used? The old entry point delegates to this skill by name; when this skill is not installed, accurately state the missing dependency, and do not fall back to a copy of the old rules.
What should be done about system conflicts between the framework and the application? The business component structure can still follow the framework, and visual tokens are handed off separately; do not repeatedly inject them into the applied-system prompt.
Does passing validation guarantee consistent output from any LLM? No. Fixed contracts, positive and negative examples, and failure gates constrain the checkable parts; semantic coverage still requires review or model evaluation, and remote effects require actual generation verification.