engineer-prompts

Engineer Prompts

Turn an informal request into a prompt whose result can be verified. Keep the core contract provider- and version-neutral; add target-specific advice only when a target model is explicitly supplied and current documentation supports it.

Workflow

1. Extract the requested outcome. Describe the finished state, not the activity.
2. Write observable success criteria. Avoid criteria such as "high quality" unless a measurable definition follows.
3. Separate boundaries from permissions:
   • boundaries state what is in and out of scope;
   • permissions state which reads, writes, network calls, installations, or external side effects are authorized.
4. Name the tools that may be used and the evidence required before claiming completion.
5. Define stop conditions for completion, blockers, exhausted retries, or required user decisions.
6. Include target_model only when the user requests model-specific optimization. Check version-matched current documentation first (see research-systematically) before adding model-specific guidance.
7. Check the contract structurally by hand: every required field present, every list non-empty with distinct strings, no unknown fields, fields kept in the canonical order below, no model names outside target_model. Then perform the semantic audit below — structural checks cannot determine whether prose is genuinely observable or authorized.
8. When a textual prompt is needed, render the contract into a stable prompt: one section per field, in the canonical order, wording taken verbatim from the contract, nothing added.

Contract shape

Use a JSON object with these required fields, in this order:

{
  "outcome": "A concrete finished state",
  "success_criteria": ["An observable condition"],
  "boundaries": ["A scope limit"],
  "permissions": ["An explicitly allowed action"],
  "tools": ["A tool or capability"],
  "evidence": ["Proof required for a claim"],
  "stop_conditions": ["A condition that ends or pauses work"]
}