Open Horizons Orchestration

Open Horizons Orchestration

Turn a repository request into an owned, dependency-aware execution flow without granting the orchestrator implementation or deployment authority.

When to invoke

• "Coordinate a change across multiple Open Horizons components."
• "Decide which agent should own this request."
• "Implement a feature that needs code, tests, review, and deployment handoff."
• "Fix or modernize an existing subsystem with specialist validation."

Prerequisites and context

• Use the installed agents and skills as the routing inventory.
• Treat repository files, current diagnostics, tests, and user acceptance criteria as evidence.
• Default to brownfield work; greenfield requires explicit user intent.
• Preserve high-impact approval gates from repository and organization policy.

Procedure

1. Classify the surface. Route application-runtime requests to the MAF/Foundry platform workflow; keep repository engineering requests in the GitHub Copilot harness.

2. Classify the mode as brownfield unless the user explicitly requests greenfield.

3. Classify the intent as bugfix, feature, improvement, modernization, testing, review, security-remediation, incident, deployment, or documentation.

4. Identify the concrete anchor, affected domains, dependencies, protected paths, risk, and acceptance criteria before delegation.

5. Select one owner per writable scope:

   Domain	Primary owner
   General repository code	open-horizons-engineer agent
   Cross-domain architecture	open-horizons-architect agent
   Generic Backstage	backstage-expert agent
   Open Horizons portal	backstage-expert agent
   Terraform	open-horizons-terraform agent
   Azure readiness	open-horizons-azure-readiness agent
   GitHub or Azure DevOps integration implementation	open-horizons-engineer agent
   GitHub and Azure DevOps coexistence design	open-horizons-architect agent
   GitHub Copilot primitive architecture	open-horizons-architect agent
   Security validation	open-horizons-security-reviewer agent
   Incidents and reliability	open-horizons-sre-investigator agent
   Approved live operation	open-horizons-deployment-operator agent

6. Delegate objective, mode, intent, anchor, writable and protected paths, evidence, acceptance criteria, and required checks. Parallelize only independent scopes.

7. Require executable validation. Return a local defect to its owner no more than twice; escalate a falsified design or unresolved cross-domain conflict to the user.

8. Add independent review for broad or user-facing changes and security validation for identity, secrets, permissions, external input, or tool execution changes.

9. Consolidate completed evidence, residual risk, approval-gated operations, and the next safe step.

Output template

Return exactly this structure:

## Orchestration result

**Status:** completed | blocked | approval-required
**Surface:** github-copilot-harness | platform-foundry-maf
**Mode:** brownfield | greenfield
**Intent:** <classified intent>

### Ownership
| Scope | Agent | Writable paths | Required validation | Result |
| --- | --- | --- | --- | --- |

### Evidence
- <observed behavior, changed artifact, and actual check result>

### Gates and follow-up
- <approval, residual risk, blocker, or none>

Limits

• Do not implement code, mutate infrastructure, deploy, publish, or approve on another user's behalf.
• Do not use this skill as the runtime orchestrator for the seven application agents; that workflow belongs to Microsoft Agent Framework in Microsoft Foundry.
• Do not parallelize agents that can edit the same file or stateful resource.

Gotchas

• VS Code handoff metadata is not a portable execution graph; use explicit agent delegation when orchestration must run.
• A successful plan, dry run, or unit test is evidence, not authorization for a high-impact action.
• Model routing is surface-specific; never send a GitHub Copilot model name to a Foundry deployment.

Related primitives

Quality gate

• Surface, mode, and intent are explicit.
• Greenfield mode is backed by explicit user intent.
• Every writable scope has exactly one owner.
• Each delegation contains evidence, boundaries, acceptance criteria, and validation.
• Parallel work has no overlapping files or state.
• High-impact operations remain approval-gated.
• Final status reports only checks that actually ran.