agentleFS
Sign inStart free
imMamdouhaboammarimMamdouhaboammar/get-things-done/skills/gtd-capability-router/SKILL.md

gtd-capability-router

Skill2 starsChanged 2 months agoMITView on GitHub

Use when a GTD task can be executed through multiple tools, plugins, connected sources, reviewers, agents, or GitHub actors and the agent must choose the smallest safe stack with explicit ownership, live-state authority, verification, review, and landing boundaries. Also use for continuation work, repository/PR missions, and skill/plugin engineering where stale state or overlapping capabilities can cause duplicate or unsafe work. Do not use for simple one-step tasks with an obvious single tool, or to replace GTD's blocker router or domain-pack selection.

The file

Show its rules and text

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈19

    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:

    Read the current outcome, blocker, Ready/Done state, constraints, and requested action.

    line 26
  2. Distinctive:

    Treat the registry as capability metadata, not proof that a named capability is callable now.

    line 32
  3. Distinctive:

    If the nominal owner is blocked, choose the smallest safe fallback or record an explicit evidence gap.

    line 42
  4. Distinctive:

    Only one selected capability owns a mutable surface at a time unless writes are clearly independent.

    line 45
  5. Distinctive:

    When delivery was requested and tools exist, perform the action.

    line 48
  6. Distinctive:

    Do not substitute planning, review, or readiness analysis for execution.

    line 49
  7. Distinctive:

    Prefer tests, builds, type checks, lint, runtime checks, current-head CI, inspected artifacts, returned IDs, or other observable proof.

    line 52
  8. Distinctive:

    Use one primary independent reviewer by default.

    line 56
  9. Distinctive:

    Add a second specialist lens only for a distinct material risk.

    line 57
  10. Distinctive:

    Use exactly one active landing owner and bind landing evidence to the current head/state.

    line 64
  11. Distinctive:

    Never invent a tool's capability, availability, command, bot trigger, or write authority

    line 73
  12. Distinctive:

    Never invoke a blocked nominal owner merely to satisfy a recipe

    line 74
  13. Distinctive:

    Never use a reviewer as proof that executable checks passed

    line 75
  14. Distinctive:

    Never ask a readiness analyzer to discover live state it cannot access

    line 76
  15. Distinctive:

    Never treat absence of findings from a blocked or rate-limited reviewer as a clean review

    line 77
  16. Distinctive:

    Never reuse stale exact-head readiness after mutation

    line 78
  17. Distinctive:

    Never trigger every reviewer because several are installed

    line 79
  18. Distinctive:

    Never let a companion tool weaken GTD Ready, Done, authority, or evidence rules

    line 80
  19. Distinctive:

    Do not expose internal routing ceremony when a simple task only needs one obvious capability.

    line 96

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

GTD Capability Router

Route an already understood GTD work cycle to the smallest safe capability stack.

This skill extends the GTD core contract. It does not replace the GTD mode router, Definition of Ready, Definition of Done, domain packs, or Execution Brief.

Load references/core-contract.md first. Then load:

  • references/router.yaml for routing invariants and route families
  • references/capability-registry.yaml for stable capability roles
  • agents/roles.yaml when the mission needs multiple logical roles
  • references/repository-playbook.md for repository, Issue, Pull Request, CI, bot, or landing work
  • references/plugin-skill-playbook.md for Agent Skill or Agent Plugin work
  • references/security-boundaries.md when authority, credentials, destructive actions, or sensitive surfaces are in scope
  • references/source-lineage.md when maintaining or extending this pack

Routing loop

  1. Establish current GTD state Read the current outcome, blocker, Ready/Done state, constraints, and requested action. Do not create a second planning system.
  2. Classify the execution surface Distinguish skill or in-host capability, connected source, external authority, repository-native gate, GitHub app or bot, and local/runtime executor.
  3. Resolve live availability Treat the registry as capability metadata, not proof that a named capability is callable now. Discover the current callable surface before selection.
  4. Choose the smallest useful stack Assign only roles that materially change the work: primary owner, source of truth, write owner, verifier, independent reviewer, and landing owner. Omit roles that are not needed.
  5. Separate nominal from selected owner The nominal owner is the best capability in principle. The selected owner is the callable capability actually used now. If the nominal owner is blocked, choose the smallest safe fallback or record an explicit evidence gap.
  6. Protect write ownership Only one selected capability owns a mutable surface at a time unless writes are clearly independent.
  7. Execute before judging When delivery was requested and tools exist, perform the action. Do not substitute planning, review, or readiness analysis for execution.
  8. Verify with executable evidence Prefer tests, builds, type checks, lint, runtime checks, current-head CI, inspected artifacts, returned IDs, or other observable proof. Reviewer agreement is not executable proof.
  9. Review independently when risk justifies it Use one primary independent reviewer by default. Add a second specialist lens only for a distinct material risk.
  10. Refresh after mutation Any push, bot-authored commit, deployment, migration, or external mutation can stale previous evidence. Refresh live state before readiness or landing decisions.
  11. Land through one authority Use exactly one active landing owner and bind landing evidence to the current head/state. Queue submission or approval intent is not merge completion.
  12. Report evidence status Distinguish completed, verified, partially verified, blocked, and not started.

Hard rules

  • Current connected state outranks memory, handoff prose, and old screenshots
  • Never invent a tool's capability, availability, command, bot trigger, or write authority
  • Never invoke a blocked nominal owner merely to satisfy a recipe
  • Never use a reviewer as proof that executable checks passed
  • Never ask a readiness analyzer to discover live state it cannot access
  • Never treat absence of findings from a blocked or rate-limited reviewer as a clean review
  • Never reuse stale exact-head readiness after mutation
  • Never trigger every reviewer because several are installed
  • Never let a companion tool weaken GTD Ready, Done, authority, or evidence rules

Output contract

For substantial routing decisions, preserve:

  • current GTD state and active mode
  • nominal owner and selected owner
  • source of truth
  • mutable surfaces and write owner per surface
  • verification plan and evidence
  • independent review path
  • landing owner when applicable
  • unavailable capabilities and resulting evidence gaps
  • next executable action

Do not expose internal routing ceremony when a simple task only needs one obvious capability.

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.

Check your setup, free