Golden Path Scaffolding Prompt: Generate a Paved-Road Project

Most teams don't lack project templates. They lack a project skeleton that matches their conventions: the directory layout the platform team blessed, the lint rules CI actually enforces, the test folder structure reviewers expect. A golden path scaffolding prompt generates that skeleton from a stack description, so a new service starts on the paved road instead of someone's personal preferences.

The platform-engineering crowd has written the concept to death. What's missing is the copyable artifact. Search "golden path" and you get strategic essays about adoption rates and platform orchestrators, like How to pave golden paths that actually go somewhere on platformengineering.org, which argues the case well and then sells you a product. None of them hand you a prompt you can paste into Claude or ChatGPT today.

That's the gap this post fills. A scaffolding prompt is a system prompt that reads two things, your stack and your conventions, and emits a paved-road project skeleton you can commit.

What a scaffolding prompt actually generates

A golden path scaffolding prompt is a system prompt that turns a stack description plus a convention spec into a ready-to-commit project skeleton. Not a running app. The skeleton: the parts every service on the paved road shares before any feature code exists.

Here's what teams use it for:

• Spinning up a new microservice that matches the org's standard layout on day one
• Onboarding a new repo into an existing monorepo without copying a sibling and deleting the parts you don't want
• Generating the lint, format, and pre-commit config so CI passes on the first push
• Producing a CI pipeline stub wired to the same stages every service uses
• Laying out the test directory the way reviewers expect, with one example test so the structure isn't empty
• Writing the README and config stubs that the platform team's checks look for

The point isn't speed for its own sake. It's that the skeleton is correct by construction. New repos drift from conventions when a human guesses. A prompt fed the real rules doesn't guess.

Anatomy of the prompt

The structure is three blocks: variables for what changes, a system instruction for the role, and a locked output contract so the skeleton comes back the same shape every run.

Variables
  {{stack_description}}   - e.g. "Node 20, Fastify, Postgres, pnpm, deployed on ECS"
  {{org_conventions}}     - structure, lint, CI, test rules (paste real standards)
  {{service_name}}        - the new project's name

System prompt
  Role: senior platform engineer who owns the org's golden path.
  Task: generate a paved-road project skeleton for {{service_name}}
        running {{stack_description}}, obeying {{org_conventions}}.
  Rules: no feature code; only structure, config, CI, and one example test.
         Explain any place the conventions were silent.

Output contract
  1. A file tree (as a fenced block)
  2. The contents of each config file (lint, CI, test config)
  3. One example test in the prescribed layout
  4. A short "decisions" list noting any assumptions made

The decisions list at the end matters more than it looks. It's where the model surfaces every spot your conventions didn't cover, which is exactly the list a platform team wants to see so they can tighten the spec next time.

Step-by-step usage

1. Write the stack description in one line

Be concrete about runtime, framework, package manager, datastore, and deploy target. {{stack_description}} of "Node, web app" produces a generic skeleton. "Node 20, Fastify, Postgres via Prisma, pnpm workspaces, deployed on ECS Fargate" produces a skeleton that fits.

2. Paste your real conventions into the variable

This is the step everyone skips, and it's the one that decides whether the output is yours or generic. The {{org_conventions}} variable wants the actual rules: "src/ for app code, test/ mirrors src/, ESLint flat config extending @acme/eslint-config, CI runs lint then typecheck then test then build, conventional commits enforced." If you have an internal handbook, paste the relevant section verbatim.

3. Run the prompt and read the decisions list first

Don't skim the file tree first. Read the "decisions" block. Every assumption listed there is a place your conventions were silent, and silent conventions are how drift starts. If the model assumed something wrong, that's a one-line fix to the variable, not a rewrite.

4. Commit the skeleton, then layer features

The output is a starting point, not a finished service. Commit the skeleton as its own commit so the diff is clean, then build features on top. Reviewers see "scaffold" and "first feature" as separate commits, which is easier to review than one giant initial commit.

5. Feed back what the model got wrong

When a generated scaffold misses a convention, the fix lives in {{org_conventions}}, not in the prompt body. Tighten the spec, and the next service inherits the improvement. This is how the prompt becomes the org's living golden path instead of a snapshot.

Prompt-craft patterns that make the scaffold reliable

Lock the output to a file tree plus contents

Models love to narrate. Without a hard contract they'll write three paragraphs about why you should structure a project before showing the structure. Pin the format:

Output format (follow exactly):
1. ## File tree   - a single fenced block, no prose
2. ## Files       - each config file as its own fenced block with its path as the heading
3. ## Example test
4. ## Decisions   - bullet list of assumptions made where conventions were silent
Do not add commentary outside these sections.

Claude honors a ## Output format heading more reliably than an inline "respond in this structure" instruction. GPT-4o tends to need the contract restated on the last line of the prompt, because it weights the most recent tokens. If your scaffold keeps drifting in shape, that's usually where to look.

Forbid feature code explicitly

Ask for a "project scaffold" and half the time you get a half-built CRUD app. State the boundary: "Generate structure, config, CI, and one example test only. No business logic, no routes, no models beyond what an example test needs." The skeleton stays a skeleton.

Make conventions a hard constraint, not a suggestion

There's a real difference between "follow these conventions" and "the project MUST satisfy every rule in {{org_conventions}}; if a rule is ambiguous, list it in Decisions rather than guessing silently." The second phrasing is what keeps the output on the paved road. Golden paths make the right thing easy; a vague prompt makes the wrong thing just as easy.

Variables you'll set

That second variable carries the post. A scaffolding prompt with a strong {{org_conventions}} value is your golden path. With a weak one, it's just another generic template, which is the same trap the essay-style competitor posts fall into.

Getting started

1. Pick one service type your team spins up often. That's your first paved road.
2. Write its {{stack_description}} in a single concrete line.
3. Pull your real structure, lint, CI, and test rules into {{org_conventions}}. Paste, don't summarize.
4. Run the prompt and read the Decisions block first.
5. Commit the skeleton as a standalone commit.
6. When something's off, fix the convention spec, not the output.
7. Reuse the same filled prompt for the next service of that type, so every new repo starts identical.

For a deeper version of step 6, where the prompt also reads an existing repo to learn conventions instead of being told them, the Golden Path Scaffolding System Prompt pack is built for exactly this job.

A scaffold is only the first step on the paved road. Once the skeleton exists, the next questions are how the codebase teaches itself to new contributors and how conventions get enforced over time. For the first, the repo health scorecard approach turns a fresh repo into a self-explaining one. For keeping the whole monorepo's conventions consistent as it grows, Cursor rules for large monorepos covers the editor-side guardrails that pair with a scaffolding prompt. Together they keep the golden path golden after day one.

Pair the scaffold with an AGENTS.md Starter so your coding agents inherit the same conventions the scaffold was built from, and the paved road extends all the way to the AI tools writing the feature code.