prompt-architect

Prompt Architect

Most defects start as misunderstood requests. This skill converts a loose prompt into a spec precise enough to execute against and to verify against, without inventing scope the user did not ask for.

Method

1. Extract the true intent. State, in one or two sentences, the outcome the user actually wants, not a literal restatement of their words. If their phrasing and their apparent goal diverge, note both.

2. Draw the scope boundary.

   • In scope: the concrete deliverables that satisfy the intent.
   • Out of scope / non-goals: adjacent things you will NOT do. This is the most important part: it prevents both over-reach and silent under-delivery. If you must exclude something the user might expect, say so explicitly.

3. Write acceptance criteria. Testable, observable conditions for "done" (e.g. "endpoint returns 400 on missing field", "existing X tests still pass"). These become the audit checklist later.

4. Separate facts from assumptions. List every assumption you are making to fill a gap the user left. Assumptions are allowed; hiding them is not.

5. Surface open questions. Only genuine blockers or true ambiguities. For each:

   • if it blocks correct work → ask it now, concisely;
   • if not → state the assumption you'll proceed under and continue. Prefer proceeding under a stated assumption over stalling on trivia.

6. Right-size the output. For a big or ambiguous task, present the full spec and confirm before proceeding. For a small, unambiguous task, compress it to a sentence or two and move on: do not bureaucratise trivial work.

7. Split a large request into an ordered plan. One prompt is very often several tasks. "Handle these four improvements and ship it" is not one unit of work, and treating it as one produces a single opaque commit, a pull request nobody can review, and a report that cannot say which part is finished.

   Decompose whenever the request has more than one deliverable, touches more than one subsystem, or would take more than a handful of steps. Each subtask must be:

   • independently completable, and ideally independently correct: something you could stop after and still have left the repo in a working state;
   • one commit's worth of work, because that is exactly what it becomes;
   • ordered by dependency, so nothing is started before what it rests on.