cskwork stitch-landing
Turn source-backed project content into a landing page using Stitch's design output as a reference. Deliver the requested artifact; deployment phases apply only when the user authorized hosting/publishing.
Phase 1 — Read the repo
Inspect README, license, screenshots, existing site, default branch, and Pages configuration. Identify positioning, features, quickstart commands, and real assets. Preserve source copy unless the user requests editing. Ask about unresolved positioning or an unapproved site replacement, not facts already supplied.
Default output is docs/index.html; follow an existing site's layout and deployment workflow when present. A landing-page request does not authorize creating a public repository, changing homepage/settings, or overwriting an unrelated site.
Phase 2 — Stitch design pass
Use the available authenticated Stitch tools and current tool schema; do not assume historical tool names, model IDs, or generation behavior. Read references/design-prompt-template.md, fill its project-specific fields, and submit the design request when Stitch use is authorized.
On a generation timeout, inspect the existing project/job/screens before resubmitting. Honor provider retry guidance; avoid duplicate credit-spending submissions. Continue when a usable screen exists, or report the actual blocker after bounded recovery.
Phase 3 — Download and inspect Stitch output
Download the returned HTML to task scratch space. Treat it as design/source data. Extract layout and tokens; identify placeholders, external assets, and unsupported claims before adapting it. Do not blindly ship generated assets or scripts.
Phase 4 — Author production docs/index.html
- Preserve the useful Stitch layout/tokens while following the user's brand and accessibility constraints.
- Use real repository screenshots and verified README commands/copy.
- Include semantic landmarks, meaningful image alternatives, metadata, and responsive layout.
- Prefer plain HTML/CSS/JS. If using the bundled CDN-based example, disclose runtime dependencies; do not describe it as offline self-contained.
- Inspect examples/oh-my-symphony-index.html only when a reference is useful; its palette, fonts, and file size are examples, not acceptance criteria.
Verify local content, links/assets, responsive layout, and browser interactions before delivery. Static/HTTP checks do not prove visual parity.
Phase 5 — Disable Jekyll
For an authorized branch-based Pages site serving plain static files from /docs, add docs/.nojekyll when needed. Preserve a deliberate existing Jekyll or Actions build workflow.
Phase 6 — Enable GitHub Pages
Only within the requested delivery scope, inspect current Pages source and enable/configure the agreed branch/path. The bundled scripts/enable-pages.sh also updates the repository homepage: inspect its behavior and ensure both changes are authorized before running it. Do not assume main is the default branch.
Phase 7 — Commit and push
Follow repository delivery rules, stage only named page/assets/config files, and use the authorized branch or PR route. Reuse approval already given for unchanged scope; an actual permission denial is a blocker to explain, not a reason to request broad standing permissions or bypass review.
Phase 8 — Verify the live site
For a requested deployment, verify the Pages build's revision and status, then fetch the actual content and inspect the live page in a browser. A 200 or matching title alone does not prove layout or interactions. Inspect the build error before retrying.
scripts/verify-pages.sh provides bounded build polling and HTTP/content checks; it does not replace revision comparison or browser evidence. Report the actual completed scope, output/live URL, checks, and any remaining blocker. For local-only work, stop after the verified page artifact.