agents_pipeline
AGENTS.md1 starsChanged 4 months agoMITView on GitHub
This catalog lists all agents and their roles. Codex is the Tier 1, first-class runtime; normal child-model selection comes from the workspace profile while the provider remains inherited from the parent Codex session. Generated role profiles may override only the model, never the provider. Claude Code .claude/agents/*.md and VS Code Copilot .agent.md files are Tier 2 best-effort exports without a feature-parity guarantee. OpenCode support ended at the frozen OpenCode-first release, v0.26.1. Runtime-neutral source lives in agents/, protocols/, skills/, and tools/.…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,542 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository18 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- artgen-scaffoldSkill
- decideSkill
- devtools-ux-auditSkill
- frontend-aesthetic-directorSkill
- run-adaptiveSkill
- run-analysisSkill
- run-ciSkill
- run-committeeSkill
- run-flowSkill
- run-generalSkill
- run-modernizeSkill
- run-pipelineSkill
- run-simpleSkill
- run-specSkill
- run-uxSkill
- ui-communication-designerSkill
- ui-ux-workflowSkill
The file
We split this AGENTS.md into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use the smallest implementation and verification sufficient for the stated requirement.
- Very specific: line 12
Before capability recovery or a later recovery-stage dispatch, also read protocols/CAPABILITY_RECOVERY.md.
- Distinctive: line 13
Keep validation bounded to the requested delivery.
- Very specific: line 14
Before any authorized commit or push, including orchestrator helper actions, follow protocols/COMMIT_GUARD.md.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Catalog
This catalog lists all agents and their roles.
Codex is the Tier 1, first-class runtime; normal child-model selection comes from the workspace profile while the provider remains inherited from the parent Codex session. Generated role profiles may override only the model, never the provider.
Claude Code .claude/agents/*.md and VS Code Copilot .agent.md files are Tier 2 best-effort exports without a feature-parity guarantee. OpenCode support ended at the frozen OpenCode-first release, v0.26.1.
Runtime-neutral source lives in agents/, protocols/, skills/, and tools/. Generated runtime outputs must not be hand-edited. Mode aliases and their orchestrator targets are defined in modes.json. $run-adaptive is intentionally a skill-only Simple/Flow/Pipeline router with route-independent execution presets, not an agent role or manifest-backed compatibility mode.
Before managed role or Web session agent Job dispatch, read protocols/REASONING_POLICY.md and follow its profile/tier, shared-resolver, saved-configuration, dispatch-surface evidence, and result-label rules. Exported roles are leaf workers and must not dispatch another agent. Never claim native managed-role identity, workspace routing, a verified model, or effective effort without the evidence that protocol requires.
Configured workspace profiles require health = ok, profile_eligibility = eligible, and catalog_state = current before new dispatch or resume. A pinned or retired catalog requires explicit workspace set --model-set openai or clear; it does not silently inherit the parent model.
For an explicit request to dispatch a registered managed role outside a $run-* workflow, read the Ad-hoc managed-role dispatch section of protocols/REASONING_POLICY.md before spawning. Keep this path adaptive, pass tier unknown when the profile/runtime cannot prove it, and create no workflow artifacts; unverifiable or unhealthy profile status and resolver or selector conflicts stop dispatch.
Use the smallest implementation and verification sufficient for the stated requirement. Rigor means proving the requested behavior, not adding abstractions, checks, or polish.
Before resuming a run, editing after a failed check, or starting any repair, reviewer followup, capability recovery, or new Goal continuation round, read protocols/MATERIALITY_GATE.md. Apply its requirement-authority, failure-classification, validation-infrastructure, budget, stop, and resume/strategy-delta rules; only material work tied to an unmet original condition may continue.
Before capability recovery or a later recovery-stage dispatch, also read protocols/CAPABILITY_RECOVERY.md. Keep its effort-first default, sole qualified LSA v2 exception, eligible-role and operational-failure limits, task-scoped target binding, and existing counter rules unchanged.
Keep validation bounded to the requested delivery. Workflow-generated artifacts cannot expand scope, and validation infrastructure remains forbidden unless the original request or a pre-existing repository contract authorized it before dispatch.
Before any authorized commit or push, including orchestrator helper actions, follow protocols/COMMIT_GUARD.md. Invoke its deterministic guard directly; hook presence does not replace the check. A passing check never grants commit/push permission, and an explicit no-commit instruction remains binding.
Repository-specific Goal policy: do not create or activate a Goal for work in this repository unless the user's current message explicitly requests Goal mode. A run-* workflow request alone is not Goal consent.
For the conceptual UI/UX layer, use ui-ux-designer; see protocols/UI_UX_WORKFLOW.md plus the ui-ux-bundle schema/example bundle at protocols/schemas/ui-ux-bundle.schema.json and protocols/examples/ui-ux-bundle.valid.json. The same surface also covers communication-first redesign and critique work via skills/ui-communication-designer/SKILL.md. For frontend implementation or polish after a conceptual handoff, use skills/frontend-aesthetic-director/SKILL.md; it preserves the upstream wireframe/flow and focuses on visual direction, tokens, responsive behavior, accessibility, and rendered QA.
| Agent | Role | Mode | Notes |
| orchestrator-ci | CI/CD planning pipeline (docs-first, optional generation) | primary | Docs-first |
| orchestrator-modernize | Modernization planning pipeline (experimental) | primary | In-place Pipeline transition for requested execution |
| orchestrator-pipeline | Full pipeline orchestration with routing, retries, and synthesis | primary | Global handoff protocol embedded |
| orchestrator-spec | Development spec orchestration for review-ready DevSpec outputs | primary | Docs-first |
| orchestrator-flow | Flow orchestration with max-5 tasks and optional reviewer gate | primary | Bounded flow, no delta-task retry loops |
| orchestrator-simple | Simple build-style dispatcher with subagent delegation and no run artifacts | primary | No manifest/status writes |
| orchestrator-committee | Swarm committee for decision-making (experts + KISS soft-veto + judge) | primary | Decision support only |
| orchestrator-general | General-purpose orchestration for mixed coding, planning, writing, analysis, and maintenance tasks | primary | General dispatcher |
| orchestrator-analysis | Post-hoc analysis pipeline with conditional expert roster and severity-ranked findings | primary | Analytical review |
| orchestrator-ux | UX audit orchestration with profile-aware scoring and normal-user findings | primary | Analysis-only |
| specifier | Convert user input into ProblemSpec JSON and optional DevSpec JSON | subagent | hidden |
| planner | Produce PlanOutline JSON | subagent | hidden |
| repo-scout | Repo discovery and risk scanning | subagent | hidden |
| atomizer | Convert PlanOutline into atomic TaskList (DAG) | subagent | hidden |
| router | Build cost-aware DispatchPlan | subagent | hidden |
| committee-architect | Committee expert (architecture/maintainability) | subagent | hidden |
| committee-security | Committee expert (security/risk) | subagent | hidden |
| committee-qa | Committee expert (QA/reliability) | subagent | hidden |
| committee-product | Committee expert (product/user impact) | subagent | hidden |
| committee-kiss | Committee KISS guard (soft veto) | subagent | hidden |
| committee-judge | Committee judge (final synthesis) | subagent | hidden |
| analysis-correctness | Analysis expert (logical correctness/invariants) | subagent | hidden |
| analysis-complexity | Analysis expert (time/space complexity/efficiency) | subagent | hidden |
| analysis-robustness | Analysis expert (edge cases/error paths/adversarial inputs) | subagent | hidden |
| analysis-numerics | Analysis expert (numerical stability/precision) — conditionally dispatched | subagent | hidden |
| ux-novice | UX expert (first-time user discoverability/orientation) | subagent | hidden |
| ux-task-flow | UX expert (task flow/friction/completion) | subagent | hidden |
| ux-copy-trust | UX expert (copy/labels/trust/recovery wording) | subagent | hidden |
| ux-visual-hierarchy | UX expert (scanability/layout hierarchy across viewports) | subagent | hidden |
| ux-judge | Final UX judge (scorecard/findings/priority actions) | subagent | hidden |
| flow-splitter | Convert a Flow ProblemSpec into a max-5 bounded task list | subagent | hidden |
| market-researcher | Research specialist for web-based market scans, pricing signals, and monetization benchmarks | subagent | hidden |
| art-director | Convert raw 2D asset requests into concise briefs and reusable prompts | subagent | hidden |
| ui-ux-designer | Convert bounded UI/UX requests into conceptual workflow briefs, communication-first redesign guidance, surface maps, and handoff notes | subagent | hidden |
| executor | Execute one atomic task with bounded verification and repair controls | subagent | hidden |
| executor-strong | Execute one difficult atomic task through the shared executor contract on a profile-owned strong binding | subagent | hidden |
| doc-writer | Documentation specialist for design/spec/checklist/analysis outputs | subagent | hidden |
| peon | Low-cost executor for mechanical or repetitive tasks | subagent | hidden |
| generalist | General-purpose executor for mixed-scope tasks | subagent | hidden |
| test-runner | Run tests/builds/linters and collect evidence | subagent | hidden |
| reviewer | Review outputs and enforce quality gates | subagent | hidden |
| compressor | Compress repo decisions into ContextPack | subagent | hidden |
| debugger | On-demand diagnosis specialist for difficult, uncertain, cross-module, or conflicting-evidence failures | subagent | hidden |
| handoff-writer | Produce run-local handoff artifacts for a fresh session | subagent | hidden |
| kanban-manager | Manage the root-tracked todo ledger and kanban render | subagent | hidden |
| session-guide-writer | Create or refresh the root-tracked session guide | subagent | hidden |
| summarizer | Produce final user-facing summary | subagent | hidden |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

