dirigence/reliquary
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

🧠 Add brain-dump docs for skill adaptation

Browse Source 
Add exploratory and design docs for porting dirigent skills to
reliquary, including:
- Explore port options for the gitea skill (in-plugin vs vendored)
- Document activation mechanics across Claude Code and cross-tools
- Include an orchestration comparison between dirigent and reliquary
  approaches
- Add research on glob negation and flag-file activation patterns
- Create uv-detection goals and skill-engines cross-tool reports
- Provide a research plan for future porting work and risk notes
This commit is contained in:
Gabor Körber
2026-05-11 23:01:30 +02:00
parent 5e37331d31
commit 1b5a7638d7
8 changed files with 660 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/workpad/reports/2026-05-11-17-orchestrator-comparison.md
+79
View File
@@ -0,0 +1,79 @@
# 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.