reliquary/docs/workpad/reports/2026-05-11-17-orchestrator-comparison.md

Orchestrator skills: dirigent's orchestrator vs. reliquary's implementation-orchestration

Comparison of two skills that both claim to govern "how the agent drives multi-step work."

Source	File
dirigent (old)	../dirigent/.claude/skills/orchestrator/SKILL.md (130 LOC)
reliquary (current)	plugins/g4b_ai/skills/implementation-orchestration/SKILL.md (80 LOC)

TL;DR

They are not the same skill at different stages — they are different philosophies of orchestration:

• orchestrator (dirigent) is a plan-execution skill: there's a markdown plan, there's a tasks file, the agent walks phases, checks boxes, writes phase-summary files, delegates each task to a specialized "implementer" agent. It is prescriptive, ceremonial, and assumes the work is already decomposed.
• implementation-orchestration (reliquary) is a judgment skill: when do you delegate vs. work inline, when do you sequence vs. parallelize, how do you handle test failures and hard bugs without thrashing. It is descriptive, principle-based, and assumes the work is not yet decomposed.

The newer skill is not a refactor of the older one — it answers a strictly different question. Adopting the new skill does not retire the old one; if anything, the old one is the content you'd want when actually walking a plan, while the new one is the meta you'd want when deciding whether a plan is even the right move.

Side-by-side

Dimension	orchestrator (dirigent)	implementation-orchestration (reliquary)
Trigger	"you have a multi-phase plan in markdown — execute it"	"user said implement / build / ship / fix" — i.e. starting work, no plan required
Scope	Drive an existing plan to completion	Decide how to approach work, with or without a plan
Posture toward planning	Plan is input; if missing, write tasks.md first	Plan is optional; only worth writing for non-trivial work
Delegation model	One implementation agent per phase / task; orchestrator never implements	Mixed — inline by default, subagents when work genuinely doesn't fit
Parallelism stance	Sequential by default; parallel only for research / read-only	Sequential by default; parallel only when truly disjoint (same rule, more explicit about why)
Test failures	Re-engage agent with feedback	Delegate fix to subagent but verify the diff (calls out the "test-deletion shortcut" failure mode explicitly)
Bugs	Not covered	Two strong rules: prove-with-test before fixing; explore-before-focus
Progress tracking	Updates checkboxes in tasks.md; writes per-phase summary file	Defers to workpad skill; no checkbox protocol of its own
Composition	Standalone, with references to "implementation agents" by name (e.g. rust-task-implementer)	Explicit composition with workpad, research-tree, superpowers
Tone	Operational SOP ("Self-Verification Checklist", "Output Expectations")	Heuristics with rationale ("a wrong plan caught at planning time costs minutes; caught at code-review time costs days")
Length	130 LOC, heavily structured	80 LOC, prose-first

What each does well

orchestrator (dirigent) strengths

• Concrete checkbox/phase-summary protocol gives a clear paper trail when the work is a long plan.
• Names roles (rust-task-implementer, task-writer) — useful in a project where you've actually built those subagents.
• Self-verification checklist is genuinely good for ritualized "have I really finished this phase" moments.

implementation-orchestration (reliquary) strengths

• "Delegate the fix, but verify the diff" is the single most important orchestration rule and the old skill misses it.
• The bug-handling section ("prove before fixing, explore before focusing") is high-leverage advice that the old skill doesn't address at all.
• Composition-first design: it explicitly defers to workpad, doesn't reinvent placement rules.
• Acknowledges that orchestration overhead is itself a cost — "for changes small enough that a single agent could do the whole thing, just do it inline."

What each is missing

orchestrator is missing

• Any treatment of bugs / unknowns. It assumes you already know what to do and just need to execute.
• Any pushback on its own ceremony. It will happily mandate phase-summary files for a 3-line fix.
• A "when not to use this skill" section.
• The verify-the-diff guard against subagents writing fake-green fixes.

implementation-orchestration is missing

• A concrete protocol for the "I genuinely have a 7-phase plan and need to walk it" case. It punts to workpad for placement but doesn't say what the execution loop looks like when there are 20 checkboxes to grind through.
• Named-subagent vocabulary. The old skill at least namechecks specialized implementers; the new one says "subagent" abstractly.
• A "definition of done" per phase. The old skill's self-verification checklist is useful precisely because it forces a stop.

Recommendation

Keep implementation-orchestration as the primary entry-point skill — its heuristics generalize. But consider porting two narrow pieces from orchestrator:

1. A separate plan-walker skill (or section) covering: walking a checkbox plan, marking items done, writing per-phase summaries. This is the operational protocol the new skill deliberately omits. It would compose under implementation-orchestration ("when you have a plan, here's how to walk it") rather than replace it.
2. A per-phase done-checklist pattern, even if shorter than the old one. Right now there's no explicit "stop here and check" marker in the new skill, and the old skill's checklist serves that role usefully.

Not worth porting:

• The phase-summary-file mandate as a hard rule. Make it conditional on plan length.
• Hardcoded implementer-role names. The user's subagent roster will evolve; tie this to project-level config instead.
• The "celebrate when all phases complete" line. (You know.)

Naming note

If a plan-walker skill is added, the names start to overlap awkwardly:

• implementation-orchestration — when and how to orchestrate
• orchestrator (old) — how to walk a plan

Consider renaming the ported piece to plan-execution or phase-walker to make the split obvious. Reserve "orchestration" for the meta-level.