stitch-loop

Stitch Bounded Page Build Loop

Quick Start

1. "Complete the current order page of the store appointment site relay-style; provide locally reviewable results first."
2. "Generate two pages in the approved backlog order and hand off; preserve the existing scope and sources."
3. "After an interruption, read-only verify the remote state and the current baton; flag the missing inputs and verification status."

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

Capability Boundaries

✅ Good at handling

• Complete the current order page of the store appointment site relay-style.
• Generate two pages in the approved backlog order and hand off.
• After an interruption, read-only verify the remote state and the current baton.

⚠️ Requires assets

• SITE.md, DESIGN.md, and the current next-prompt.md.
• Project metadata, existing pages, and authorized rounds.
• Available Stitch tools and the target output root directory.

❌ Inapplicable scenarios and handoff

• Generating only a site blueprint → stitch-site-md.
• One-off prompt polishing → stitch-ui-prompt-architect.
• Infinite background monitoring or automatic deployment → use the product scheduling/deployment process, and deliver the current baton and the reason for stopping.

Workflow

When the user requests full delivery, closed loop, high fidelity, editable HTML, or formal archiving, you must switch to stitch-delivery-harness; this Skill is only responsible for the bounded page relay. Tool success text must not be used to mark completion. The delivered visual convergence rounds are constrained by the specification comparison.max_rounds (default 3); after stagnation, a structural redo is required, and the user's explicit approval remains the final criterion.

1. Read the baton's page, SITE.md's sitemap/backlog, and the actual files; page only allows a safe slug, with no slashes or ..
2. Choose an authorized to-do item; verify the project and the current system, do not rebuild existing pages, and when the backlog is empty or the round limit is reached, stop immediately and record it.
3. Call the prompt architect according to the project's applied system/inline fallback conditions; generate once, and on timeout first reconcile the three read-only items.
4. Download and verify the screenshot/HTML and navigation in the staging directory, and only integrate into the actual site root after verification passes; keep the old version for recovery.
5. Update SITE.md's evidence status and the next baton; if the scope is complete, write a clear completion/stop statement, and do not spawn tasks on your own.

Order by dependency: source verification → local artifacts → authorized external operations → verification handoff. For multiple tasks, do the current main path first; when information is missing, first output an assumption draft, then precisely list what is missing and its purpose, without using vague prompts like "please provide more context."

Security and Result Verification

Do not read unrelated account configurations or collect user passwords; credentials are provided only by the environment or authorized connectors. Examples use demo data only; before uploading, replace customer names, phone numbers, and order numbers with demo values, 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 must note sources, decision rationale, actual execution, and parts not yet verified.

• page will not escape the site root directory.
• Write once per round; for unknown results, first get_project/list_screens/get_screen.
• Unverified pages are not marked complete, and stopped states will not resume automatically.

Customizable: maximum rounds, site root, page list, cache reuse strategy, and system mode. Value-added checks: baton path constraints; bounded loops; cross-round evidence handoff.

FAQ

Q1: What is the main deliverable? Input page: orders; the sitemap already has orders.html and it has been accepted → skip rebuilding this round, choose from authorized to-dos; if there are no to-dos, stop and do not generate a new project.

Q2: When should a different entry point be used? Generate only a site blueprint → stitch-site-md; one-time prompt polishing → stitch-ui-prompt-architect; unlimited background monitoring or automatic deployment → use the product scheduling/deployment process, delivering the current baton and stop reason.

Q3: What happens when inputs are missing? First provide a clearly marked local assumptions draft, and list "Needs to be supplemented: SITE.md, DESIGN.md, and the current next-prompt.md; project metadata, existing pages, and authorized rounds; available Stitch tools and target output root directory." Write operations that depend on these inputs are not executed.

Q4: How is completion determined? page will not escape the site root directory; write once per round; for unknown results, first get_project/list_screens/get_screen; unverified pages are not marked complete, and stopped states will not resume automatically.

Q5: How is it customized? Maximum rounds, site root, page list, cache reuse strategy, and system mode; when not provided, use the existing project values and state the assumptions.

Q6: Does it automatically upload, install, or go live? Only actions covered by the current request and existing authorization are executed; without a remote receipt, do not claim upload success, and without runtime verification, do not claim it is live. Additional installation or scope expansion requires explaining the specific impact first.

Reference as needed

• When executing detailed mapping, APIs, or templates, read Extended workflow。
• When encountering failures/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 basis for local implementation is the source code accompanying the current skill and pinned upstream snapshot; the structure follows the 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 the user needs to select and execute a verifiable, recoverable professional workflow for the current request. When this skill is loaded. First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: According to .stitch/SITE.md, DESIGN.md, and next-prompt.md, continue and complete the authorized Stitch page build; it is triggered when the user asks to continue iterating according to the backlog and hand off the next page. Writing only prompts, planning, or running indefinitely in the background does not belong to this entry point..

Rules

• Read before write: first confirm the current state and real capabilities, then perform actions that will change the 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 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: Perform 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 that will be called, the objects that will be changed, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute in the minimum sufficient steps, and record evidence at key state changes; every external call retains an associable state or receipt.

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 are consistent with the user's intent, and adjacent tasks were not mistakenly routed to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values were used to replace required values.
• All writes, payments, publications, or irreversible actions are within the scope authorized by the user.
• The results have been verified with independent checks; only "the command succeeded" or "the file exists" does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Mistaking the plan for the result: a document or prompt is 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-volume, publication, overwrite, and payment are not natural extensions of ordinary read/write operations.
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; writes, payments, publication, 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 you need to determine inputs/outputs, state, and authorization points, read references/workflow-contract.md。
• When you need self-checks before delivery, read references/validation-checklist.md。
• In timeout, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation denial, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。