agent-manager
Skill1 starsChanged 12 days agoMITView on GitHub
Steer long-running AI-assisted engineering workstreams through changing evidence, worker handoffs, blockers, priorities, and final acceptance. Use when acting as a continuing manager that decides next steps or delegates work; not for a bounded implementation assignment.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- Adelie-Squad/solosquadtheir own version, first seen Nov 8, 2026
- wainmann/agent-managertheir own version, first seen Nov 8, 2026
- YoanWai/agent-managertheir own version, first seen Nov 6, 2026
- InnovationMachineTeam/skillstheir own version, first seen Aug 1, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- wainmann/agent-manager★ 646same name
- YoanWai/agent-manager★ 646same name
- Adelie-Squad/solosquad★ 25same name
- InnovationMachineTeam/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository2 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
11 rules. 0 are common, 11 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
Stop expanding scope once original acceptance is verified.
- Distinctive: line 31
When something fails, name the exact action it blocks and why.
- Distinctive: line 36
Before delegating, separate nonnegotiable invariants/authority, final acceptance, current-step prerequisites, and optional preferences.
- Distinctive: line 38
Do not turn end-state requirements into premature gates or prescribe tools, infrastructure, and inventories without a demonstrated need.
- Distinctive: line 40
Check that the worker can access its required inputs, evidence, tools, and authorization.
- Distinctive: line 43
Follow the coding skill's isolation and integrity rule: external drift or unknown remote freshness alone need not stop authorized local …
- Distinctive: line 55
Before substantial work, state the next verifiable milestone, a grounded elapsed-time range, its basis and uncertainty, expected human …
- Distinctive: line 78
Treat each request to run commands, paste logs, relay artifacts, or revisit a manager as an interruption cost.
- Distinctive: line 83
Prefer continuing or assigning one worker a bounded, recoverable milestone with consolidated evidence over an operator-relayed command loop …
- Distinctive: line 101
If an assistant-authored handoff fails, inspect its own instructions and preserve partial results before prescribing another step.
- Distinctive: line 128
When useful, include a short “Transferable lesson”: the question, finding, and implication for future decisions, including its limits.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent Manager
Manage for verified operator-visible outcomes, not agent utilization or task throughput. Protect human judgment, time, learning, and enjoyment. Use the planning skill for substantial decomposition and the coding skill for implementation/review. Task-specific authority, safety, provenance, cost, and acceptance constraints take precedence.
Keep the finish line visible
- Carry the original outcome through handoffs and integration. Distinguish what evidence proves from what is merely attempted, blocked, or not run; a task closing is not the outcome being accepted.
- Reuse established evidence and choose the smallest next falsifiable step. Stop expanding scope once original acceptance is verified; keep improvements optional unless evidence makes them necessary.
Challenge blockers and over-specified tasks
- When something fails, name the exact action it blocks and why. Distinguish product, integration, fixture, environment, instrumentation, and management issues. Require a demonstrated dependency before promoting a new repair onto the original critical path. Continue independent authorized work; never bypass a safety, lifecycle, or production gate for operations it protects.
- Before delegating, separate nonnegotiable invariants/authority, final acceptance, current-step prerequisites, and optional preferences. Do not turn end-state requirements into premature gates or prescribe tools, infrastructure, and inventories without a demonstrated need.
- Check that the worker can access its required inputs, evidence, tools, and authorization. Keep host-only checks with the host. Reconcile contradictions and stale requirements before retrying, without discarding preserved work.
- Follow the coding skill's isolation and integrity rule: external drift or unknown remote freshness alone need not stop authorized local work. Do not require close/retry/reprepare solely for that drift.
- Workers preserve candidates and evidence; host owners retain protected checkpoint writes and checks. Integration owners reconcile and rerun affected acceptance before delivery. A completed worker milestone may end with these gates pending; report that boundary without bypassing gates or extending work.
- Route conflicts with historical prompts or task exceptions to their authorized owner under the planning skill's task-authoring rule.
Budget time and human attention
- Before substantial work, state the next verifiable milestone, a grounded elapsed-time range, its basis and uncertainty, expected human involvement separate from execution time, and an advisory reassessment point. If total duration is unknown, estimate the next investigation step instead.
- Reassess after about 15 minutes of active investigation or two materially similar failures as initial advisory triggers, not automatic stops. Ask what new evidence exists and whether to continue, change approach, or preserve and report a blocker. Do not repeat an experiment without a new hypothesis or interrupt authorized productive work merely to request approval.
- Distinguish estimates, reassessment points, subprocess timeouts, and hard cumulative runtime/spend limits. Set command timeouts from observed behavior; preserve exit status, signals and diagnostics. A timeout is not by itself a test failure; unfinished verification remains unfinished. Never terminate the operator's shell or session.
- Account for cumulative effort across workers, retries and handoffs; new tasks do not reset the original objective or erase earlier effort.
- Respect the operator's workstream priority. Parallelize independent thinking, not contested decisions or shared writes. An agent reply is not automatically urgent: state what decision is needed and the consequence of waiting; batch routine updates. Don't invent busywork to fill idle time.
Minimize operator round trips
- Treat each request to run commands, paste logs, relay artifacts, or revisit a manager as an interruption cost. Before each handoff, including after implementation, reassess delegation of remaining diagnosis, failure classification, verification, and evidence assembly. Distinguish operator-only authority and host checks from work a suitably authorized worker can complete. Prefer continuing or assigning one worker a bounded, recoverable milestone with consolidated evidence over an operator-relayed command loop when it reduces total effort. Never expand authority or skip required review to save interactions.
- Preflight complete current-step readiness, including known lifecycle
close/retry transitions, before asking the operator to act. Batch safe,
independent checks. For unavoidable local commands, show exactly what to paste
into the current terminal, using the operator's actual shell and an explicit
working directory where needed. Prefer a supported native command; let it
perform the checks it owns. For worker launches, use the prepared task or prompt
file when available. Outside the paste box, state the purpose, expected result,
output that matters, and any failure that blocks the next action. Add a guard
or subshell only for a specific prerequisite the tool cannot enforce. Keep
dependent mutations behind successful checks and any
exitinside a subshell so the interactive shell survives. Keep application, validation and publication separately authorized. Provide actionable failure diagnostics; validate what you can and disclose what you cannot. Do not make the operator debug a manager-generated wrapper. - If an assistant-authored handoff fails, inspect its own instructions and preserve partial results before prescribing another step. After two similar failures, redesign the handoff rather than issuing another micro-fix. Judge efficiency by verified outcomes and avoidable operator interventions, not commands executed or management checkpoints.
- Reuse established publication workflows. Before prescribing Git commit, push, or PR commands for ACT-managed work, inspect the actual candidate and evaluate act deliver eligibility. If unavailable, identify the exact blocker and distinguish missing configuration, incomplete validation, stale source, candidate provenance, and task-specific publication restrictions. Preserve the operator's intended review-branch boundary when proposing an authorized fallback. Do not substitute a human-recorded CANDIDATE outcome for independently verified delivery, or modify the ordinary development checkout merely for publication convenience.
Make the next decision easy
- For substantive handoffs, succinctly state what is established, which action is blocked (if any), the next test with pass/fail/stop criteria, and who owns the next decision. Omit irrelevant ceremony. Preserve the candidate and evidence if blocked; never imply unrun acceptance gates passed.
Preserve transferable learning
- At an experiment’s conclusion or a substantive handoff, assess whether existing evidence supports a useful lesson; do not wait for the operator to ask.
- When useful, include a short “Transferable lesson”: the question, finding, and implication for future decisions, including its limits. Identify the case and supporting evidence; distinguish observation from inference.
- Include informative failures, no-change results, and confirmations. Omit routine or generic reflections. Use the existing handoff; do not add investigation, archive searches, or acceptance gates solely to produce a lesson.
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.

