agentic-orchestrator

Solid

Run the implementation loop for a framed and decided feature: pick the next unit, retrieve just enough context, write an inline spec, dispatch one subagent, gate the result, route on which gate stage failed, and record it. Use after agentic-feature-framing and agentic-design-session have produced a charter and a decision log, when the user says "start building", "implement the feature", "run the next unit", or resumes work on an existing .claude/features/<slug>/. This is phase 2 of the agentic development pipeline. It never edits code itself.

AI & Automation 314 stars 20 forks Updated yesterday Apache-2.0

Install

View on GitHub

Quality Score: 86/100

Stars 20%
83
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Orchestrator You plan, specify, dispatch, route and record. You are a long-lived session and your context is the scarcest thing in the system — everything below exists to spend it on judgement and nothing else. ## The rule that will be hardest to keep **You never edit code.** Not a one-line fix. Not "while I'm here". Not when the gate failure is obviously a missing import and dispatching feels absurd. It will feel absurd often. Do it anyway. The moment you patch, you are the executor: frontier rates for mechanical work, and the diff lands in the one context this whole arrangement is protecting. The re-spec loop exists precisely because the obvious fix is cheap to specify and expensive to make yourself. You may write: `.claude/features/<slug>/units/*.json`, `records.jsonl`, appended entries in `decisions.md`, and the `verified by` column in `charter.md`. You may run git. Nothing else. **You do not read code to judge a result either.** The gate does that. If you find yourself opening a source file to see whether a unit worked, you are re-centralising the expensive work. ## Setup, once per feature ``` .claude/features/<slug>/ charter.md decisions.md units/ records.jsonl metrics.jsonl ``` Read the charter and the decision log now, in full. Read them once. Everything after this is against that, plus the compact records. **Check the charter's `Size and sessions` before anything else.** The design session already decided whether this feature is one orch...

Details

Author
PackmindHub
Repository
PackmindHub/packmind
Created
1 years ago
Last Updated
yesterday
Language
TypeScript
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

agentic-feature-framing

Frame a piece of work before any design or implementation: what is in scope, what is explicitly not, and the acceptance criteria that will judge it. Use at the very start of a new feature, when the user says "I want to build X", "we need a way to Y", or hands over a ticket or a rough idea. Produces .claude/features/<slug>/charter.md and nothing else — no code, no design decisions, no file edits. This is phase 1a of the agentic development pipeline; agentic-design-session is 1b and agentic-orchestrator is phase 2.

314 Updated yesterday
PackmindHub
AI & Automation Solid

agentic-design-session

Turn a framed feature into an append-only decision log: every design fork made explicit, with the reasoning and the alternatives that were rejected and why. Use after agentic-feature-framing has produced a charter, and before any implementation starts. Also use when an implementation reveals an earlier decision was wrong and needs superseding. Produces .claude/features/<slug>/decisions.md, and closes by sizing the feature into the Size and sessions section of the charter — the call on whether the orchestrator runs it in one pass or several. No code, no other file edits. This is phase 1b of the agentic development pipeline.

314 Updated yesterday
PackmindHub
AI & Automation Listed

orch-development

Use when implementing features, bugfixes, or executing a development plan through an orchestrated multi-agent setup — the session model acts as PM + lead architect + QA gate while developer subagents (any models/CLIs you have) do the implementation. Triggers on "orch-development", "orchestrated development", "multi-agent dev", "let the orchestrator drive", or any dev work you want run as orchestrate-and-verify rather than write-it-yourself.

2 Updated 3 weeks ago
Continero