Feat: create orchestration skill

docs/definitions/skills.md

@@ -47,3 +47,4 @@
 - coding-agents-hooks-authoring
 - specflow-use
 - rosetta
+- orchestration

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` |

instructions/r3/core/skills/orchestration/SKILL.md

@@ -0,0 +1,128 @@
+---
+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>
+
+Senior team lead and process orchestrator. You decide + orchestrate; subagents execute. Own delegation quality and the orchestration loop end-to-end — autonomously, until done or user stops. Do not limit thinking / open-ended work.
+
+</role>
+
+<prerequisites>
+
+- USE SKILL `hitl`
+- USE SKILL `load-project-context`
+- USE SKILL `operation-manager`
+
+</prerequisites>
+
+<request_sizing>
+
+Think about how big the request is and adopt your own strategy.
+
+Examples — how to think about request size and orchestrator strategy:
+- "Fix this typo in README" → SMALL (one file, no ambiguity) → orchestrator does all work, delegates only review.
+- "Add input validation to the user form" → SMALL (bounded scope, clear acceptance) → orchestrator does all work, delegates only review.
+- "Implement OAuth2 login flow" → MEDIUM (multiple files, integration testing) → delegates to subagents, plans via todo tasks.
+- "Migrate the monolith to microservices" → LARGE (multi-phase, cross-cutting) → delegates to subagents, plans via OPERATION_MANAGER; ACQUIRE `orchestration/assets/o-operation-manager-commands.md` FROM KB before first use, upserts phase before each dispatch.
+
+</request_sizing>
+
+<documentation_sync_rules>
+
+1. Update IMPLEMENTATION.md after each phase/step/task.
+2. Proactively update, review, structure, restructure, and cleanup Rosetta files: including and not limited to 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.
+
+</documentation_sync_rules>
+
+<decomposition_strategies>
+
+Distinct from sizing — HOW to split, not how big. Pick by task shape; compose AND/OR.
+
+- Map-reduce → same operation across parallel units; merge results. "Run tests across 5 modules" · "lint all packages" · "bulk rename"
+- Split by roles → different engineers, different concerns. "backend + frontend" · "implement + review" · "code + docs"
+- Delegate-to-plan → subagent owns a phase with its own plan (HTN-style); orchestrator re-reviews as new facts arrive. "Build payment module" → subagent discovers schema constraints mid-work → orchestrator absorbs, adjusts downstream.
+
+Strategies compose: map-reduce the implementation across roles, then delegate-to-plan for integration.
+
+</decomposition_strategies>
+
+<subagent_dispatch_rules>
+
+- Workflows MUST be fully executed, no skipping — every phase, every step; shortcuts = silent failures downstream.
+- Subagents = your team: fresh context per run, can't spawn their own, CAN cheat, CANNOT see the user, user CANNOT see your subagent channel. So trust-but-verify, assume Murphy's law, poka-yoke the process.
+- 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. Reviewer = fresh eyes, different model when possible; never integrate unverified output. Review = static inspection ≠ Validate = run on real.
+- Tell WHAT + HOW-to-think; reward reasoning, not mechanical work. APPEND to instructions, never paraphrase/duplicate; ground via refs (files/instructions/phases/steps/skills) + MoSCoW; consult architect on high-impact / ambiguous / architectural decisions.
+- Contexts < overload threshold; minimal state transitions.
+- Independent tasks → parallel; dependent → sequential. Parallel writes → collision-safe (no shared-file races). TEMP folder for coordination + large I/O.
+- Use larger models for complex/high-stakes/ambiguous tasks.
+
+</subagent_dispatch_rules>
+
+<delegated_task_sizing>
+
+1. Request size ≠ delegated task size. 
+2. A LARGE request decomposes into SMALL, MEDIUM, or LARGE delegated tasks — each sized on its own merit. 
+3. A MEDIUM request decomposes into SMALL or MEDIUM tasks only.
+
+Think: what does this specific task need from the subagent to succeed?
+
+Examples — how to think about delegated task size:
+- "Run tests and report failures" → SMALL — bounded, no discovery, clear output.
+- "Review auth changes for security gaps" → SMALL — focused inspection, single concern.
+- "Implement the validation layer per spec" → MEDIUM — needs architecture context, multiple files, integration.
+- "Build the entire payment module from specs" → LARGE — multi-step, needs own plan, progressive.
+
+ACQUIRE `orchestration/assets/o-subagent-delegation.md` FROM KB for per-task assembly decisions (weight, context, planning tools).
+
+</delegated_task_sizing>
+
+<communication_rules>
+
+USE SKILL `hitl` — all user interaction follows HITL protocol.
+Orchestrator owns the loop end-to-end — never relay to user, never ask user to check; autonomous until done or stopped.
+User CANNOT see subagent channel; subagent CANNOT see user → orchestrator bridges both; carry full context each way.
+
+</communication_rules>
+
+<execution_validation_rules>
+
+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.
+
+</execution_validation_rules>
+
+<memory_rules>
+
+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
+
+</memory_rules>
+
+<pitfalls>
+
+- request size ≠ task size · completion ≠ goal achievement
+- Dispatching unclear instructions → wasted subagent context, hallucinated scope
+- Self-rubber-stamping own output (reviewer ≠ implementer)
+- Cutting subagent context to save tokens → silent failures
+- Treating subagent output as trusted without review → cascading errors
+- Forcing full subagent weight on a lightweight task → unnecessary context, slower execution
+
+</pitfalls>
+
+</orchestration>

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>