StitchFlow

Turn briefs, mockups, and product context into Stitch UI screens, design variants, Tailwind-friendly HTML, and screenshots. Use when the user wants to explor...

Security Scan

The skill's stated purpose (local design generation via a local toolkit) is plausible, but the runtime instructions reference an API key, install script, and local .env/toolkit usage that are not reflected in the registry metadata — this mismatch and the implicit requirement to run installation commands and read local files are worth caution.

Purpose & Capability

The skill's purpose (generate Stitch UI screens using a local 'stitch-starter' toolkit) aligns with the instructions in SKILL.md. However, SKILL.md claims the tool "Requires Node.js 22+, a configured STITCH_API_KEY, and the local stitch-starter toolkit installed by this repository," while the registry metadata lists no required env vars or install steps. That metadata/instruction mismatch is inconsistent and should be corrected.

Instruction Scope

The instructions explicitly tell the agent to cd into a local toolkit root, inspect the user's project for UI/context, and rely on a .env file containing STITCH_API_KEY. Inspecting the user's codebase and reading the toolkit's .env are reasonable for a local CLI-based design tool, but they are sensitive operations. The SKILL.md does state 'Never print or expose STITCH_API_KEY or .env contents,' but the agent still needs access to those files to operate, which increases risk if the install/run environment is not trusted.

Install Mechanism

There is no formal install spec in the registry, but SKILL.md includes an 'install: "bash install.sh --target all"' directive and says the repository installs a local starter toolkit. Because this is instruction-only (no bundled code), the actual install would come from external repo/script. Running an arbitrary install.sh has non-trivial risk unless the user inspects the script and repository. The homepage is a GitHub URL (helpful), but the skill provides no packaged, vetted install source in metadata.

Credentials

SKILL.md requires a STITCH_API_KEY (expected in the toolkit .env) and Node.js 22+, but the registry lists no required env vars or primary credential. Requesting a single service API key for the tool is proportionate to the stated purpose, but the omission from declared requirements is a red flag. Also the agent will read the toolkit folder and latest-screen.json; if that folder contains other secrets, they could be exposed accidentally. The skill does not request unrelated credentials, but it implicitly accesses local config files.

Persistence & Privilege

The skill does not request permanent presence (always:false) and does not claim to modify other skills or system-wide settings. It writes artifacts into a local runs folder within the toolkit root, which is consistent with its stated purpose.

What to consider before installing

This skill appears to be a local CLI wrapper that needs a local 'stitch-starter' toolkit and a STITCH_API_KEY stored in a .env file. Before installing or using it: 1) Inspect the GitHub repository and the install.sh script yourself to ensure no unexpected commands (network exfiltration, chmod +x of unknown binaries, downloading from untrusted URLs). 2) Keep the STITCH_API_KEY scoped with least privilege for just the Stitch service, and consider providing it via a dedicated environment variable or secret manager rather than a shared .env if you have other secrets in that folder. 3) Run the installer and CLI inside an isolated environment (container or VM) until you verify behavior. 4) Verify outputs and any network calls (e.g., via network monitoring) the first few runs. 5) Ask the skill author to update registry metadata to declare required env vars and an explicit, verifiable install source — that will make the skill's requirements coherent and easier to audit.

Use this skill when the user wants to create a new screen, refine an existing one, generate design variants, or export local HTML and screenshots through Stitch.

It uses the local toolkit at ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter} instead of a Stitch MCP tool.

Local setup

• Toolkit root: ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}
• API key is expected in ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/.env
• Outputs are saved to ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/runs
• The latest single-screen result is tracked in ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/runs/latest-screen.json

When to use

• The user says to use Stitch or StitchFlow
• The user wants a screen generated from a brief, spec, or rough idea
• The user wants design variants before implementation
• The user wants targeted visual edits to a generated screen
• The user wants HTML and screenshots exported locally for review

Workflow routing

• New screen from a prompt or brief: Read text-to-design
• Targeted changes to an existing Stitch screen: Read edit-design
• Multiple directions from one base screen: Read variants

Core rules

1. Before any Stitch command, rewrite the user request into a stronger design prompt.
2. If the user already has a codebase or UI context, inspect it first and carry that context into the prompt.
3. Prefer DESKTOP by default unless the user clearly asks for mobile or tablet.
4. For first-pass exploration, prefer one generated screen plus 3 variants.
5. If a screen is already close, prefer edit over full regeneration.
6. Always tell the user where the resulting files were saved.
7. Never print or expose STITCH_API_KEY or .env contents.

What good output looks like

• the brief is rewritten into a stronger design prompt
• the right Stitch workflow is chosen: generate, edit, or variants
• the command completes and saves artifacts locally
• the response includes project id, screen id, output folder, and what to do next

Prompt shaping

Use prompt-keywords to translate vague requests into design language Stitch understands better.

Structure prompts like this:

[overall vibe, product intent, and audience]

Platform: [web/mobile], [desktop/mobile]-first

Page goal:
- what the screen is for
- what primary action matters most

Page structure:
1. Header / navigation
2. Main content / hero / dashboard body
3. Secondary content
4. Footer / actions / supporting detail

Visual direction:
- palette roles
- typography tone
- spacing density
- component style

After running Stitch

Report:

• the command used at a high level, not the secret env
• the project and screen ids
• the output folder under ${STITCH_STARTER_ROOT:-$HOME/.agents/stitch-starter}/runs
• the HTML and image artifact paths if they were downloaded
• a short design assessment and the best next step

References

• cli-usage
• prompt-keywords