How to Build a Master Prompt from Scratch: Structure, Schema, Variables, and Validation

Building a master prompt starts before writing instructions.

You need one workflow, known inputs, a defined output, an accountable reviewer, and a clear boundary between what the model proposes and what the application or person decides.

Step 1: Define One Workflow

Use this sentence:

Given approved inputs X, produce structured draft Y for reviewer or application step Z.

Name what is outside scope. If the artifact must research, decide, write, approve, and act, split it.

Step 2: Map Sources and Owners

List each input source, why it is authorized, how current it must be, and who owns it. Mark deterministic values such as totals, dates, prices, thresholds, eligibility, and permissions for calculation outside the model.

Identify the domain owner, developer, reviewer, and person authorized for any real-world action.

Step 3: Write the Instruction Sections

The CyWire definition uses six compiled instruction sections: identity, industry context, task instructions, output format, quality and safety, and constraints.

Give each rule one home. Identity establishes relevant expertise without pretending the model holds a license. Task instructions describe ordered work. Quality and safety define useful review behavior. Constraints cover hard boundaries.

Read Inside a Master Prompt for why each section exists.

Step 4: Declare Typed Variables

Variables are runtime inputs, not string-replacement trivia.

{
  "source_text": {
    "type": "string",
    "required": true,
    "description": "Authorized source content for this record"
  },
  "output_locale": {
    "type": "string",
    "required": true,
    "allowed_values": ["en-US", "en-GB"]
  }
}

Define type, required state, description, limits, allowed values, and sensitive-data treatment. Validate before the model call.

Step 5: Design the Output Schema

Work backward from the consumer. What exact object can the UI, reviewer, storage, or next code step use?

{
  "type": "object",
  "required": ["status", "source_references", "draft"],
  "additionalProperties": false,
  "properties": {
    "status": {
      "type": "string",
      "enum": ["draft", "missing_information", "out_of_scope"]
    },
    "source_references": {
      "type": "array",
      "items": { "type": "string" }
    },
    "draft": { "type": ["object", "null"] }
  }
}

Represent uncertainty and missing information structurally. Do not force every request into a success object.

Step 6: Connect Instructions to Schema

Use the same field names and states in task instructions, output rules, examples, tests, and application types.

Contradictions are common: prose requests a summary, the schema calls the field analysis, and the example uses result. Choose one contract.

Step 7: Write Edge Constraints

Cover missing sources, conflicts, out-of-scope requests, untrusted content, sensitive data, unsupported conclusions, prohibited actions, and review.

Good:

When source references conflict, return both references in the conflicts field and set status to review_required.

Weak:

Always be accurate.

Specific behavior can be tested.

Step 8: Compile and Validate the Artifact

Confirm that the master-prompt JSON itself parses, required sections exist, variable definitions are valid, the schema is valid for its declared draft, and every example validates.

The official JSON Schema guide describes how schemas define structure, types, properties, and required fields.

Step 9: Build Representative Tests

Include normal, boundary, missing, conflicting, malicious, sensitive, and out-of-scope cases. Define expected schema state and content criteria before running them.

One successful example is a demo, not a test suite.

Step 10: Validate Output in Layers

1. Parse the model response.
2. Validate against the JSON Schema.
3. Run deterministic business checks.
4. Resolve source references.
5. Apply policy and authorization checks.
6. Route to accountable review.

Schema-valid output can still contain a false fact. Each layer owns a different failure.

Step 11: Version and Release

Assign immutable version identity to the instructions, variables, schema, constraints, and tests. Store the version with output. Release through review, limited rollout, monitoring, and rollback.

Step 12: Keep Actions Outside the Model

The model returns structured data. Application code decides whether an authenticated and authorized user may publish, send, update, purchase, schedule, approve, or otherwise act.

Step 13: Document Ownership

Name who approves source changes, prompt changes, schema migrations, tests, production activation, output review, and incident response. Store those responsibilities with the workflow documentation.

A technically complete artifact without an owner will become stale. A named owner can decide when the workflow, policy, model, or risk has changed enough to require a new version.

Read 10 Master Prompt Best Practices for operating rules and From Master Prompt to Production for integration.

Inspect complete free global and marketplace artifacts in the CyWire marketplace when you need a real production cross-section rather than a shortened article example.