orchestrator-prompt-editing

[STALE — DO NOT USE] Editing the Orchestrator System Prompt

This skill is disabled as of 2026-04-29. Three known staleness issues:

1. Wrong file targeted. Skill assumes .github/workflows/orchestrator-prompt.xml, but redesign mode (installed 2026-04-27, commit 06c799cd) swapped the active prompt to .github/workflows/orchestrator-redesign-prompt.xml via .github/workflows/orchestrator.yml line 51. Both files exist; only one is active. The skill predates this swap.
2. Wrong XML structure. Skill describes the production prompt's 8 sections (<identity>, <directives>, <definitions>, <environment>, three <phase> sections, <practices>). The redesign prompt has a completely different structure: <critical-context-read-first>, <mission>, <core-design-principle>, <authority>, <phases>, <checkpoints>, <abort-criteria>, <initial-directive>, <persistence>, <iteration-until-approval>, etc.
3. "When to edit" framing is production-only. Skill triggers are all behavioral-correction signals (recurring findings, adoption gaps, data-filtering). Redesign-mode edits are usually design-refinement (phase ordering, checkpoint tweaks, scope clarifications) — different shape entirely.

To make current: detect which prompt is active (read .github/workflows/orchestrator.yml and find the cat line); document both prompt structures; add a redesign-mode editing subsection. Until then, edit prompts manually with surgical edits and validate XML afterward.

---

Editing the Orchestrator System Prompt

The orchestrator's system prompt lives at .github/workflows/orchestrator-prompt.xml. This XML file is loaded as the orchestrator's briefing every cycle. It contains ALL orchestrator instructions — identity, directives, definitions, environment, startup steps, close-out steps, and standing practices. Changes here directly affect orchestrator behavior.

Key facts

• Location: .github/workflows/orchestrator-prompt.xml — a single XML file that replaces the previous markdown prompt + STARTUP_CHECKLIST.md + COMPLETION_CHECKLIST.md
• Format: XML with 8 top-level sections: <identity>, <directives>, <definitions>, <environment>, <phase id="startup">, <phase id="work">, <phase id="close-out">, <practices>
• The workflow YAML (.github/workflows/orchestrator.yml) loads this file via cat and passes it as the system prompt
• Human-only change: The orchestrator cannot modify this file itself (it's under .github/workflows/). It must create a question-for-eva issue for proposed changes.

When to edit

Edit the prompt when journal entries or review findings reveal recurring behavioral patterns that tools haven't fixed. Indicators:

• The same finding category appears across 3+ consecutive review cycles
• The orchestrator acknowledges a pattern in its journal but doesn't change behavior
• Tools exist but aren't being used (adoption gaps)
• The orchestrator interprets or filters data instead of reporting canonical values

How to edit

1. Read the journal entries that document the behavioral issue
2. Read the current prompt at .github/workflows/orchestrator-prompt.xml
3. Edit the XML file — add directives/constraints in the appropriate section
4. Validate: python3 -c "import xml.etree.ElementTree as ET; ET.parse('.github/workflows/orchestrator-prompt.xml')"
5. Commit — Eva will need to merge via PR (orchestrator has no Workflows permission)

XML structure

Section	Purpose	When to edit
<directives>	Non-negotiable behavioral constraints	Recurring behavioral failures
<definitions>	Enumerations, thresholds, labels, tools	New thresholds, finding categories, tools
<environment>	Runtime, permissions, communication	Infrastructure changes
<phase id="startup">	Steps S0-S9	Startup procedure changes
<phase id="close-out">	Steps C1-C8	Close-out procedure changes
<practices>	Standing reference (worklog, journal, tools)	Practice updates

Behavioral directives (<directives> section) is the right place for constraints addressing recurring failures. Each directive should have id, severity="mandatory", <rule>, and optionally <violation-signal>.

What NOT to do

• Do not let the orchestrator self-modify its prompt — requires human oversight
• Do not duplicate content — each rule should be defined once. Use ref-directive, ref-threshold, and cross-ref attributes for references
• Do not break XML validity — always validate after editing