Write five cross-checked spec documents before coding an app

Before writing code for a resume and cover letter builder (Java 25, Spring Boot, Vue and five MCP servers), the author had Claude Code produce five documents in a terminal: a software requirements spec, a solution architecture, a PRD, user stories and a technical design. Each prompt names the documents to read first, says the SRS wins any disagreement, sends anything unclear to an Open questions list, and repeats shared rules such as the product name, ID prefix and limits. Claude Code builds the PDF and DOCX exports by running a build script that fails on broken diagrams and a trace script that checks every cited requirement ID exists and every Must requirement has a story, and fixes errors until both pass. He then fed it one user story at a time with its requirement IDs and design sections.

With one or two line prompts the documents looked fine but did not fit together: names drifted and requirements vanished between documents. After the prompt changes they stayed consistent, and renaming the product halfway through was a small job. Some errors were his own prompts asking for a database schema and a login the SRS never had. The five documents and a first increment of the app are public. He still reads every document himself and gives no time figures.

The check scripts only prove the documents agree with each other, not that the requirements are right. Telling the agent to log unclear points as open questions, rather than guess, did more than longer prompts. Fix the SRS first when a story exposes a mistake, then the documents that depend on it.