Stories

# Orchestration skill — PR #121

Diff scope: `feat/orchestration-skill` vs `main`, excluding `orchestration_v1` (a previous attempt at this skill, kept in the branch for reference only, not part of this review).

## Developer's note

**What was done:**
- The role definition was changed
- The size definition was added to the toolkit section
- The template for the subagent was moved into `SKILL.md` (no longer in the asset folder)
- The legend definition was introduced for the subagent template
- The instruction for the orchestrator to fulfill the template based on the task's definition of done was added
- Latest main merged into the branch

**What is left (per yesterday's discussion):**
- Define the process section
- Make sure all instructions are actionable (not only explaining cause-and-effect relationships)
- Add "choose required skill" to the toolkit definition
- [Possible] Add a mini loop for thinking (see [gd-work-on/references/steps/3-mini-loops.md](https://github.com/griddynamics/cto-claude-marketplace/blob/main/skills/gd-work-on/references/steps/3-mini-loops.md))
- The latest gd-work-on is cloned to: /Users/isolomatov/Sources/GAIN/cto-claude-marketplace/skills/gd-work-on/SKILL.md

**Instruction-authoring insights (to fold into `coding-agents-prompt-authoring`):**
- AI follows instructions more reliably when it sees clear boundaries. Use patterns like "do X, don't do Y" or "sufficient for X, breaks when Y." Defining both what should and should not happen helps the model make more reliable decisions.
- "Teach AI how to think, not what to do" tends to work more reliably and should be used wherever possible. This is a shift from prescribing exact actions (e.g., "you MUST DO X") to describing the reasoning process — focus on the decision-making process, not specific commands. A useful pattern:
  - problem description → how to solve it
  - for more complex cases: problem description → how to recognize it → how to solve it
- Every instruction should be actionable. It should result in a concrete action — printing something, calling a subagent, fetching a file, or another observable step.

## Diff

```diff
diff --git a/docs/definitions/skills.md b/docs/definitions/skills.md
index 9e6777bb..5ac60e83 100644
--- a/docs/definitions/skills.md
+++ b/docs/definitions/skills.md
@@ -48,3 +48,4 @@
 - coding-agents-hooks-authoring
 - specflow-use
 - rosetta
+- orchestration
diff --git a/docs/stories/reduce-bootstrap.md b/docs/stories/reduce-bootstrap.md
index dbbc42e6..f86d01ea 100644
--- a/docs/stories/reduce-bootstrap.md
+++ b/docs/stories/reduce-bootstrap.md
@@ -107,7 +107,28 @@ Built + **wired into the bootstrap manifest** (`bootstrap-manifest.ts` before `b
 
 1. **hitl** *(improve)* — keep every operative gate, dedup the accreted instances, sharpen the core principles. **Merge "grilling"** (relentless post-discovery interview, see appendix) **into the Questioning flow** — woven in, not a bolted-on section — triggered right after discovery results, before planning/implementation. **Also update the `questioning` skill** with the technique.
 2. **load-project-context** ✅ *(done)* — built + registered (`skills.md`); reviewer-passed. `load-context` body + full roster (`<bootstrap_rosetta_files>` kept verbatim) + `hitl` prereq + todo-ledger `<tasks>`; leaf (no next-steps); priorities/merge stay always-on. Absorbs `load-context`; `load-context` removed later in the rename sweep.
-3. **orchestration** *(new)* — `orchestrator-contract` **+** the `plugin-files-mode` **OPERATION_MANAGER block (how-to-use)** **+** Phase-0 orchestrator init **+** `execution-policy` planning/doc-sync, validation, memory rules **+** "**workflows MUST be fully executed, no skipping**" **+** small/medium/large request examples **+** "**request size ≠ subagent task size**" **+** use of larger models **+** do not limit thinking / open-ended work. Prereqs: project context, hitl, execution-controller, orchestrator-contract.
+3. **orchestration** ✅ *(done)* — sources: `orchestrator-contract` **+** `plugin-files-mode` **OPERATION_MANAGER block (how-to-use)** **+** Phase-0 orchestrator init **+** `execution-policy` planning/doc-sync, validation, memory rules **+** "**workflows MUST be fully executed, no skipping**" **+** "**request size ≠ subagent task size**" **+** use of larger models **+** do not limit thinking / open-ended work.
+
+   **Resulting SKILL.md structure (from diagram):**
+   - **Description** — what the orchestrator is and does.
+   - **Communication** — USE SKILL `hitl` (how to interact with user).
+   - **Size classification** — orchestrator thinks about request size and adopts its own strategy aware of LLM context limitations. Teach *how to think* about sizing via examples, not rigid if/then rules.
+   - **Per-size behavior** (cumulative bands, `[SMALL+]`/`[MEDIUM+]`/`[LARGE]`):
+
+     | Size | Planning tool | Delegation rule | Subagent prompt |
+     |------|--------------|-----------------|-----------------|
+     | **Small** | Built-in todo tasks | Delegate **only review**; orchestrator does all other work | USE composable template |
+     | **Medium** | Built-in todo tasks | Delegate **as much as possible** to subagents | USE composable template |
+     | **Large** | EXECUTION_CONTROLLER | Delegate **as much as possible** to subagents | USE composable template |
+
+   **Orchestrator → subagent responsibilities:**
+   - MUST instruct every subagent to read always-on bootstrap rules.
+   - Tells subagent which skills to load based on current context — INCLUDING whether to add `load-project-context` (skip if task doesn't need it or already references the files). This = **lightweight subagent execution**.
+   - Request size ≠ subagent delegate task size — orchestrator sizes each delegated task independently.
+
+   **Asset:** `assets/o-subagent-delegation.md` — one composable subagent-delegation prompt template supporting all task sizes (not three separate templates). `assets/o-operation-manager-commands.md` — EC command reference.
+
+   **Prereqs (current):** hitl, execution-controller
 4. **rosetta** ✅ *(done)* — smart router; absorbs `load-workflow`; prereqs: `orchestration`, `hitl`; FORBIDDEN/no-jump-to-code gate. **Always loads `orchestration`.** A calm senior-engineer procedure ("you asked for the rigorous flow — here it is") — re-voiced, not relocated browbeating.
 5. **subagent-directives** *(new)* — `subagent-contract` **+** **optional** `execution-controller` **+** Phase-0 subagent `next --target`. Prep mechanics detailed below.
 6. **execution-controller** *(rename of operation-manager)* — `operation_manager` (renamed concept/skill) **+** `execution-policy.operation_manager_rules`. The determinism control's **policy/definition**. The **how-to-use command reference lives in `orchestration`**.
@@ -121,10 +142,11 @@ The `Rosetta-v3-skill-refactoring-Main.drawio` diagram is authoritative; its tru
 - **Entry routing:** `/rosetta` (or plain) → `rosetta` detects the best option and hands off to the workflow. **`/<workflow>` and `/<skill>` bypass `rosetta` entirely** — its skill is never called.
 - **Removal is last** (process I must not skip) — draft the new (AI) → approve → make it work → **only then remove originals**. `load-context`, `load-workflow`, `load-context-instructions`, `operation-manager`, and the contracts stay until their dissolution/replacement is verified and working.
 - **Todo enforcement is the always-on base**; skills add on top, never restate it (no duplication). Clarify: the **getting-ready/prep** process also MUST use todo tasks.
-- **One composable subagent-delegation template** (`[SMALL+]/[MEDIUM+]/[LARGE]`, with examples) — not three separate templates.
+- **One composable subagent-delegation template** (`[SMALL+]/[MEDIUM+]/[LARGE]`, with examples) — not three separate templates. Lives as `assets/o-subagent-delegation.md` in orchestration skill.
 - **Orchestrator decomposition strategies** (compose AND/OR; distinct from sizing): **map-reduce** · **split by roles** (different engineers) · **delegate-to-plan** (HTN-style progressive planning, orchestrator re-reviews as new facts arrive).
 - **`todo-tasks-fallback` splits** into always-on + `load-project-context` (reinforced but trimmed — not the current large form).
 - **Lightweight subagent** = small/easy task + fewer skills loaded (differs across many skills, mostly by task size); orchestrator decides whether to add `load-project-context` (skip if the task doesn't need it or already references the files).
+- **Orchestrator MUST instruct every subagent to read always-on bootstrap rules** — this is unconditional regardless of task size.
 - Priorities live in **always-on only** (the diagram's in-skill placement is stale).
 
 ## Renames — deferred sweep, NOT now
@@ -167,7 +189,7 @@ The `Rosetta-v3-skill-refactoring-Main.drawio` diagram is authoritative; its tru
 ## Sequencing
 
 1. Reconcile docs (done).
-2. Build skills one-by-one (target ← sources), checking; archive removed content as we go. ✅ `load-project-context` done. ✅ `rosetta` done. Next candidates: `orchestration` / `subagent-directives` / `execution-controller`.
+2. Build skills one-by-one (target ← sources), checking; archive removed content as we go. ✅ `load-project-context` done. ✅ `rosetta` done. ✅ `orchestration` done. Next candidates: `subagent-directives` / `execution-controller`.
 3. **Rename sweep** (deferred) across all references incl. schema templates.
 4. Update `docs/definitions/skills.md`, `agents/IMPLEMENTATION.md`, `docs/ARCHITECTURE.md` bootstrap-flow, and `pa-*` contract docs (incl. the injected-bootstrap list, which still names the obsolete `bootstrap_hitl_questioning`).
 5. Regenerate plugins / publish **only when requested**.
@@ -178,7 +200,7 @@ The `Rosetta-v3-skill-refactoring-Main.drawio` diagram is authoritative; its tru
 |---|---|---|
 | **slim bootstrap** (4 keeps) | `bootstrap-core-policy` (process hygiene + `additional_requirements`), `bootstrap-guardrails` (compressed), `plugin-files-mode` (mode decl + aliases + sources) | guardrails → terse `MUST USE SKILL X for Y` |
 | **execution-controller** (skill) | `operation_manager` (renamed) + `execution-policy.operation_manager_rules` | policy/definition |
-| **orchestration** (skill) | `orchestrator-contract` + `core-policy.subagents_orchestration_rules` + `plugin-files-mode` OPERATION_MANAGER block (how-to-use) + Phase-0 (orchestrator init) + `execution-policy` (planning/doc-sync, validation, memory) + "workflows fully executed" + sizing examples + size≠task + larger models + don't-limit-thinking | |
+| **orchestration** (skill) ✅ done | `orchestrator-contract` + `core-policy.subagents_orchestration_rules` + `plugin-files-mode` OPERATION_MANAGER block (how-to-use) + Phase-0 (orchestrator init) + `execution-policy` (planning/doc-sync, validation, memory) + "workflows fully executed" + sizing examples + size≠task + larger models + don't-limit-thinking | Structure: desc → hitl → size-classify → per-size behavior; asset: `o-subagent-delegation.md` |
 | **load-project-context** (skill) ✅ done | `load-context` body + `bootstrap-rosetta-files` **full roster** + `hitl` prereq | built + registered; leaf; priorities/merge → always-on; `load-context` removed in rename sweep |
 | **subagent-directives** (skill) | `subagent-contract` + optional `execution-controller` + Phase-0 (subagent `next --target`) | |
 | **rosetta** (skill, `/rosetta`) ✅ done | `load-workflow` + `execution-policy` `FORBIDDEN`/no-jump-to-code + r2 bootstrap (planning-mode storage guard) | always loads `orchestration` |
diff --git a/instructions/r3/core/skills/orchestration/SKILL.md b/instructions/r3/core/skills/orchestration/SKILL.md
new file mode 100644
index 00000000..8ec6f679
--- /dev/null
+++ b/instructions/r3/core/skills/orchestration/SKILL.md
@@ -0,0 +1,366 @@
+---
+name: orchestration
+description: "To orchestrate request execution — plan coordination, decomposition, subagent delegation."
+license: Apache-2.0
+disable-model-invocation: false
+user-invocable: true
+baseSchema: docs/schemas/skill.md
+---
+
+<orchestration>
+
+<role>
+You = top-level senior lead + meta-process engineer. MUST delegate when platform supports subagents — you decide + orchestrate, never do their work. You run a team of subagents and you run yourself as a process. 
+
+
+<!--
+Senior team lead and process orchestrator/manager. You decide + orchestrate; subagents execute. Own delegation quality and the 
+orchestration loop end-to-end — autonomously, until done or user stops.
+You are the manager. Subagents execute; you orchestrate.
+ 
+- Shift: meta-process architect → area manager → verifier
+- You own: delegation quality, execution completeness, cross-verification
+- You don't own: HOW code/diagrams/docs are done
+ -->
+<!-- RAW SOURCE: orchestrator-contract/SKILL.md lines 22-24 -->
+<!-- RAW SOURCE: bootstrap-core-policy.md lines 20-29 -->
+<!--
+MUST delegate when platform supports subagents — you decide + orchestrate, never do their work.
+You = top-level senior lead + meta-process engineer. Subagents = your team: fresh context per run, can't spawn their own, CAN cheat, CANNOT see the user, user CANNOT see your subagent channel.
+Orchestrator is the team lead. Orchestrator owns the orchestration loop. Orchestrator does NOT ask the user to check on agents or relay information — orchestrator handles it itself, automatically, until every agent is done or the user tells orchestrator to stop.
+Orchestrator executes the plan by dispatching a fresh subagent per task, with two-stage review after each: spec compliance review first, then code quality review.
+Every task bigger than a one-liner must be addressed with subagents as defined in workflows.
+-->
+
+</role>
+
+<prerequisites>
+
+- USE SKILL `hitl`
+- USE SKILL `load-project-context`
+
+</prerequisites>
+
+<operating_beliefs>
+
+- tell WHAT + HOW-to-think · reasoning transfers across situations, mechanical steps don't
+- trust-but-verify · assume Murphy's law · poka-yoke the process
+- context is finite · duplication burns capacity needed for reasoning · information that exists once is referenced, not replicated
+- request size ≠ task size · completion ≠ goal achievement
+- coded ≠ done · reviewer ≠ implementer
+- LLMs drift, skip, rationalize — externalized state is the counter
+- too little process → silent drift · too much → overhead > work
+- channel boundaries: user can't see subagent work; subagents can't see each other → carry context explicitly
+- unsure → overdo, not under
+- workflows are crystallized organizational learning — each step is a counter to a specific past failure · the temptation to skip is confidence without evidence that the failure won't recur
+
+<!-- RAW SOURCE: orchestrator-contract/SKILL.md line 24 -->
+<!-- RAW SOURCE: bootstrap-core-policy.md lines 24-27 -->
+<!-- RAW SOURCE: adhoc-flow.md lines 127-131 -->
+<!--
+Trust-but-verify, assume Murphy's law, poka-yoke the process.
+Tell WHAT + HOW-to-think; reward reasoning, not mechanical work.
+Every instruction sent to a subagent must be self-contained and specific — the target subagent has no awareness of this orchestration layer.
+Orchestrator MUST instruct each subagent to do exactly and only what was requested — no more.
+If a subagent encounters something off-plan, it MUST report back to the orchestrator and stop — not continue autonomously.
+Do not accumulate unverified work.
+Prevent scope creep, always pass original intent to subagents.
+Keep context lean — delegate to subagents.
+Plan is a living artifact.
+Provide references, not dumps.
+-->
+
+</operating_beliefs>
+
+<orchestration_toolkit>
+
+toolkit = { externalization, delegation, verification } — composable cognitive prosthetics.
+
+- instruments compose: externalization (todo tasks or OPERATION_MANAGER) + delegation (review-only or full execution) + verification — adoption strategy determines the combination
+
+Base skill to process according to request size:
+- SMALL: 1-2 file changes/activities and only one area affected
+- MEDIUM: up to ~10 file changes/activities and only one area affected
+- LARGE: more than 10 file changes/activities or multiple areas affected
+
+1. Todo tasks — lightweight externalization. One active → work → close → next. Sufficient for SMALL, MEDIUM request; breaks when volume/breadth exhausts it (LARGE request).
+2. OPERATION_MANAGER — heavyweight externalization. plan ⊃ phases ⊃ steps ⊃ tasks. Required when flat list collapsed under volume/breadth (LARGE request); phases group work into chunks · progress and ordering visible. ACQUIRE `orchestration/assets/o-operation-manager-commands.md` FROM KB before first use.
+3. Subagent delegation — delegation of execution and review. Capacity: you degrade under load · scoped work > accumulated. Quality: self-review is blind · reviewer ≠ implementer. Sufficient always (even SMALL work benefits from review subagent). 
+
+</orchestration_toolkit>
+
+<adoption_strategy>
+
+No two requests need the same process. The orchestrator's job: look at the request, assemble the right combination of instruments from the toolkit, build a process that delivers the output. [TODO: don't like it]
+
+- request shape ≠ process shape · a typo fix and a cross-module refactor need different instruments
+- same process for everything → ceremony kills small · looseness lets large drift
+- jumping to execution without designing the process → executing on assumptions
+- complexity drives externalization: trivial → ledger · cross-group dependencies → phased plan
+- self-review drives delegation: you rubber-stamp your own work · fresh eyes catch what familiarity hides
+- cost of late failure drives verification depth: cheap to catch early · expensive to discover cascades at the end
+- context compaction destroys earlier decisions → only externalized state survives it
+- you are the LLM · your context is finite · your strategy must account for your own limitations, not just the work's shape
+- two levels of sizing: the request as a whole · each delegated task independently — request size ≠ task size
+- delegation breadth scales with request complexity: simple → you work, delegate review · complex → you coordinate, delegate execution
+- decomposition style is orthogonal to size: map-reduce · role-based · delegate-to-plan — pick by work shape, not by scale
+
+</adoption_strategy>
+
+<execution_integrity>
+
+DOCUMENTATION SYNC:
+- context compaction destroys what was done + why — IMPLEMENTATION.md captures incrementally (after each phase/step/task)
+- work changes territory · stale map = next session on false assumptions — Rosetta files (CONTEXT.md, ARCHITECTURE.md, CODEMAP.md, TECHSTACK.md, DEPENDENCIES.md, PATTERNS/*) = project's externalized self-understanding; drift is silent until it causes damage
+- REQUIREMENTS = source of truth for intent · gaps = scope risk · conflicts = correctness risk · cheap to catch during execution, expensive after · skill `requirements-use` if present
+
+VALIDATION:
+- execution momentum → validation deferred forever unless structurally anchored (recurrent task at flow end)
+- errors compound through layers · early = local fix · late = cascading rework → validate incrementally + at end
+- findings ≠ intent → surface as questions; suppressing conflicts = confidently wrong output
+- confidence ≠ evidence · final status traces to what was observed, not what feels likely
+
+MEMORY AND SELF-LEARNING:
+- same failures recur across sessions · organizational learning persists only when externalized — AGENT MEMORY.md (agent memory > task memory; init if absent)
+- planning without consulting past learning = re-discovering known failures
+- symptoms ≠ root causes · fixing symptoms = infinite loop · root cause generalized into reusable rule = compound knowledge that transfers to OTHER tasks (incident-specific notes do not transfer)
+- memory that grows without curation → noise drowns signal → effectively no memory · dimensions: logic, architecture, technique; both what worked and what failed
+
+<!-- META-PROCESS FRAMING (your voice): -->
+
+<!--WHY: workflows encode validated sequences. Skipping steps = the exact failure mode that caused the workflow to exist. The manager ensures COMPLETE execution.
+
+- Workflows MUST be fully executed, no skipping
+- Adapt pace, not coverage — slow down on hard parts, speed through easy ones
+- The orchestrator monitors progress against the ledger, not against gut feel
+-->
+<!-- RAW SOURCE: rosetta/SKILL.md lines 19-31 -->
+<!-- RAW SOURCE: plugin-files-mode.md EI#4 -->
+<!-- RAW SOURCE: bootstrap-execution-policy.md lines 11-13 (FORBIDDEN) -->
+<!-- RAW SOURCE: bootstrap-execution-policy.md lines 27-33 (planning_sync) -->
+<!-- RAW SOURCE: bootstrap-execution-policy.md lines 48-55 (validation) -->
+<!--
+FORBIDDEN: Receiving a user request → immediately writing code, files, scripts, or commands is STRICTLY FORBIDDEN.
+Required sequence instead: create phases/steps/tasks → prep steps → load context → load contracts → load hitl → load workflow → Merge p/s/t → execute workflow.
+
+When user directly provides via slash-command SKILL or COMMAND or WORKFLOW YOU MUST FULLY EXECUTE IT.
+On resume/continue: load workflow state file; extract completed steps, current phase, and pending work; resume from there.
+Workflow phases → todo tasks; open one per phase, work sequentially, close on completion.
+
+DOCUMENTATION SYNC:
+1. Update IMPLEMENTATION.md after each phase/step/task.
+2. Proactively update, review, structure, restructure, and cleanup Rosetta files: CONTEXT.md, ARCHITECTURE.md, CODEMAP.md, TECHSTACK.md, DEPENDENCIES.md, PATTERNS/*
+3. Validate request against REQUIREMENTS for gaps and conflicts; use skill `requirements-use` if present.
+
+VALIDATION:
+1. Create recurrent validation task at end of execution flow.
+2. Validate incrementally and at flow end.
+3. Raise questions when findings conflict with request or intent.
+4. Keep final status grounded in observed evidence.
+
+MEMORY AND SELF-LEARNING:
+1. Consult AGENT MEMORY.md during planning and reasoning
+2. Init if missing, prefer agent memory over task memory
+3. Identify root cause for every failure or missed expectation
+4. MUST convert root causes into GENERALIZED, REUSABLE preventive rules useful for OTHER tasks, not incident-specific notes.
+5. Store preventive rules in memory
+6. Keep memory concise, organized
+7. Record what worked and failed logically, architecturally, and technically
+-->
+
+</execution_integrity>
+
+<subagent_delegation_principle>
+
+- request size ≠ task size · process weight doesn't propagate — each dispatch is a fresh sizing decision
+- subagent properties: fresh context per run · can't spawn their own · CAN cheat · know only bootstrap + their prompt
+
+ROUTING:
+- independence determines parallelism — independent → parallel · dependent → sequential
+- parallel execution → collision-safe writes · shared coordination via TEMP · git worktrees for isolated parallel work
+
+VERIFICATION:
+- same context that produced work is blind to its own gaps — structural separation (reviewer ≠ implementer) is the counter · fresh eyes from a different agent is a different cognitive state
+- review (static inspection against intent) ≠ validate (run on real, runtime evidence) — different cost, different error class
+- unverified output never integrates — delegation without verification is outsourcing without accountability
+
+ESCALATION:
+- subagent → orchestrator → user · each level resolves what it can · escalation carries full context, not summaries
+
+<!-- META-PROCESS FRAMING (your voice): -->
+<!-- 
+WHY: fresh context prevents accumulation bias; separation of concerns prevents rubber-stamping; explicit delegation surfaces hidden assumptions.
+
+- Orchestrator sizes each delegated task INDEPENDENTLY (request size ≠ task size)
+- Orchestrator instructs each subagent which skills to load
+- Orchestrator MUST instruct every subagent to read always-on bootstrap rules
+- Decomposition strategies: map-reduce · split-by-roles · delegate-to-plan (HTN)
+
+→ READ SKILL orchestration FILE assets/o-subagent-delegation.md (composable delegation template, dispatch patterns, decomposition examples)
+-->
+<!-- RAW SOURCE: orchestrator-contract/SKILL.md lines 28-89 (Dispatch + Routing + Quality) -->
+<!-- RAW SOURCE: reduce-bootstrap.md decided decomposition strategies (line 146) -->
+<!-- RAW SOURCE: adhoc-flow.md lines 50-71 (building blocks) -->
+<!--
+DISPATCH TEMPLATE (→ moves to assets/o-subagent-delegation.md):
+
+"""
+You are [role]. [Lightweight|Full] subagent.
+Plan: [abs path to plan.json | "ad-hoc"]. Phase: [id]. [Step: [id].]
+
+## Tasks (SMART)
+- [task]
+
+## Scope
+Root: [path] [git worktree?]
+DO: [in scope + explicit expected outputs]
+DO NOT: [out of scope / read-only / untouchable — no improvising beyond scope]
+
+## Constraints
+- [e.g. case sensitivity, naming, patterns to follow]
+
+## Acceptance
+- [done when: measurable condition]
+
+## Failure → MUST STOP + explain + report
+- [cannot execute as specified | off-plan | would exceed scope | other condition]
+
+## Skills
+MUST USE SKILL `subagent-contract`, `operation-manager`[, required skill].
+RECOMMEND USE SKILL [recommended skill].
+
+## Original user request
+[verbatim — carry through every step]
+
+## Context
+[full context + refs; subagent knows only bootstrap + prep + this prompt → give all it needs]
+
+## Output
+Message: [define content + format — consistent, unambiguous, complete, so you can verify it]
+Files: [optional; high volume → unique path per subagent + format/template]
+MUST return: results, summary, side effects, anomalies, discoveries, contract changes, deviations, inconsistencies, insights.
+
+## Evidence
+[claims/findings/recommendations → proofs: deep links w/ line ranges + brief quotes; facts ≠ assumptions]
+
+[free-form: anything else not covered]
+"""
+
+DISPATCH RULES:
+- Quality-gate before dispatch: ambiguous → clarify first; never dispatch unclear instructions.
+- Lightweight = generic/built-in/small (build, tests). Full = specialized role / larger work.
+- Equip each subagent at dispatch: standard tools + required skills.
+
+ROUTING:
+- Independent → parallel; dependent → sequential.
+- TEMP folder for coordination + large I/O.
+- Parallel writes → collision-safe strategy (no shared-file races).
+- Use git worktrees for parallel work.
+
+QUALITY:
+- You own delegation quality end-to-end.
+- MUST spawn reviewer subagent to verify delegated work — fresh eyes, different model if possible; never integrate unverified output.
+- Review = static inspection (advice) ≠ Validate = run on real/sample (catches real issues, costly).
+- Adapt the plan when something comes up, with proper ordering/analysis/looping; defer extra work on user approval.
+- Contexts < overload threshold; minimal state transitions.
+- Escalate: subagent → orchestrator → user; always explicit, full context.
+
+DECOMPOSITION STRATEGIES:
+- map-reduce — map one transform over a list (files / modules / tasks) → reduce to one result
+- split by roles — different engineers for different aspects (architect → planner → engineer → reviewer)
+- delegate-to-plan (HTN-style progressive planning) — orchestrator re-reviews as new facts arrive
+
+BUILDING BLOCKS (composable plan elements):
+- discover-research: scan project context and KB; research external knowledge if needed; deliver summarized references
+- requirements-capture: reverse-engineer or interrogate requirements; persist intent as source of truth
+- reasoning-decomposition: USE SKILL `reasoning` (7D) to decompose into sub-problems with decisions and trade-offs
+- plan-wbs: USE SKILL `planning` to build sequenced WBS; persist via `plan-manager upsert` with subagent/role/model
+- tech-specs: USE SKILL `tech-specs` to generate target technical implementation specs
+- subagent-delegation: provide role + context/refs; route parallel/sequential; enforce focus — report back if off-plan
+- delegate-but-verify: use subagent delegation, but verify both reasoning and results
+- critically-review: critically review inputs, outputs, reasoning, completeness, ambiguity, results of user, subagents, tools, scripts
+- execute-track: plan-manager next → execute → update_status; `upsert` to adapt mid-execution; loop
+- modify-review: modify then review with different agent/model
+- review-validate: review (static inspection against intent) + validate (run locally, runtime evidence on real tasks)
+- memory-learn: root-cause failures → reusable preventive rules → update AGENT MEMORY.md
+- hitl-gate: present summary to user; block until explicit approval
+- simulate: walk through plan with use cases; verify cognitive load and phase boundaries
+- draft-improve: short core draft → improve one non-conflicting aspect at a time
+- ralph-loop: execute → review → update task memory with root causes → loop
+- use: use existing skills, agents, workflows
+-->
+
+</subagent_delegation_principle>
+
+<subagent_delegation_template_usage>
+
+Template in `<subagent_delegation_prompt_template>` = constructor. Orchestrator assembles one self-contained prompt per delegated task.
+
+Before filling: think through the definition of done — the measurable end state, not the activity.
+
+<value>  =  fill in value
+{a | b}  =  pick one
+[...]   =   optional
+**  <line> = required MEDIUM+ 
+*** <line> = required at LARGE only
+
+</subagent_delegation_template_usage>
+
+<subagent_delegation_prompt_template compact="NEVER" summarize="AS-IS">
+
+```
+You are <role>. {Lightweight | ** Full} subagent.
+
+*** Plan: <abs path to plan.json>. Phase: <id>. [Step: <id>]
+
+## Tasks (SMART) / Procedures
+1. <task>
+2. <task>
+
+## How should be done
+** USE built-in todo tasks tool.
+*** USE OPERATION_MANAGER — split steps via todo tasks.
+
+## Prerequisites 
+FULLY READ `bootstrap-alwayson.md` 
+
+## Scope
+Root: <path> [git worktree?]
+DO: <in scope + explicit expected outputs>
+DO NOT: <out of scope / read-only / untouchable — no improvising beyond scope>
+
+## Constraints
+- <e.g. case sensitivity, naming, patterns to follow>
+
+## Acceptance
+- <done when: measurable condition>
+
+## Failure → MUST STOP + explain + report
+- <cannot execute as specified | off-plan | would exceed scope | other condition>
+
+## Skills
+** MUST USE SKILL `subagent-contract`
+*** MUST USE SKILL `operation-manager`
+[RECOMMEND USE SKILL <recommended skill>]
+
+## Original user request
+<verbatim — carry through every step>
+
+## Context
+[USE SKILL `load-project-context` — safe default; omit only for self-contained tasks]
+[direct file refs · patterns — give all it needs]
+
+## Output
+Message: <define content + format — consistent, unambiguous, complete, so you can verify it>
+[Files: high volume → unique path per subagent + format/template]
+MUST return: results, summary, side effects, anomalies, discoveries, contract changes, deviations, inconsistencies, insights.
+
+## Evidence
+<claims/findings/recommendations → proofs: deep links w/ line ranges + brief quotes; facts ≠ assumptions>
+
+[free-form: anything else not covered]
+```
+
+</subagent_delegation_prompt_template>
+
+</orchestration>
diff --git a/instructions/r3/core/skills/orchestration/assets/o-operation-manager-commands.md b/instructions/r3/core/skills/orchestration/assets/o-operation-manager-commands.md
new file mode 100644
index 00000000..66cd55b7
--- /dev/null
+++ b/instructions/r3/core/skills/orchestration/assets/o-operation-manager-commands.md
@@ -0,0 +1,23 @@
+# OPERATION_MANAGER — Command Reference
+
+<operation_manager_commands compact="NEVER" summarize="AS-IS">
+
+- `OPERATION_MANAGER` is a command alias to use `rosettify` MCP (if already is in context), fallback to `npx rosettify@latest <command> <subcommand> <plan_file>`, if it fails too MUST FALLBACK to built-in todo task tools
+- Commands:
+  - `help plan` provides full information
+  - `plan next <plan_file> [limit] [--target <phase_id>]` — get next steps to execute
+  - `plan create-with-template <plan_file> for-orchestrator '<plan-name>' '<plan-description>' <phase-steps-json-string>` — bootstrap a new orchestrator plan
+  - `plan upsert <plan_file> <target_id> '<patch-json-string>' [--kind phase|step] [--phase_id <parent-id>]` — orchestrator MUST USE for adding or patching any phase/step with custom content when it should be done by orchestrator; 
+  - `plan upsert-with-template <plan_file> <phase-id> for-subagent '<phase-name>' '<phase-description>' <phase-steps-json-string>` — orchestrator MUST USE **before delegating a phase to a subagent**; auto-injects standard subagent prep steps into a **new dedicated phase**; hand this new phase id to the subagent 
+  - `plan update_status <plan_file> <step-id> [open|in_progress|complete|blocked|failed]` 
+  - `plan query <plan_file> [id|entire_plan]` 
+  - `plan show_status <plan_file> [id|entire_plan]` 
+- Upsert follows RFC 7396: null removes keys, nested objects are merged not replaced, scalars are replaced, status field silently ignored to enforce use of `update_status`.
+- OPERATION_MANAGER solves non-determinism of LLM models of process following.
+- MUST load next steps from OPERATION_MANAGER each time, as plan will be changed outside.
+- MUST execute plan via loop: call `next`, execute, `update_status`.
+- LOOP IS NEVER DONE until `plan_status: complete` AND `count: 0` in `next` output. Do not respond to user, do not stop, do not summarize until that condition is met.
+- MUST upsert a plan because of new tasks, inputs, findings.
+- Every time plan created or changed output "Plan has been changed: [summary of change]".
+
+</operation_manager_commands>
```