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.

Standing up a brand-new Spring Boot service — as opposed to a library — with Domain-Driven Design and hexagonal (ports and adapters) architecture imposed from the first commit: a Maven multi-module reactor, a contract-first API layer, reproducible integration tests, infrastructure-as-code, CI/CD, and a documentation page set derived from the code.

The architecture this group imposes is deliberately not configurable. Dependencies point inward only — domain depends on nothing, application sees only domain, each infrastructure and api adapter sees only domain (plus application for the inbound side), and boot is the composition root that wires everything. That direction is enforced twice over: by maven-enforcer-plugin bannedDependencies rules at module granularity, and by an ArchUnit test at package granularity. Every dependency version is declared in the root pom.xml and nowhere else, and Java 21 is the enforced minimum.

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 java-springboot language/framework backend for the iru-code pipeline — the pair of skills that implement plan tasks in a DDD/hexagonal Spring Boot service, as opposed to the plain Java/Maven backend above — plus the standalone Spring Boot checks a person runs on demand against such a service. Registered by convention — Plan derives the java-springboot key from the *-code-one-task directory name, and Code One Task Group dispatches that key’s tasks to the group skill — so no orchestrator mentions Spring Boot anywhere in its own instructions.

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.

Turning meeting transcriptions and their attached documents into a durable, queryable knowledge base at knowledge/ — filed meeting summaries, per-person profiles, tracked agreements, and open pending tasks — and closing the loop as those tasks get done.

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-setup-java-springboot is the service-shaped counterpart to the flow above. It interviews the user once — project identity, target cloud, reactive or blocking, and every technology choice — resolving versions and dependency ids against the live Spring Initializr API, records everything in springboot-stack.yml, and then runs seven sub-skills in a fixed order that each read that manifest back:

The order carries real constraints rather than being a preference: poms before modules (a module needs its parent), modules before APIs (generated sources need somewhere to land), APIs before the container stack (it must know whether a schema registry is needed), and everything before the workflows and documentation, both of which survey what is actually on disk. Only the first step is fatal if it stops — every later sub-skill that stops is recorded in the final report and the run continues.

Two decision points are worth knowing about before starting. The concurrency model (blocking, reactive, or both) is asked early because it decides which starter every other technology resolves to, and "both" is flagged as the hardest to reason about. The deployment platform (AWS or Google Cloud) determines the whole OpenTofu layout and the recommended dynamic-configuration mechanism, so it can’t be deferred either.

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). Only iru-create-jira-ticket supports an epic assignment and delegates to iru-jira-custom-context for organization-specific context — there is no GitHub equivalent for either.

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 — if quality regresses, follow-up issues can be filed on whichever tracker the plan itself originated from (GitHub via gh issue create, or Jira via iru-create-jira-ticket) — updating documentation via iru-update-docs once both pass, and archiving the plan under a filename that embeds the originating ticket id (see Code). iru-issue then attaches that archived plan back onto the ticket before opening the PR, so a later iru-explore of the same ticket finds it as precedent. 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 — for a Jira ticket, iru-explore also pulls in its epic, linked tickets, and any attached prior implementation plans for extra context.

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.

A separate, standalone lifecycle from the code-focused workflows above: turning meeting transcriptions into a durable record and closing the loop as tracked agreements get done. iru-knowledge-setup runs once; iru-knowledge-process-inbox, iru-knowledge-briefing, iru-knowledge-complete, and iru-knowledge-compact each run repeatedly, on their own schedule. The one internal hand-off is at the end of a filing run: iru-knowledge-process-inbox invokes iru-knowledge-compact once it has filed every meeting in the inbox, so an item a new meeting re-raised gets collapsed into the task an earlier meeting already produced instead of accumulating as a near-duplicate — and iru-knowledge-compact hands each already-finished item to iru-knowledge-complete. iru-knowledge-compact also runs standalone as periodic housekeeping, and confirms its full plan before deleting or editing anything. iru-knowledge-to-issue and iru-knowledge-to-jira also run repeatedly, but reach into the Issue-to-PR Development Cycle and Ticket Intake groups (via iru-explore plus iru-create-github-issue/iru-create-jira-ticket respectively) to turn a pending agreement into tracked work on whichever tracker fits, without itself completing that agreement: