Specs Before Prompts
Separate what you want from what the machine needs, and review the plan before it runs.
Before this:02 · Context Is the Product
Deep Research shows you its plan before it runs, and almost everybody skims it and hits go, which is signing a contract because it looked long enough. Over one report, the cost is some noise in your citations. Over a thesis, it is hundreds of hours of machine work aimed by plans you never read, and "aimed" is generous.
Learning outcomes
- State the difference between a requirement and a specification, and produce both for one project.
- Write a spec an agent can build from without asking you three clarifying questions.
- Treat a generated research plan as a document to edit rather than a step to approve.
- Describe your data's shape precisely enough that a model does not have to guess.
What you already have
Deep Research. Give it a research question and it produces a multi-step plan, then autonomously browses hundreds of sources and returns a fully cited report in minutes. Two things about it matter more than the report:
- The plan is editable before it runs. Click "Edit plan" to narrow the scope or name specific databases (arXiv, PubMed) rather than accepting whatever it decided to search.
- The output exports to Google Docs in one click, or converts to an Audio Overview.
The default path is to skim the plan and hit go. The plan is the leverage point; the report is downstream of it.
Concept
Requirements are for you: what you want and why, in your own words. Specifications are for the machine: precise enough that nothing is left to guess, because whatever you leave to be guessed, will be.
Read §2.1 (Requirements: what you actually want) and §2.2 (Specifications: what the machine actually needs) back to back. They are deliberately a pair. §2.5 (Prompting based on data shape) and §5.1 (Data shape: the prerequisite to good prompts) cover the part everyone skips.
The PRD template at /templates/prd and the feature spec at /templates/feature-spec are the artifacts. Both carry an AFD considerations section; fill it in rather than deleting it.
Paired instantiation
| Portable idea | Google (what you have) | Internet Menace (the method) |
|---|---|---|
| Review the plan before execution | Deep Research "Edit plan"; Antigravity Implementation Plan | §2.2: specifications, reviewed |
| Say what you want vs. what to build | A research question | §2.1 vs. §2.2: requirements vs. spec |
| Describe the data before asking | Uploading a CSV and hoping | §2.5, §5.1: data shape first |
| A durable artifact, not a chat turn | Export to Docs | /templates/prd, /templates/feature-spec |
Lab
- Pick a real research question from your current work. Run a Deep Research pass on it.
- When the plan appears, click Edit plan. Narrow the scope. Name arXiv or PubMed explicitly if your field lives there. Cut any step that will return noise.
- Run it. Export the report to Docs.
- Run a second pass on the same question from a deliberately different angle: a competing method, an adjacent field, a contrary result. Edit that plan too.
- Now switch modes. Identify a tool your research actually needs (a scraper, a cleaner, a small dashboard) and write requirements for it in plain language: what you want and why.
- Turn those requirements into a spec using
/templates/prd. Include the data shape: columns, types, row counts, what is missing, what is malformed. - Hand the spec to an agent and count the clarifying questions it asks. Every question is a hole in the spec.
Deliverable
A completed PRD for a tool your research needs, plus two Deep Research reports whose plans you edited rather than accepted.
Self-check
- Give one requirement and its corresponding specification for the same feature. What changed between them?
- Your agent asked four clarifying questions. What does that number tell you about the spec?
- Why does describing your data's shape do more for output quality than rephrasing the prompt?
- What is in a plan you edited that would not have been in the plan you accepted?