agent-dev Plugin

Add persistent memory to agents via /agent-dev:add-memory:

Memory systems are copied directly into the agent - no plugin dependency at runtime.

/agent-dev:add-git-sync

Installs hooks that treat the agent's own repository as durable memory:

This gives agents durable cross-session memory through their repo, complementing Trinity's GitHub Sync on the platform side.

Add task management via GitHub Issues:

/agent-dev:add-backlog

This installs the full development cycle directly into the agent. After install, the agent has:

/agent-dev:work-loop

One bounded unit of work: the agent picks the highest-priority issue, executes it, closes it, and exits. It is designed to be re-invoked - by a Trinity schedule for a steady cadence, or by a Trinity agent loopfor a bounded burst ("drain up to 20 items, stop when the backlog is empty").

/agent-dev:add-pipeline

Scaffolds an agent-owned pipeline for work that spans days or weeks (e.g. perception → synthesis → publish → measure): a projects/<slug>/ directory with pipeline.yaml and per-instance state, tick/status/recover/pause/resume skills, a heartbeat schedule that advances stages, and a ~/.trinity/ read surface so Trinity can display pipeline state without owning it.

A stage can name a local skill or delegate to another fleet agent - agent: <fleet-agent> calls that agent's playbook as one line with --run <pipeline>/<instance>, dispatched asynchronously and polled for its result; such stages skip the local-skill check.

Pipelines are owned by the agent, not by Trinity - the platform only reads the published state. This matches Trinity's agent-defined-pipelines design: no central DAG engine.

/agent-dev:add-orchestrator

Makes any agent a system-aware orchestrator of other agents. Two modes, picked by whether the fleet already exists: describe and route over an existing fleet (read-only - discover, then orchestrate; no manifest, no deploy) or provision a new system (author the intent, compose a manifest, deploy, then orchestrate). It installs these skills into the agent:

Three conventions run through the whole bundle:

Re-running the installer. /agent-dev:add-orchestrator --check is a read-only divergence report - per installed skill it says whether the bundle moved ahead (upgrade available), whether the installed copy was hand-edited (an overwrite would discard it - the diff is shown), or whether the installed copy is aheadof the bundle (a field-hardened copy the marketplace should pull from - an overwrite would be a downgrade). The same comparison runs inside every overwrite prompt when you re-run the installer, so the warning arrives at the moment of decision. It compares only this bundle's own skills and keeps no state on disk.

Gated skills on crons. /sync-fleet-to-head and /profile-fleet ask questions at their decision points; put on a schedule as-is, each run would block on a prompt nobody sees. Both declare a --autonomous run mode - the schedule message is the bare /<skill> --autonomous, and the skill takes the safe default at every gate, never a destructive path, recording anything non-trivial as a needs-attention line. This is the bundle-wide convention every gated-and-scheduled skill follows.

The orchestrator builds on Trinity's existing multi-agent primitives rather than inventing a parallel standard - see System Manifest, Fan-Out, and Rooms. Pipelines are the intra-agent sibling: /orchestrate routes pipeline-shaped work to the agent that owns the pipeline instead of re-sequencing its stages as a chain; canon is the data sibling: reads of published facts are served from the canon repo, writes are dispatched to the owning agent.

/agent-dev:add-canon

Gives any agent a shared canonical-data layer - a fleet-wide canon repo on plain git where each agent owns an agents/<name>/ folder, with conventions (CONVENTIONS.md, CODEOWNERS) instead of a new platform primitive. It installs four runtime skills into the agent:

In orchestrator fleets (a fleet/system-map.yaml is present), it can also enroll the mapped agents - all or a subset - into the same canon.

Each agent owns a folder it publishes to and reads other agents' folders at a pinned ref. The layer also carries relations- per-counterpart collaboration memory: each agent keeps one doc per agent it actually works with (working agreements, a capped log of recent events, open threads), reads it before acting on that counterpart's request and appends the outcome before closing the interaction. Each side keeps its own view; a divergence between the pair is a dropped-thread signal, and open threads older than 30 days surface as needs-review rows in the reconcile pass.

/agent-dev:add-canon-lint

The enforcement sibling - run once per fleet against the canon repo itself, not an agent. Seeds a deterministic linter (stdlib-only Python, no LLM), a severity config, and a GitHub Actions workflow that lints every push/PR. It defines the two-zone folder schema: facts.yaml holds purely lintable claims, docs/ holds prose with a linted envelope. Optionally makes the lint a required PR status check; the per-agent gate ships with the add-canon runtime skills (/canon-publish lints before pushing).

/agent-dev:add-project-management

Installs a cross-actor task model on GitHub Issues, with an open → pending-verification → done lattice so work isn't marked complete until it's been verified, and a loop-closure discipline: no loop closes by silence in either direction. Every run ends by stating what is now true, what is waiting on the operator, and what happens next; work parked on someone the system cannot dispatch to (a client, a vendor, a colleague) is labeled waiting-on:<actor>, aged on a 3/7/14-day ladder, listed under Your open loops in the digest, and handed back with a drafted follow-up - the agent drafts, the human sends. See add-project-management for the installed artifacts.

/agent-dev:agent-fleet-analysis

Scans one or more directories of agents in any paradigm - Claude Code, n8n workflow exports, framework apps (LangChain / CrewAI / AutoGen), or freeform-coded agents. It assesses quality (a fleet maturity score for Claude Code agents, a migration-readiness score for the rest), designs the right fleet architecture (hierarchy, knowledge brain, memory, canon layer), maps every improvement to an installable skill from the abilities marketplace, and generates a PDF report plus a markdown twin that agents can execute as a work order. Value-first - useful whether or not you ever deploy to Trinity.

/agent-dev:agent-fleet-migrate

Executes that work order non-destructively: sources are never mutated. Each agent is copied or scaffolded into fleet-migrated/, its logic extracted per paradigm, every fix delegated to a named marketplace skill, and every copy verified through a review gate. The run ends with a before/after maturity report plus a gated Trinity deploy offer.

For large projects that span multiple sessions:

/agent-dev:plan

Creates a persistent plan that tracks overall goals and milestones, current session focus, completed work, and next steps.