Workflow prompts
Select the named main agent before sending a prompt. The examples do not invoke another agent, approve an artifact, or authorize Azure changes by themselves. Use the workflow guide for the current gates.
End-to-end (orchestrator)
Section titled “End-to-end (orchestrator)”Select 01-Orchestrator to identify the project and next handoff:
Start an APEX project for a patient portal.We have 500 staff, 50,000 patients, and 10,000 daily active users.Gather the missing requirements and identify the next main-agent handoff.Do not deploy anything.For an existing project:
Resume patient-portal. Inspect current recall state and artifacts.Report missing evidence and recommend the next handoff.Do not restore state, change decisions, or skip approvals.
Step 1: requirements
Section titled “Step 1: requirements”Select 02-Requirements. State constraints without inventing technical answers:
We are migrating a .NET ERP system from 12 VMware VMs and SQL Server 2019.We expect 300 concurrent users and require 99.9% availability.Capture our recovery, identity, data residency, budget, and operating requirements.Ask for missing facts before choosing services. We use Terraform.The step produces requirements and an initial SKU manifest. In the owner-approved
shared structured-review candidate, the producer or its authorized Orchestrator
invokes challenger-review-subagent for the required review. Manual
10-Challenger selection is optional, not a prerequisite. Resolve findings and
obtain separate owner approval. See
review finalization and recovery
for recording, validation, and pending native runtime evidence.
Step 2: architecture
Section titled “Step 2: architecture”Select 03-Architect with approved requirements:
Assess agent-output/patient-portal/01-requirements.md.Compare service choices against the approved availability and budget requirements.Use current pricing evidence. Identify unsupported assumptions and blockers.Architecture assessment and cost estimate have independent required reviews. Request deep review explicitly when wanted; it is not the default.
Step 3: design, optional
Section titled “Step 3: design, optional”Select 04-Design for a diagram or decision record:
Diagram the approved patient-portal architecture.Show resources, trust boundaries, client access, and data flows.Mark anything not established by the assessment as unresolved.Write an ADR for the approved hosting choice.Include alternatives, constraints, and the reasons recorded in the assessment.Whether you run Design or skip it, continue to Governance, not directly to Plan.
Step 3.5: governance
Section titled “Step 3.5: governance”Select 04g-Governance:
Discover effective policy for patient-portal at the confirmed target scope.Include inherited assignments and report inaccessible scopes.Reconcile constraints with the approved architecture before planning.Do not change policy assignments.
Step 4: planning
Section titled “Step 4: planning”Select 05-IaC Planner for either track:
Plan the approved patient-portal architecture using the recorded Terraform track.Use current governance constraints, verify module versions and property coverage,and produce the required implementation contract and environment manifest.Escalate unresolved design conflicts instead of filling them with assumptions.The planner consumes governance evidence. Fresh policy discovery belongs to Governance. Complete the required plan review before CodeGen.
Step 5: implementation
Section titled “Step 5: implementation”Select 06b-Bicep CodeGen or 06t-Terraform CodeGen:
Implement the approved patient-portal plan and contracts.Generate the selected track's code and required deployment manifest.Run the required checks and emit the current JSON handoff.Return plan defects to the planner. Do not deploy.Deterministic validation remains required. Challenger review at this step is opt-in.
Step 6: deployment
Section titled “Step 6: deployment”Select 07b-Bicep Deploy or 07t-Terraform Deploy and distinguish request scope:
Validate patient-portal only. Report passed, failed, and unperformed checks.Do not preview, bootstrap resources, regenerate code, or apply changes.Preview patient-portal against its approved environment.Preserve the raw preview and policy evidence.Stop after reporting the preview. Do not request or perform apply.Prepare the next approved deployment phase for patient-portal.Present current policy and preview results, including destructive changes.Wait for explicit approval before applying that phase.A missing prerequisite does not expand a validation-only or preview-only request. Record provisioning and application-health outcomes separately.
Step 7: documentation
Section titled “Step 7: documentation”Select 08-As-Built:
Document the observed patient-portal deployment.Use the deployment evidence and verified inventory.Include failed checks, unresolved issues, and unverified operational procedures.Do not describe planned resources as deployed.This step produces the required 07-* workload records. It does not publish or
rewrite this documentation site.
If a step fails
Section titled “If a step fails”Return the exact error and evidence to the owning step. Code defects return to CodeGen; contract mismatches return to Plan; stale policy discovery returns to Governance. Re-run affected reviews after repairs.
An empty result is usable only when discovery actually completed for the required scope. Authentication failure is not evidence that no policy applies.
Standalone agents
Section titled “Standalone agents”
Orchestrator
Section titled “Orchestrator”Use 01-Orchestrator to inspect evidence and recommend a main-agent handoff.
It does not execute the entire main-agent sequence automatically.
Diagnose
Section titled “Diagnose”Select 09-Diagnose:
Investigate HTTP 503 from app-payment-api-prod in rg-payment-gateway-prod.Start with read-only checks. Separate observations from hypotheses.Do not restart services or change configuration without approval.
Challenger
Section titled “Challenger”Select 10-Challenger for an optional manual review. In the shared-review
candidate, it coordinates the same read-only challenger-review-subagent used by
automatic producers. It captures metadata, invokes the synchronous native task,
and records and validates the actual attributed JSON output. It does not replace
the leaf’s independent findings or approve deployment.
Review the patient-portal implementation plan and its contracts.Use the required review scope and identify findings with evidence.Do not edit the reviewed artifacts or approve deployment.