AI Catalog

Each skill lives in its own directory under .claude/skills/ and contains a single SKILL.md file with:

Skills in this catalog range from small, single-purpose checks (iru-check-license, iru-java-test) to orchestrators that call other skills in sequence.

Several skills in this catalog spawn a sub-agent through the Agent tool, to run a sub-task in an isolated context (so its detailed output — a full test log, a static-analysis report, an entire nested skill run — doesn’t clutter the main conversation) or to search the codebase without derailing the current flow. This repository defines three custom agents under .claude/agents/ for its most-duplicated sub-agent shapes:

Skills that need ad hoc context isolation beyond those three shapes still use Claude Code’s built-in agent types: the Explore agent (a fast, read-only search agent) is used explicitly by the iru-explore skill, and the general-purpose agent (Claude Code’s default when no specific type is named) covers one-off cases like bootstrapping the iru-setup-antora skill mid-run.

See Agents (built-in types) and Gate Runner, Isolated Skill Executor, Change Summarizer (custom agents) for detail on where and why each is used.

CLAUDE.md is a plain markdown file that Claude Code loads automatically, without being invoked, at the start of every session — unlike a skill or agent, which only act when called on. It holds the persistent facts Claude would otherwise need re-explaining every session: build/test commands, coding conventions, architectural notes, and "always/never do X" rules specific to a project or a person.

Claude Code reads it from several locations at once (project root, a personal ~/.claude/CLAUDE.md, nested subdirectory files, and an enterprise-managed policy file, if any) and concatenates them rather than picking one — see The CLAUDE.md file for exact locations, precedence, and how to create or update one without letting it bloat the context window.

A plugin is not a new kind of artifact alongside skills, agents, and CLAUDE.md — it’s a packaging and distribution mechanism for them. A plugin is a directory (with a .claude-plugin/plugin.json manifest) that can bundle any combination of skills, custom agents, slash commands, hooks, and MCP server configs into one installable, versioned unit, published to a marketplace (a private, organization-internal one or a public one) and installed into a repository with /plugin install instead of copying files by hand.

This repository does not currently package itself as a plugin — its skills are adopted by copying the .claude/skills/<name>/ directories directly — but Plugins and Packaging and distributing skills, agents, and CLAUDE.md cover when a plugin is worth the extra packaging step instead.

Scaffolding a brand-new repository’s build, docs, CI/CD, and top-level files from nothing, so a new Java library starts out matching the same conventions as every other repository in the catalog.

Turning a rough idea, bug report, or request into a well-formed, tracked ticket — a GitHub issue or a Jira ticket — before the Issue-to-PR Development Cycle picks it up.

Taking a piece of work from "described" — a tracked ticket (a GitHub issue or a Jira ticket), or a task you describe yourself — to an implemented, open pull request.

Implementing a single plan task end to end, plus the point-in-time checks (tests, coverage, lint, Javadoc) a person or another skill can run against a Maven/Java project any time — each reporting real, measured results rather than an estimate.

The .NET/C# counterpart to Java Development Tooling — implementing a single plan task end to end, plus the equivalent point-in-time checks (tests, coverage, Roslyn analyzers, XML doc comments) against a .NET project.

The database counterpart to Java Development Tooling and .NET Development Tooling — implementing a bucket of database tasks (schema migrations, seed data, index changes) from a plan.

Everything after code exists but before it’s merged: describing the change and getting it reviewed, on whichever platform hosts the repository (GitHub, Bitbucket, Azure DevOps, or TFS).

Keeping an already-bootstrapped repository correct and current, well after its initial setup.

Maintaining this catalog’s own documentation rather than a consumer repository’s.

The custom agents this catalog’s skills delegate to for its most-duplicated sub-agent shapes, cutting across every group above rather than belonging to any single workflow.

iru-setup-java-library-repository collects the project’s identity and CI/CD parameters once, then orchestrates six other skills in a fixed order so nothing is asked twice:

Any of these six can also be run standalone against an existing repository to fill a single gap (e.g. just /iru-setup-antora to add docs to a repository that already has a pom.xml).

iru-create-github-issue and iru-create-jira-ticket turn a rough idea into a tracked, actionable ticket, ready for a later, separate /iru-issue invocation. See guides/common-workflows.adoc#filing-a-ticket for a more detailed walkthrough.

Both skills work the same way up to filing; which one to use depends on which tracker the repository/team uses. Neither is required — /iru-issue and /iru-plan work fine against a ticket filed by hand, or against no ticket at all (a free-form description).

iru-issue is the single entry point for taking a tracked ticket — a GitHub issue or a Jira ticket — to an open, reviewed pull request. See guides/common-workflows.adoc#typical-development-cycle for a more detailed walkthrough — this is the main workflow for day-to-day work in this catalog.

iru-code itself doesn’t implement anything directly: for every task group it dispatches to iru-code-one-task-group, which resolves each task’s language and delegates to whichever iru-java-code-one-task-group or iru-dotnet-code-one-task-group skill matches — each of which captures one quality baseline for the whole bucket, implements its tasks (in parallel when the group allows it), and validates the bucket once via its own group’s tests/coverage/quality/doc skills, instead of once per task. A bucket tagged database instead goes to iru-database-code-one-task-group, which is deliberately simpler — always sequential, with no baseline or bucket-wide validation of its own. The whole run is bracketed with project-wide quality (iru-java-code-quality/iru-dotnet-code-quality) and security (iru-check-security) baselines, updating documentation via iru-update-docs once both pass (see Code). iru-explore and iru-plan can also be run individually (/iru-explore, /iru-plan) ahead of, or instead of, the full /iru-issue flow, and either a GitHub issue or a Jira ticket works the same way throughout.

iru-release must be run from develop and drives the whole version bump itself, delegating only the README and PR description. See guides/common-workflows.adoc#generating-a-release for a more detailed walkthrough.

There is no single orchestrator for this — it’s a set of independent skills, each scoped to one artifact, run after code has already changed:

iru-setup-changelog is deliberately not part of this flow: it only bootstraps a changelog that doesn’t exist yet and stops immediately if CHANGELOG.md is already present (see Setup Changelog). Keeping an existing changelog current on each release is `iru-release’s job, not a standalone update skill’s.