agentleFS
xingfanxiaxingfanxia/AX-skills/task-shaped-agent-routing/SKILL.md

task-shaped-agent-routing

Skill4 starsChanged 54 days agoMITView on GitHub

Design or audit agent responsibilities, delegation boundaries, and review topology from the actual work. Preserve the user's configured model and reasoning policy; do not invoke merely because agents are available.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    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:

    Do not down-route scouts or workers, raise reviewer effort, or choose a different model merely because a role sounds cheaper or harder.

    line 16
  2. Distinctive:

    Keep work direct when it is tightly sequential, needs the coordinator's own source understanding, or is faster to perform and verify than …

    line 26
  3. Distinctive:

    Before splitting, consider source ownership, integration cost, observability, and the consequence of a wrong result.

    line 34
  4. Distinctive:

    Never let a worker broaden permissions or perform an external action that the user has not authorized.

    line 49
  5. Distinctive:

    Keep useful progress and uncertainty visible while continuing authorized work.

    line 61
  6. Distinctive:

    Do not create a new task graph or ledger for work that fits one coherent pass.

    line 62

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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.

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

Task-Shaped Agent Routing

Choose responsibilities and parallel work that improve the requested outcome. Model and reasoning settings come from the user's current routing policy, not from an assumed cost or capability ladder.

Respect the runtime contract

Honor an explicit model and reasoning preference for every role. In AX's Codex configuration the uniform route is gpt-6-astra with xhigh reasoning. Do not down-route scouts or workers, raise reviewer effort, or choose a different model merely because a role sounds cheaper or harder.

For other environments, inherit the caller's supported settings unless the user requests a different route. Do not silently translate model names into unsupported provider-specific fields. Distinguish requested configuration from observed runtime metadata, and disclose unavailable metadata.

Decide whether delegation helps

Keep work direct when it is tightly sequential, needs the coordinator's own source understanding, or is faster to perform and verify than to dispatch.

Delegate independent investigations, well-separated implementation areas, or one consequential claim needing independent evidence when parallel agents can save time or improve quality. Use parallel tool calls for independent lookups that do not need separate judgment.

Before splitting, consider source ownership, integration cost, observability, and the consequence of a wrong result. A large file count is not itself a reason to create agents. A small change may still benefit from an independent review of a concrete permission or persistence boundary.

Bound the task

Give each child the outcome, relevant sources, owned files, allowed mutations, expected evidence, and condition for returning. Add a retry limit when the operation can loop. Keep writers disjoint and coupled changes sequential.

Roles describe the work: retrieval, implementation, integration, diagnosis, research, architectural judgment, or focused review. They do not require separate model tiers or a fixed roster.

Never let a worker broaden permissions or perform an external action that the user has not authorized. Use actual tool capabilities rather than names copied from another harness.

Integrate and finish

The coordinator owns the stable objective, dependency order, and final acceptance decision. Read child evidence and check consequential claims. Incomplete or contradictory output calls for a better observation, a clarified contract, or direct takeover; it does not automatically justify another reviewer or a more expensive model.

Keep useful progress and uncertainty visible while continuing authorized work. Do not create a new task graph or ledger for work that fits one coherent pass.

Result

For a routing design, return the chosen direct/delegated structure, ownership, runtime settings, and verification owner. For implementation, apply that structure and deliver the requested result. Add independent review only for a named material claim; do not use agent count as a quality metric.

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.