17.3 Generating scaffolding: folders, configs, and scripts

Goal: generate boring scaffolding fast

Scaffolding is where AI saves you time: folders, boilerplate, scripts, configs, and stubs.

But the goal is not “a lot of code.” The goal is:

• a structure you can build into,
• a runnable entrypoint,
• a test harness,
• clear boundaries (especially around LLM calls).

What scaffolding should include

Minimum scaffolding components:

• README: purpose + run/test commands
• entrypoint: CLI/main server stub
• config loading: env var pattern + .env.example
• LLM boundary: stub module for model calls
• prompts/schemas: placeholder files with version ids
• tests: smoke test harness

Optional but useful:

• .gitignore
• formatting/lint configuration (only if you already use it)
• simple CI workflow (run tests)

Bake boundaries into the scaffold

The scaffold should enforce architecture by default:

• only one module contains provider calls,
• prompts are files, not inline strings,
• schemas are versioned,
• tests import domain logic, not UI glue.

This is how you prevent “prompt soup” later.

Scripts and commands (run/test/dev)

Scaffolding should make your loop short:

• run: one command to run the app
• test: one command to run tests
• dev: (if applicable) a command that runs with hot reload or quick iteration

Even a tiny project benefits from consistent scripts, because it removes friction from the vibe loop.

Copy-paste scaffolding prompts

Prompt A: scaffold only (no full implementation)

We are scaffolding a new project.

Spec:
(paste one-page spec)

Task:
Generate a repo scaffold with:
- file tree
- README with run/test commands
- stubs (TODOs) for core modules
- LLM adapter stub (no real model calls yet)
- prompts/ and schemas/ directories with v1 placeholders
- a minimal test harness

Constraints:
- Keep it thin: no full implementation yet
- No new dependencies unless explicitly required

Output format:
1) File tree
2) Each file in a fenced code block labeled with its path

Prompt B: refine scaffold (diff-only)

Refine the scaffold for clarity WITHOUT adding new features.

Constraints:
- Diff-only changes
- Do not implement business logic
- Improve boundaries, naming, and run/test scripts only

Scaffold review checklist

• Does the file tree match the architecture we chose?
• Is there one obvious entrypoint?
• Is there one obvious LLM adapter module?
• Do prompts and schemas live in files (versioned)?
• Is there a single run command and a single test command?
• Are secrets excluded and documented via .env.example?

Ship point: scaffold commit

Commit after scaffolding. This gives you a clean base for implementation:

• commit message: “Scaffold project structure”
• tests may be minimal, but run/test commands should work

Then proceed to walking skeleton implementation.

Where to go next

• 17.4 Building the walking skeleton
• 17.5 Iterating features with controlled scope