Hacking Specdd Generating Specs From Prompts For Fun And Profit

---
title: "Hacking SpecDD: Generating Specs from Prompts, for Fun and Profit"
date: 2026-05-09
seoDescription: "A practical guide to using AI agents to generate SpecDD specs from rough prompts, then reviewing and tightening those specs before implementation."
excerpt: "You do not have to write every SpecDD spec from scratch. A rough prompt can become a useful first draft, the draft can become a reviewed contract, and the contract can guide implementation. The trick is using AI to make intent cheaper to structure without handing it ownership of the decisions."
author: "Matīss Treinis"
---

One of the more useful discoveries once you start using SpecDD in real work is that the blank page is optional. You do
not have to sit down and produce a polished spec from nothing before anything else can happen. You can begin with the
rough version of what you want: a feature idea, a ticket description, a few notes from a meeting, or the half-formed
prompt you were about to hand directly to an AI coding agent.

The hack is to ask the agent for the spec first.

That changes the shape of the work in a small but important way. If the agent writes code directly from a vague prompt,
its assumptions land in the implementation. If the agent writes a spec first, those assumptions land in plain text,
where they are much cheaper to review, correct, and reuse. The first draft does not need polish so much as it needs to
give you something concrete enough to argue with.

That is where SpecDD becomes a very practical companion to AI-assisted development: you can use the agent to turn messy
intent into structured context, then use your own judgment to decide what the system is actually supposed to do.

## The prompt becomes the contract

Most AI coding workflows treat the prompt as the contract. You describe the feature, the agent writes the code, and the
review happens after the implementation exists. That can work for small tasks, but it is a poor fit for features with
permissions, edge cases, product nuance, or architectural boundaries.

Spec generation gives you another step. The prompt becomes raw material for a spec, the spec becomes the contract, and
the implementation follows that contract.

That may sound like a small distinction until you watch the failure mode change. Instead of discovering during code
review that the agent guessed the wrong ownership model, ignored permissions, or invented a queue because that looked
like a common pattern, you can see those assumptions in the generated spec before the code exists. You can keep the
parts that are right, delete the parts that are invented, and sharpen the parts that were too vague in the original
prompt.

The resulting workflow can stay lightweight: write a rough prompt, generate a spec, review the spec, ask for a plan,
then implement from the reviewed spec. The point is not to add ceremony, but to create one useful checkpoint where
intent can be corrected before it turns into code.

## A rough feature idea

Here is a deliberately ordinary feature idea: