Performance and token budget

Gates are not run inline. iru-code, iru-code-one-task-group and every <key>-code-one-task-group skill dispatch each test, coverage, quality, license and security run to the iru-gate-runner agent. A subagent has its own context, its own (small) prefix and its own model, so the caller’s cache is untouched, and only a compact summary comes back into the caller’s context. Whole coding skills run through iru-isolated-skill-executor, which inherits the model. One accepted exception remains inside the gate runner: the 11 doc-comment audit skills (iru-java-javadoc, iru-kotlin-kdoc, iru-android-dokka, iru-kmp-dokka, iru-dotnet-docfx, iru-typescript-tsdoc, iru-php-phpdoc, iru-python-docstrings, iru-swift-docc, iru-rust-rustdoc, iru-go-godoc) are sonnet, because they write the missing doc comments, and every group skill dispatches them through the haiku iru-gate-runner, so the model still switches once inside that subagent. The switch stays out of the caller’s context and cache, and the subagent’s prefix is small, which is why it is accepted rather than fixed; the audit does not report it because the call sits inside an Agent({…​}) prompt.

catalog-audit.py reports every Skill() call whose caller and callee models differ and that is not delegated to an agent (the "inline cross-model calls" section), so a new one cannot appear unnoticed. A call counts as delegated when it sits inside an Agent({…​}) prompt or within 250 characters after a mention of iru-gate-runner or iru-isolated-skill-executor: the *-generate-all-tests skills describe the dispatch in a sentence and write the Skill() call as the prompt it carries.

10 are calls to iru-explore (opus) from skills that need its report (project type, technology stack, docs location) in their own context; an agent would return only a summary, and the exploration is a one-off per run.

2 are iru-issue calling iru-plan and iru-pr-review (opus): both are interactive (questions, confirmation before posting comments), so they must run in the orchestrator’s conversation, not in an isolated agent.

1 is iru-knowledge-compact calling iru-knowledge-complete (haiku), a single-purpose file operation whose stop message the caller reads; an agent per item would add a context for a few file edits.

By purpose would give a setup plugin (70 scaffold and workflow skills, 26,401 description characters), a gates plugin (59 test, coverage, quality, doc-audit, version-bump and test-generation skills, 19,422 characters) and a code plugin (39 -code-one-task and -code-one-task-group skills, 14,360 characters) besides the core. A repository uses one or two stacks, so every one of those plugins would still carry the other sixteen stacks' skills: installing "gates" for a Java library lists 59 skills of which 5 apply. The per-purpose split also crosses the dependency graph the wrong way: a stack’s code skill calls that stack’s gates and scaffolds, so the three purpose plugins would depend on each other and install together in practice.

By technology matches how the skills call each other: every Skill() edge is inside a stack or from a stack to iru-core (or to a sibling the stack really reuses, such as iru-springboot to iru-java), which is what lets tools/generate-marketplace.py derive the plugin dependencies from the audit’s call graph and fail on an uncovered edge.

The three agents already cover the shapes that repeat (about 184 gate runs, 101 whole-skill runs and 2 history summaries across the skills). A fourth agent adds another context window and another system prompt to every invocation.

The roles of the issue-to-PR cycle are interactive. A subagent returns one summary and cannot hold a dialogue with the user, and iru-plan, iru-pr-review and the ticket skills ask questions.

The model for each role is already chosen per skill (opus for exploration, planning and review, sonnet for coding, haiku for gates). An agent pins one model, so it would duplicate that choice and remove the ability to vary it by task.

Skill({skill: "iru-java-test"}) by bare name still resolves, as does the namespaced iru-java:iru-java-test, so none of the 298 Skill() call sites needed to change.

Agent({subagent_type: "iru-gate-runner"}) by bare name does not resolve. The agent exists only as iru-core:iru-gate-runner, and the error lists the namespaced names as the available ones.

.claude/skills does not exist, which is why key discovery first reads the skills available in the session and uses find .claude/skills only as a corroborating check.

Agents listed on a marketplace entry whose source is the repository root load even though claude plugin details shows Agents (0).

Consolidating the shared reference files. About 357 KB of the supporting files are byte-identical copies (the UI contract in 12 skills, the CLI contract in 4, and so on). One copy per plugin would remove most of it, but every skill is deliberately self-contained so that copying its directory into another repository keeps working. The copies are instead checked for drift.

Merging the per-language gate skills. One cross-language test, one coverage and one quality skill would shrink the listing by about thirty entries, but each skill’s body is specialized per toolchain, the names are part of the public interface, and the gate runner and every code skill refer to them.

A physical plugins/<name>/skills/ tree. The marketplace instead lists each plugin’s skill directories over the unchanged .claude/skills/ tree (source: "./"). The trade-off is that each installed plugin caches a full copy of the repository (231 MB measured for two plugins from a directory marketplace, see Plugins); a physical tree would remove that but move 196 directories and change the path used when copying a skill, so it needs an explicit decision.