orchestrator-workflow 0.2.0 → 0.3.0

package/README.md

@@ -39,7 +39,8 @@ Two effects fall out of this shape:
   structured YAML evidence instead of transcripts, and durable state lives
   in run files that survive context compaction. The cheap models do the
   volume work; the strongest model is spent only on orchestration decisions
-  and the skeptical review.
+  and the skeptical review. The ceremony scales to the task: a trivial change
+  is done directly, the full flow is for non-trivial work.
 - **Quality through structure.** Writing and reviewing are separated by
   role and model, task slices are validated before any implementation
   starts, acceptance is decided on evidence (tests executed, findings

package/assets/agents-md-section.md

@@ -5,10 +5,9 @@ This repository uses an orchestrator-led agent workflow, installed and updated b
 [orchestrator-workflow](https://github.com/LanNguyenSi/agent-dx/tree/master/packages/orchestrator-workflow).
 
 The primary agent acts as the orchestrator. It owns the goal, planning, task
-validation, delegation, final acceptance, and the operator handoff.
-Implementation and technical review are delegated to narrow subagents. The full
-procedure and the subagent I/O contracts live in the `orchestrator-workflow`
-skill.
+validation, delegation, final acceptance, and the operator handoff. Non-trivial
+implementation and review are delegated to narrow subagents. The full procedure
+and the subagent I/O contracts live in the `orchestrator-workflow` skill.
 
 ### Core rules
 
@@ -16,12 +15,28 @@ skill.
   further subagents.
 - The orchestrator plans features itself. It may delegate task slicing, but it
   validates the sliced tasks before implementation starts.
-- Implementation goes to narrow implementer subagents, one task per subagent.
-- Technical review goes to a separate reviewer subagent. Review is never
-  skipped, not even for docs or batch changes.
+- Non-trivial implementation goes to narrow implementer subagents, one task
+  per subagent.
+- Non-trivial review goes to a separate reviewer subagent (see Scaling
+  delegation). Review itself is never skipped, not even for docs or batch
+  changes.
 - Final acceptance and the final answer to the operator stay with the
   orchestrator.
 
+### Scaling delegation
+
+The orchestrator matches the ceremony to the task; the full flow is a
+default, not a ritual.
+
+- A trivial change (a typo, a one-line fix, a rename) may be implemented by
+  the orchestrator directly, without slicing or an implementer subagent.
+- Slicing and implementer subagents are for non-trivial work: multiple files,
+  real logic, or anything that benefits from decomposition or a fresh context.
+- Review judgment applies to every change. For a trivial change the
+  orchestrator may review it itself; reserve the reviewer subagent for
+  changes whose risk or size warrants an independent skeptical pass. Either
+  way, review is never skipped.
+
 ### Context discipline
 
 - Prefer task-local context over repository-wide context.

package/assets/skill/SKILL.md

@@ -15,6 +15,12 @@ tasks to specialized subagents. The goal is to improve quality, reduce
 context-window pressure, and keep the operator informed through structured
 handoffs.
 
+Scale the ceremony to the task. The workflow below is the default for
+non-trivial work; a trivial change (a typo, a one-line fix) may be done
+directly by the orchestrator and reviewed by it, without slicing or spawning
+subagents. Review judgment still applies to every change; only the size of
+the apparatus changes.
+
 ## Roles
 
 - **Operator**: the human requester. Provides goal and constraints, approves or
@@ -58,6 +64,10 @@ older directories are the auditable history. Do not edit past runs.
 
 ## Workflow
 
+For a non-trivial change, run the full flow below. For a trivial change, do
+the work directly, review it, and still leave a short handoff; skip the run
+directory and the subagents.
+
 1. **Understand the goal.** Create the run directory and fill `00-goal.md`:
    operator request, goal, non-goals, constraints, assumptions, open questions.
    If the task can proceed on reasonable assumptions, proceed without blocking.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "orchestrator-workflow",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "Installer for an orchestrator-led agent workflow: .ai/ run state, an AGENTS.md policy section, and per-harness subagent definitions for Claude Code, OpenAI Codex, and opencode",
   "main": "dist/index.js",
   "type": "module",