firehose> #llmops

Role-Typed Agent Roster

Shipping a whole organisation's worth of job roles as named, individually-invocable commands — CEO, staff engineer, design engineer, QA lead, DX tester, chief security officer — so the operator selects a role rather than re-describing a methodology. Each command carries a role's working method, not just its job title: a /qa lead doesn't only find bugs, it fixes them with atomic commits and generates a regression test for every fix; a DX tester actually walks the onboarding flow, times it, and screenshots the errors; a design engineer emits shippable HTML rather than a mockup. The roster ships as one repo and installs in one clone (Public Skill Adoption).

Two design moves make it more than a prompt collection. The first is that the role name is the compression: "run a CEO product review" invokes a whole stance — rethink the problem, look for the 10-star product hiding inside the request, decide among expansion / selective expansion / hold scope / reduction — that the operator would otherwise have to restate every time. The role is a handle on a methodology, which is why the roster is a Reusable Workflow Library with a particularly memorable index. The second is splitting a role by authority, not by method: /qa and /qa-only run the same methodology and differ only in whether the agent may write. That is Agent Supervision expressed as a naming convention, and it is the roster's sharpest idea — the operator chooses the blast radius at invocation time, in one character of difference.

The obvious failure mode is that an org chart is not a decomposition of your work. A roster is someone else's company, and adopting it wholesale imports their structure along with their methods. The /-palette after a roster install is a scrolling list, most of which the operator will never invoke and all of which they must now remember exists.

Claims


Linked from