# Stitch Landing

> Build a project landing page from its README and screenshots using Stitch for design, with optional authorized GitHub Pages delivery. Use when the user asks for this Stitch-based workflow; generic landing-page requests need not use Stitch or publish.

- Skill: `cskwork/stitch-landing` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add cskwork/stitch-landing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cskwork/stitch-landing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: cskwork (https://skillmd.com/u/cskwork)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cskwork/stitch-landing

---


# 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](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](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](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](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.