Project 1 — a prompt assistant

The first project is deliberately small and entirely within what stage three covered. Build it and you have something you will use.

Goal. Take a rough request — "help me write something about the delay" — and return a structured, well-formed prompt.

Step 1 — the contract#

Decide the output shape before writing any prompt:

{
  "instruction": "string, the single clear task",
  "context": "string, background the model needs, or null",
  "format": "string, the required shape of the answer",
  "constraints": ["array of strings"],
  "missing": ["array of things the user should clarify"]
}

The missing field is the one that makes this tool genuinely useful rather than decorative. A rough request usually omits the audience, the length, or the purpose. Naming the gaps is worth more than filling them with guesses.

Step 2 — the system prompt#

Apply what stage three taught. Role, task, rules, and an explicit ambiguity policy:

You turn rough requests into well-formed prompts. Return only the JSON object described below. Do not invent context the user did not provide — if something important is missing, name it in missing rather than guessing. If the request is already well-formed, return it largely unchanged.

That third rule is what stops the tool inventing an audience and a tone the user never asked for.

Step 3 — two examples#

Include one rough request and one already-good request. The second teaches restraint, which is the behaviour a tool like this most often gets wrong — everything gets elaborately rewritten whether it needed it or not.

Step 4 — validate#

Parse, then check the contents:

• instruction present and non-empty
• constraints an array of strings
• missing present, even if empty

On failure: retry once, including the specific error. On a second failure, show the user an honest message. Never silently substitute the original text and present it as improved.

Step 5 — evaluate#

Take ten real rough requests of your own. For each, run the original and the assistant's version through a model and compare results.

Score honestly: better, no different, worse. If fewer than half are better, the tool is not working — and knowing that is the point of the exercise.

Extend it#

• Save and reuse prompts, with the results they produced
• Detect domain and adjust the constraints
• Add a "why" field explaining each change, so the tool teaches rather than just transforms