The eleven roles
Issues-FS is developed by a team of named agentic roles, and the structure is unusually literal: each role is its own GitHub repository, added as a submodule to Issues-FS__Dev on branch dev, each with its own ROLE.md and its own .issues/ directory. The claim that follows is the one worth testing:
“The agents collaborate through Issues-FS itself… This creates a self-referential system: the issue tracker tracks its own development.”
Six conventional
| Role | What it owns |
|---|---|
| Dev | The implementation |
| QA | Testing and verification |
| Architect | Structure and design decisions |
| DevOps | Pipelines, releases, environments |
| AppSec | Security review and threat modelling — both are node types in the shipped registry |
| Conductor | Coordination across the rest |
Four unconventional — and the argument that they are central
The interesting claim in the role documents is not that these four exist. It is that they are architecturally central rather than secondary, and the reason follows directly from the foundational document.
Librarian
In a system where meaning comes from connectivity, the role that maintains connections is the meaning-making role. Not a documentation clerk — the Librarian owns whether the graph's edges still describe the world. Its reality files are the mechanism, and they are the reason this site could be built at all: the record that Issues-FS-lite existed as specification only, embedded in a manual about email, was a Librarian reality file, not a README.
Cartographer
Adds position to connectivity, via Wardley Maps. Connectivity tells you what relates to what; position tells you where each thing sits on an evolution axis, and therefore what to build and what to buy. A graph with no position is a picture with no strategy in it.
Journalist
Captures the present with enough fidelity that the Historian later has pivot points to find. This is a claim about when recording has to happen: the moment a decision is made is the only moment its alternatives are still visible.
Historian
Finds the pivot points and writes the arc. The Journey — the corpus's Historical Record document — is what this role produces.
The eleventh role, which appears in no document
There are eleven role repositories, not ten. Every role table in the corpus lists ten, and CLAUDE.md says “a team of 10 specialized AI agent roles”. The eleventh submodule is Designer, and it is named in no README, no role table and no role document. Its repository exists and is wired into Issues-FS__Dev.
Related and in the same file: “17 git submodules” is stated twice; 19 gitlinks are present. Both corrections.
It is a small discrepancy and an instructive one. A role that exists in the repository structure and in no document is invisible to exactly the reader the structure was built for — an agent that discovers its part by reading the role documents. The same failure that hid the lite specification and hid the DSL, in a third place.
How a role actually works
The operationally useful document in the corpus is the agentic role-based workflow guide — 5,814 words, Status Active, with a Quick Start checklist and a ROLE.md template. The mechanism it describes is deliberately thin:
| Element | What it does |
|---|---|
| A repository per role | Gives the role its own history, its own issues and its own permissions boundary. Roles are composed by submodule rather than by configuration |
ROLE.md | The role's own definition of what it is for and what it will not do. Read at the start of a session |
Its own .issues/ | The role's work plan, owned by the role |
| Coordination through the tracker | Roles hand work to each other by creating and linking nodes, not by calling each other |
That last row is the same design position lite states as the writer rule — each agent owns its own work plan, and work arrives by request rather than by injection. Two independent formulations of the same rule, one in a full graph and one in three folders, is reasonable evidence the rule is load-bearing rather than incidental.
Is the self-referential claim true?
Partly, and the honest version is more interesting than the marketing one.
| True for | Not true for | |
|---|---|---|
| Repositories with a real graph | Issues-FS (24 nodes) · Issues-FS__CLI (3) · Issues-FS__Service__UI (49) | Issues-FS__Docs · Issues-FS__Dev · Issues-FS__Dev__Utils — config scaffolding and no nodes |
And the largest, healthiest graph in the ecosystem — 71 nodes, 141 link entries, depth 8 — belongs to a different product: SGraph Send, the flagship consumer. Which is arguably the better evidence. A tool used seriously by somebody who did not write it tells you more than a tool used by its own authors.
The role repositories' own .issues/ graphs are not included in the 147-node ecosystem count on the examples page, which covers the eight module repositories. What those eleven graphs contain has not been measured here and is not claimed.
Where these roles turn up elsewhere
The Librarian, Journalist and Historian vocabulary is shared with newsroom.sgit.ai, which is built around the same three roles doing the same three jobs on a different corpus. The four unconventional roles were defined here first — one document each, around 4,500 words apiece, February 2026. The boundaries.
For an agent
Eleven roles, each a separate repository submoduled into Issues-FS__Dev on branch dev, each carrying a ROLE.md and its own .issues/. Six conventional (Dev, QA, Architect, DevOps, AppSec, Conductor), four unconventional (Librarian, Cartographer, Journalist, Historian), and Designer — the eleventh, named in no document. If you are operating as a role, read that role's ROLE.md first and keep your work plan in that role's own .issues/. Do not create tasks in another role's graph — hand work over by request, the same rule lite states explicitly. Any document saying there are ten roles or seventeen submodules is behind: it is eleven and nineteen.