My workflow is 0-to-1: I want the model to lay down a complete, runnable repo skeleton so I can start editing real content in minute two, not fight tooling for an hour. The failure mode is a model that emits five files, references ten more that don't exist, and leaves the project unbuildable.
The fix was to demand a self-consistent, runnable tree with every referenced file present, pinned enough to install, and a smoke path I can run. I also make it end with an explicit "what's stubbed vs real" list so I know exactly where to point my attention.
Sharing my scaffolding prompt. Curious whether people prefer this all-at-once approach or a thinner skeleton plus follow-ups.
Generate a COMPLETE, runnable marketing-site repo skeleton. Stack: {STACK e.g. Astro + TypeScript} for a static landing site. Assume a fresh directory.
NON-NEGOTIABLE: the output must be internally consistent. Every file you import or reference must also be emitted. No dangling imports, no "add this file" TODOs. If a file is a stub, it must still be syntactically valid and build.
EMIT:
1. Full file tree.
2. package.json with pinned major versions and scripts: dev, build, preview, and a `check` that runs a type/lint pass.
3. Config files needed to build (tsconfig, framework config, .gitignore).
4. src with: layout, one landing page composed of section components, a content module holding all copy, and shared UI primitives.
5. A README with exact setup commands and a "verify it works" section (the commands that prove the build is green).
STUBS: any section without real content gets clearly-labeled realistic placeholder copy in the content module ONLY (never fake logos or fabricated testimonials).
FINISH with a table: file -> [real | stub] -> what I should edit first. Do not output prose between files; tree, then files, then the table.