agentleFS
dtnorrisdtnorris/agent-skills/skills/agent-manager/SKILL.md

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

  • Other versions4 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 4

    1. wainmann/agent-manager★ 646same name
    2. YoanWai/agent-manager★ 646same name
    3. Adelie-Squad/solosquad★ 25same name
    4. 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
  1. Distinctive:

    Stop expanding scope once original acceptance is verified.

    line 26
  2. Distinctive:

    When something fails, name the exact action it blocks and why.

    line 31
  3. Distinctive:

    Before delegating, separate nonnegotiable invariants/authority, final acceptance, current-step prerequisites, and optional preferences.

    line 36
  4. Distinctive:

    Do not turn end-state requirements into premature gates or prescribe tools, infrastructure, and inventories without a demonstrated need.

    line 38
  5. Distinctive:

    Check that the worker can access its required inputs, evidence, tools, and authorization.

    line 40
  6. Distinctive:

    Follow the coding skill's isolation and integrity rule: external drift or unknown remote freshness alone need not stop authorized local …

    line 43
  7. Distinctive:

    Before substantial work, state the next verifiable milestone, a grounded elapsed-time range, its basis and uncertainty, expected human …

    line 55
  8. Distinctive:

    Treat each request to run commands, paste logs, relay artifacts, or revisit a manager as an interruption cost.

    line 78
  9. Distinctive:

    Prefer continuing or assigning one worker a bounded, recoverable milestone with consolidated evidence over an operator-relayed command loop …

    line 83
  10. Distinctive:

    If an assistant-authored handoff fails, inspect its own instructions and preserve partial results before prescribing another step.

    line 101
  11. Distinctive:

    When useful, include a short “Transferable lesson”: the question, finding, and implication for future decisions, including its limits.

    line 128

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 exit inside 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.