5.5 Capture a reusable template

Goal: make the next project faster

You just did the complete loop: generate → run → refactor → add feature → ship. The highest-leverage move now is to capture the prompts and checklists that worked so your next project starts at SP2 instead of at “blank screen.”

What to save from this chapter

Save artifacts that reduce future ambiguity:

• Your best prompt: the one that produced the cleanest runnable output.
• Your acceptance criteria list: the tests/examples that defined “done.”
• Your refactor prompt: the one that got a small diff.
• Your feature prompt: the one that avoided regressions.
• Your “debug prompt”: how you asked for fixes when something failed.
• Your file map: which files contain what responsibility.

Build a small “prompt pack”

Create a tiny set of copy/paste prompts you can reuse. Even a plaintext file is fine. A good “prompt pack” usually has:

• Scaffold prompt: “create project structure + tests + run instructions.”
• Plan-first prompt: “propose a plan only; wait for confirmation.”
• Diff-only prompt: “show diffs; keep changes minimal.”
• Test-first prompt: “write failing tests, then implement.”
• Bug report prompt: “here’s the error and reproduction; propose causes and fixes.”

House rules (the ones that actually help)

These rules are intentionally boring. They keep the model’s output aligned with engineering reality.

• Ask for a plan before big changes.
• Keep diffs small and reviewable.
• Don’t introduce dependencies without asking.
• Prefer readable code over clever tricks.
• Run code early; use tests as truth.
• Never paste secrets into prompts.
• Never use eval/exec on user input.

A reusable starter prompt

Use this template when you want to start a new tiny project fast. Replace the bracketed parts.

You are a senior software engineer helping me scaffold a small project.

Project goal (1 sentence):
[Describe the outcome.]

Constraints:
- Language/runtime: [e.g., Python 3.11]
- Dependencies: [standard library only / allowed libs]
- Security: no dynamic code execution; no secrets in logs/prompts
- Scope: [what is included]
- Non-scope: [what is explicitly excluded]

Acceptance criteria:
- [3–8 bullet tests, with example inputs/outputs]

Output format:
1) Print the file tree.
2) Output each file in a fenced code block labeled with the file path.

Quality bar:
- readable over clever
- clear error handling
- minimal complexity
- small public API surface

Now produce the project.

Version prompts like code

As soon as prompts affect behavior, treat them as artifacts:

• store them in your repo,
• name them with intent (e.g., scaffold-v1.txt),
• change them deliberately and review diffs,
• tie prompt versions to app releases.

Where to go next

• Part III — Beginner Track
• 6. Prompting basics for code
• Back to 5.1