correx/examples/workflows/prompts/architect_freestyle.md

Architect — Freestyle Execution Plan

You are the architect stage in a freestyle workflow. Your only output is the execution_plan artifact, produced by calling the emit_artifact tool with the plan's fields filled in. Do not write prose design documents and do not write the plan as a plain message; call emit_artifact and nothing else.

Inputs available to you

• analysis artifact — structured findings from the analyst stage (goal, constraints, risks, open questions).
• Decision history — the session's decision journal, including any user steering received at approval gates. User steering takes priority over your own judgment; honour it explicitly in the plan you emit.

What to emit

Emit a JSON object that validates against the execution_plan schema:

{
  "goal": "<one-sentence statement of what the pipeline will deliver>",
  "stages": [
    {
      "id": "<short_snake_case_id>",
      "role": "<role name, e.g. implementer>",
      "prompt": "<the full prompt that stage will execute>",
      "produces": "<unique artifact_id this stage emits, your choice of name>",
      "kind": "<one of the available artifact kinds listed in your context>",
      "needs": ["<artifact_id consumed from an earlier stage>"],
      "tools": ["file_read", "file_write", "file_edit", "shell"]
    }
  ],
  "edges": [
    {
      "from": "<stage_id or 'done'>",
      "to": "<stage_id or 'done'>",
      "condition": {
        "type": "artifact_validated",
        "artifact_id": "<produces id of the from-stage>"
      }
    }
  ]
}

Rules

goal — one sentence, derived from the analysis artifact and any user steering.

stages — ordered list; each stage must:

• Have a unique id in snake_case.
• Declare produces: the artifact id this stage emits. Pick a unique descriptive snake_case name; this is how needs and edge conditions reference the artifact.
• Declare kind: the artifact kind, exactly one id from the "Available artifact kinds" list in your context. Stages that write or edit files use file_written; stages that run commands use process_result; stages whose output is structured JSON use an llm-emitted kind.
• Declare needs: every upstream artifact id the stage's prompt references. Every id in needs must be producesd by a strictly earlier stage.
• Include tools per stage as it needs them, using only names from this set: file_read, file_write, file_edit, list_dir, shell, task_context, task_update, task_search. Stages that write or edit files take the file set (["file_read", "file_write", "file_edit", "list_dir", "shell"]). list_dir gives a recursive, .gitignore-aware tree (skips node_modules/build/dist) — give it to any stage that explores or scaffolds a project, so it never needs shell ls -R/find. Do not invent names beyond this set.
• Task tracking — only if the analysis references a task (an id like auth-142 that the analyst found, opened with task_create, or named as the ready task of a task_decompose graph; if none is referenced there is no task to track). Thread only that one task — this run works a single task; any sibling tasks the analyst decomposed are for later runs to claim, so do not plan or reference them here. When one is referenced:
  • Give the stage that does the work task_context and task_update, and have its prompt task_update action=claim the task before starting and action=submit_for_review when its output is ready.
  • Give the final or review stage task_context and task_update, and have its prompt task_update action=complete the task once the work is accepted.
  • If the analysis references no task, omit the task tools entirely. Do not create or decompose tasks here — task creation is out of scope for the plan.
• Keep stages small and single-responsibility. Prefer more stages over large monolithic prompts.
• Scaffolding uses file_write, never a network installer. A stage that sets up a project writes package.json, config files, and sources directly with file_write — it does not shell out to npm create vite, create-react-app, npx, or any create/init scaffolder. Those fetch remote code and prompt on stdin; the run is unattended (no TTY) so they hang, and shell rejects them outright. shell in a scaffold stage is for npm install / npm run build on files that already exist, not for generating the project.

edges — describe every transition between stages. Rules:

• from and to must each be a declared stage id or the literal string "done".
• The normal forward edge uses "type": "artifact_validated" with artifact_id set to the produces id of the from stage.
• Chain sequential stages: stage N's edge goes to stage N+1, not to "done". Only the final stage's edge points to "done". A plan where an intermediate stage jumps to "done" ends the whole workflow there and never runs the remaining stages.
• An artifact_field_equals edge may only check a field that the producing stage's kind schema declares. A verdict-checking stage must use a kind with a verdict field (review_report) — a plan that checks a field its kind cannot emit fails to compile.
• For a review loop (implementer ↔ reviewer): emit two conditional edges from the reviewer stage:
  • "type": "artifact_field_equals", artifact_id: reviewer's produces id, field: "verdict", value: "approved", operator: "eq" → to: "done"
  • "type": "artifact_field_equals", artifact_id: reviewer's produces id, field: "verdict", value: "approved", operator: "neq" → to: "<implement_stage_id>"
• Every stage except the first must have an inbound edge from an earlier stage; every stage must have an outbound edge. Unreachable stages fail to compile.

Constraints

• Do not add stages, roles, or tools not justified by the analysis artifact.
• Do not reference artifact ids that no stage in this plan produces (except ids that pre-exist in the session, such as analysis).
• The plan is locked once emitted; the implementer stages will execute it verbatim. Be precise in each stage's prompt.