KO | EN

GitLite

Minimalist Open Source Repository Search Engine

gitlite — search

#dsh #ai-agents #dsh-plugin #codex #developer-tools #claude-code #windows #cli #desktop-app #typescript #rust #ai-agent

Pln-Droid-Orchestrator

★ 365 Open GitHub ↗

🤖 PLN Droid Orchestrator - An intelligent AI orchestration system for coordinating specialized droids to accomplish complex development tasks

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# PLN Droid Orchestrator

PLN Droid Orchestrator is a Droid plugin for structured planning and in-chat execution orchestration.

It provides a single primary command, `/pln`, that turns a product or engineering request into a reviewed plan package and then hands execution back to the main agent in the same chat.

## Install

### Install from GitHub

```bash
droid plugin marketplace add https://github.com/aeitroc/Pln-Droid-Orchestrator
```

Droid will print the marketplace name it registered. Then install the plugin:

```bash
droid plugin install pln-pipeline@<marketplace-name>
```

### Install from a local checkout

```bash
droid plugin marketplace add /absolute/path/to/pln-droid-orchestrator
droid plugin install pln-pipeline@<marketplace-name>
```

If you already have Droid running, reload commands after installation.

## Quick start

1. Open a repository in Droid.
2. Run `/pln <task description>`.
3. Let `/pln` generate the plan package under `docs/plans/`.
4. Choose **Execute here now (main-agent orchestration)** when prompted.
5. The main agent will continue in the current chat and orchestrate implementation with visible `Task` calls.

## What `/pln` produces

Each planning run produces:

- a reviewed plan document
- a machine-readable execution manifest
- one task capsule per task

These artifacts are saved under `docs/plans/` so execution can stay grounded in an explicit contract.

## How plan creation works

`/pln` does not jump straight to task generation. It builds the plan through an explicit chain so the final artifacts are reviewable and execution-ready.

### 1. Intent and scope framing

The command first classifies the request and locks scope:

- identifies the task type and expected pipeline depth
- derives a scope contract from the user request and referenced materials
- flags blocking ambiguities before planning continues

### 2. Codebase grounding

Before planner droids reason about the work, the main agent gathers grounded context with visible `Task` calls:

- `explore` finds relevant files, patterns, and boundaries
- `librarian` is added when external libraries or framework details matter
- `tla-precheck` is used when the plan touches a stateful workflow that needs formal verification

This keeps the plan tied to the real repository instead of generic assumptions.

### 3. Planning phases

The planning chain is:

1. `metis` — clarifies intent, surfaces ambiguities, identifies failure points, and assesses test strategy
2. optional design checkpoint — used for architecture or research-heavy requests, then reviewed before full planning continues
3. `prometheus` — writes the executable plan, task waves, file targets, `dispatchAgent` values, and verification steps
4. `momus` — checks the plan for executability, reference validity, and blocking gaps

If a phase finds unresolved blocking issues, the chain stops and asks for clarification instead of silently guessing.

### 4. Plan package output

Once the chain passes review, `/pln` writes:

- a Markdown plan for humans
- a JSON manifest for orchestration
- one capsule per task for self-contained execution context

### 5. Execution handoff

After the plan is saved, `/pln` immediately asks how to execute it.

The primary path is **Execute here now (main-agent orchestration)**, where the main agent stays in the current chat and uses visible `Task` calls to drive implementation, review, testing, security gates, and optional memory writeback.

## Execution model

The supported execution path is **main-agent orchestration**.

That means:

- execution stays in the current chat
- the main agent reads the saved manifest and task capsules
- implementation and verification happen through visible `Task` calls to the bundled droids in `droids/`
- no hidden headless executor is required for the primary workflow

## Quality controls built into the flow

The plugin is designed for complex work, so planning and execution keep explicit quality gates:

- **TDD-aware planning** — tasks can encode `TDD`, `Tests-after`, or `None`
- **Per-task review loop** — `reviewer` plus `tester`
- **Wave barriers** — `reviewer`, `tester`, and `sentinel`
- **Final gate** — validation commands, scope checks, QA execution, and optional memory writeback

## Bundled droids

This repository includes the droids used by the current PLN flow.

- **Planning and research**: `explore`, `metis`, `prometheus`, `momus`, `librarian`, `tla-precheck`
- **Implementation**: `backend`, `frontend`, `devops`, `api-designer`, `migrator`, `performance`, `debugger`, `tdd-test-writer`, `tdd-orchestrator`
- **Verification**: `reviewer`, `tester`, `sentinel`
- **Memory**: `memory`

## Repository layout

```text
.factory-plugin/plugin.json
commands/pln.md
droids/*.md
```

## When to use it

Use this plugin when the task is large enough to benefit from:

- explicit scope control
- plan artifacts you can inspect before execution
- wave-based execution and review checkpoints
- visible, reusable droid orchestration

For trivial one-file edits, the normal chat flow is often simpler.

This plugin was inspired from [oh-my-openagent](https://github.com/code-yeongyu/oh-my-openagent) , [superpowers](https://github.com/obra/superpowers) and [Claude Code compound engineering plugin](https://github.com/EveryInc/compound-engineering-plugin).

Pln-Droid-Orchestrator

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README