stitch-site-md

Write a Stitch site blueprint

Quick Start

1. "Establish a page blueprint for the store appointment site; provide locally reviewable results first."
2. "Organize the existing homepage and to-do list into a sitemap; preserve the existing scope and sources."
3. "Define the next round of page priorities and non-goals for the team; mark missing inputs and verification status."

For designers, front-end developers, and teams maintaining this process. Designers provide intent and materials, developers provide engineering/tools, and the team preserves sources and acceptance status during handoff.

Capability Boundaries

✅ Good At

• Establish a page blueprint for the store appointment site.
• Organize the existing homepage and to-do list into a sitemap.
• Define the next round of page priorities and non-goals for the team.

⚠️ Requires Materials

• Site requirements description.
• The actual file tree and verified page states.
• Brand style and an optional real projectId.

❌ Inapplicable Scenarios and Handoff

• Extract colors and fonts → stitch-design-md.
• Run the multi-page build loop → stitch-ui-loop.
• Production operations or database architecture → project specification process, delivering the business scope of this blueprint.

Workflow

1. Read requirements, the existing SITE.md, and actual page files, and protect the approved scope.
2. Fill in identity, mission, audience, and visual direction; clearly mark an unknown projectId as unassociated, and do not leave a fake ID that could be misused.
3. Align with the actual output directory, asset queue, and navigation rules; do not force the use of the default directory.
4. Maintain six sections: identity, visual, architecture, sitemap, backlog, and creative boundaries; mark pages as [x] only when there is existing verification evidence.
5. Prioritize and sort by core paths; verify the six sections, each route, and the stop boundaries, then deliver SITE.md.

Sort by dependency: source verification → local artifacts → authorized external operations → verification handoff. For multiple tasks, do the current primary path first; if information is missing, output a draft with assumptions first, then precisely list what is missing and its purpose, without using vague prompts like "please provide more background."

Security and Result Verification

Do not read unrelated account configurations and do not collect user passwords; credentials are provided only by the environment or authorized connectors. Use only demo data in examples; replace customer names, phone numbers, and order numbers with demo values before uploading, and check HTML, screenshots, and file metadata. Do not write keys, session cookies, full base64 text, or signed download URLs into reports/repositories. Unverified parameters, visual effects, and business figures must not be fabricated; outputs should note sources, decision basis, what was actually executed, and what has not yet been verified.

• The template explicitly has six sections, and verification also checks the six sections.
• Completion markers correspond to actual files and verification records.
• An empty backlog does not equal authorization to create additional pages.

Customizable: site root directory, target routes, priorities, audience, creative boundaries. Value-added checks: verified sitemap; priority sorting; scope and stop boundaries.

FAQ

Q1: What is the main result to be delivered? Store appointment SITE.md: homepage index.html [x] (has verification record); orders.html [ ]; prioritize order list; non-goal is payment; Project ID not associated.

Q2: When should a different entry point be used instead? Extract colors and fonts → stitch-design-md; execute multi-page build loop → stitch-ui-loop; production operations or database architecture → project specification process, delivering the business scope of this blueprint.

Q3: What happens when inputs are missing? First provide a clearly marked draft of local assumptions, and list “Needs to be supplemented: site requirements description; actual file tree and verified page status; brand style and optional real projectId”. Write operations that depend on these inputs are not executed.

Q4: How is completion determined? The template explicitly defines six sections, and verification also checks the six sections; completion markers correspond to actual files and verification records; an empty backlog does not equal authorization to create additional pages.

Q5: How is it customized? Site root directory, target routes, priority, audience, creative boundaries; when not provided, use existing project values and indicate assumptions.

Q6: Is it automatically uploaded, installed, or launched? Only perform actions covered by the current request and existing authorization; do not claim upload success without a remote receipt, and do not claim launch without runtime verification. Additional installation or scope expansion requires first explaining the specific impact.

Reference as needed

• When executing detailed mappings, APIs, or templates, read extended processes。
• When encountering failures or abnormal inputs, read anti-patterns and Gotchas。
• When involving edge cases, compatibility, customization, and authorization, read in-depth FAQ。
• When complete inputs, outputs, and verification scenarios are needed, read local application examples。
• The local implementation basis is the current skill's accompanying source code and fixed upstream snapshot; the structure follows Agent Skills specification. The tool's current behavior is subject to the actual schema; when not connected, do not claim to have verified online behavior.

When to use (when to use)

When the user needs to select and execute a verifiable, recoverable professional workflow for the current request , load this skill. First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: organize site requirements and existing pages into .stitch/SITE.md; trigger when it is necessary to determine the website identity, navigation, page status, priority, and creative boundaries for the Stitch Build Loop. Use the corresponding skill for visual token extraction or actually generating screens..

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, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase status; 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 off to a more precise skill.

Step 2: Execute precheck

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; stop at the read-only stage when any key condition is unknown.

Step 3: Form a plan

List the tools to be invoked, 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 every 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 adjacent tasks were not misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no required values were replaced with guesses.
• All write, payment, publish, 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. Treating a plan as a result: A document or prompt is not equal to actual execution; the actual execution level must be indicated.
2. Retrying on error: 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 payment actions are not a natural extension 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; write, payment, 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 inputs/outputs, states, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, refusal of overreach, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。