Skip to content

Agency Agents

One markdown file per AI specialist persona, organised into divisions like engineering, marketing and healthcare, and installed by script or by a desktop app into a dozen different coding tools.

Screenshot of Agency Agents
Editor screenshot, 29 Sep 2026Agency Agents ↗

What it is

A roster of AI specialist personas, one markdown file each, grouped into divisions: engineering, design, marketing, paid media, product, project management, research, sales, finance, healthcare, game development, GIS, academic, specialized and support. Each file carries frontmatter and a defined voice and working method, and installation copies a division into a tool’s agent directory or runs a script that converts the roster for a specific target. A companion desktop app browses the whole collection and installs it into Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Qwen and others, then keeps it updated. The repository was born from a Reddit thread.

Who built itAuthor of 197 of the 457 commits, and the maintainer who integrates what arrives. The project is genuinely multi-author — fifty contributors appear in GitHub’s list, which is where that list stops counting, and 444 of the commits are attached to linked accounts. Among the contributors is claude.

Build log

8 stages
  1. 01

    A hundred and fifty-five thousand stars and no releases

    The numbers are the largest this archive has recorded: 155,273 stars, 25,048 forks, 1,127 watchers, 370 files, and 155 open issues. There are also no releases and no tags at all, which is worth noticing on a project of this size — distribution happens through an installer script and a companion desktop app, not through versioned downloads, so there is no published artifact to point a version number at. The history is 457 commits from fifty contributors — the number at which GitHub’s contributor list stops counting — with 444 of those commits attached to linked accounts. The first commit is dated 2025-10-13 and describes itself as fifty-one specialist agents. The README credits a Reddit thread as the origin.

  2. 02

    What it actually is

    Each agent is a single markdown file with YAML frontmatter, a voice and a working method, and they are grouped the way a company is grouped rather than the way software is: divisions for engineering, design, marketing, paid media, product, project management, research, sales, finance, healthcare, game development, geographic information systems, academic work, specialized roles and support. A divisions.json describes the taxonomy and two scripts police it. Getting the roster into a tool is either a copy of a directory into the tool’s agent folder or a run of the installer with a target named. The companion app does the same thing with a browser and a click, across Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Qwen and others, and auto-updates what it installed. The claim in the README — specialized rather than generic prompt templates, personality-driven, deliverable-focused — is the kind of thing that is easy to assert and hard to hold at this scale, and the interesting evidence is not the README but what the repository does to keep it true.

  3. 03

    One roster, thirteen tools

    The hidden complexity of working everywhere is a conversion step, and one pull request exposes its cost in a single line: it restores content in a hundred and thirty-one agent files across thirteen tools by keeping horizontal rules in the converted bodies. A conversion pipeline that runs one source document through thirteen output formats has thirteen chances to lose a little of it, silently, per file — and the fix was not a redesign but a rule about horizontal rules. The same contributor’s series includes a guard against duplicate slugs before anything is written, a stop after a failed automatic conversion, and a guard on shared destination paths. This is the ordinary tax on a project whose value proposition is that it works with whatever the reader already uses.

  4. 04

    A silent partial install, caused by SIGPIPE and a flag

    The best bug in the repository is one line of shell away from invisible. The installer pipes its selected-slug list into a quiet grep while the pipefail option is set. When the match is near the start of the list, grep exits before the producer finishes writing, the producer takes a broken-pipe signal, and the pipeline reports failure even though the slug matched. Every installer step skips the failed agents and continues, and the script still exits successfully — so --division engineering --link installed twelve or thirteen of sixty-four agents and said nothing was wrong. Two idempotency runs picked different subsets, fourteen and then forty-six, again without an error. The fix replaces the pipe with a here-string; the regression test puts a matching slug at the head of a twenty-thousand-entry list so the race is deterministic rather than occasional. A tool that installs some of what you asked for and returns success is worse than one that fails, and only the second run of the same command reveals it.

  5. 05

    Fifteen pull requests, one merge, and the reply that explains it

    One contributor spent a stretch auditing the installer and CI, and sent fifteen pull requests. The maintainer landed all fifteen as a single merge so that none of them would conflict with the next, with every commit arriving unchanged under its author’s name, and then explained the decision in a reply that is the best short statement of how to review a stranger’s audit work: this was a real audit rather than a drive-by, because every pull request came with a test that fails before its fix, which is what made fifteen changes reviewable in one pass. He singled out the horizontal-rule fix as restoring content in a hundred and thirty-one agents, and the destination-path fix as closing a live data-loss path in one of the installer targets. Then he asked for one thing in return — since installer and CI files are shared by nearly everything, open an issue with the list first next time so the order can be agreed and nothing collides. That is a maintainer converting a near-miss into a contribution process.

  6. 06

    The contribution path is a checklist and two scripts

    Adding an agent has a shape. The pull-request template asks for the agent’s name, its category and its specialty, and carries a checklist: follow the template in the contributing guide, include frontmatter with a name, a description and a colour, provide concrete code or templates rather than description. Submissions report their own verification — that the agent lints clean and that the division check passes — and a drift manifest is regenerated once at the end of a batch rather than by each change. A twenty-one-kilobyte contributing guide plus a nine-kilobyte Chinese translation set out the rest. The recent queue reads exactly as the process intends: three agents in two days, each closing a named issue and each arguing why it is not already covered by an existing persona — a ServiceNow platform developer distinct from an IT service manager who merely lists platforms, an Abaqus finite-element specialist distinct from a civil engineer who mentions analysis once, a policy generator distinct from a reviewer who only reads documents somebody else drafted.

  7. 07

    A persona converted into a skill, with the session attached

    One pull request does something structurally interesting: it converts an existing agent persona into a Claude Code skill and explains the difference in the body. The result is a short always-resident instruction file with a trigger-keyword description, and templates split into reference documents that load only when needed; there is no persona and no tool isolation, the author writes, because this is domain knowledge meant to apply inside the current conversation rather than a separate agent identity. That is a real distinction between two ways of packaging the same expertise, and the repository is now a place where both forms exist. Less obviously, the pull request carries a link to the session that produced it. Publishing the transcript alongside the change is a small thing that very few projects do, and it turns the proposal into something a reviewer can check rather than a summary they have to trust.

  8. 08

    Fifty names, one large share, and a model on the contributor list

    The contribution distribution is lopsided and healthy at once: the largest share is 197 commits, and behind it sit dozens of one- and two-commit contributions from names in many countries — a roster assembled by a crowd rather than by one author. The co-author trailers tell the other half of the story. There are 128 of them, and they mix models with people: Claude Opus 4.6 appears on twenty-nine, Opus 4.8 on twenty, two flavours of million-token context on twenty-six between them, Fable 5.1 and Sonnet 4.6 on eight each, Copilot on three, and one from Mistral Vibe. Alongside them are human co-authors, which is what pairing looks like when it is recorded. And claude appears in the contributor list itself with two commits. A repository of agent personas, contributed by a crowd, with the co-authorship ledger increasingly split between people and the models that worked with them, is a fair picture of where this practice has arrived.

Adjacent records

All records →