Generate a Full Module From a Written Spec

Instead of asking Claude for a single function, you give it a short written specification — inputs, outputs, constraints, and file layout — and it returns a complete, coherent module.

Claude is strongest when the target is fully defined before generation starts. A spec removes ambiguity, so the model spends its reasoning on implementation rather than guessing your intent. It also gives you a stable artifact to diff future changes against.

Use this when you know exactly what you want but writing the boilerplate is the slow part: a new API client, a parser, a validation layer, a set of typed models.

Skip it when the design is still unsettled. If you don't yet know the interface, you'll spec the wrong thing and generate confident, wrong code. Explore the design first (see the architecture cards).

You are writing production code. Implement the following module.

Spec:
- Purpose: <one line>
- Public interface: <function/class signatures>
- Inputs / outputs: <types>
- Constraints: <perf, deps allowed, error handling>
- File layout: <paths>

Rules:
- Match the style of the existing codebase.
- No TODOs, no placeholder logic.
- Include the minimal tests that prove each public function.
Return each file in its own code block with the path as a header.

Feeding Claude a 12-line spec for a RateLimiter class (token-bucket, thread-safe, no external deps, plus a try_acquire() method) returns the class, the internal bucket logic, and three unit tests in one pass — ready to paste behind a review.

Pair the spec with two or three real files from your codebase as context so the output matches your conventions (naming, error types, logging). Then ask Claude to also return a one-paragraph rationale for any decision the spec left open — that surfaces assumptions you can correct before they harden.

• Writing a vague spec ('make a good auth module') — you get generic code that fits no real system.
• Omitting the 'no placeholder logic' rule, then shipping stubbed functions that quietly return null.
• Not asking for tests, so you have no cheap way to verify the generated code actually works.