AI Catalog
| This documentation was generated with the assistance of AI. Please report any inaccuracies. |
AI Catalog is a collection of Claude Code Skills —
reusable, version-controlled playbooks for common software engineering workflows. Instead of re-explaining
the same process to Claude in every project (how this team bootstraps a Java library, how a pull request
should be reviewed, how release notes get written), each workflow is captured once as a SKILL.md file and
invoked on demand with a slash command such as /iru-plan or /iru-pr-review.
Why this exists
Prompting an AI assistant to repeat a multi-step process consistently is hard: the steps drift between sessions, edge cases get forgotten, and every teammate ends up with a slightly different mental model of "how we do X". A skill fixes that by writing the procedure down once — what to check first, what to skip, what "done" looks like — so any repository that adopts it gets the same behavior every time it’s invoked.
Core concepts
A skill
Each skill lives in its own directory under .claude/skills/ and contains a single SKILL.md file with:
-
A short description used by Claude Code to decide when the skill is relevant.
-
Step-by-step instructions written for an agent to follow, including what to survey before acting, what to leave untouched, and how to report back.
Skills in this catalog range from small, single-purpose checks (iru-check-license, iru-java-test) to
orchestrators that call other skills in sequence.
An agent
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:
-
iru-gate-runner— runs a single verification/quality-gate skill (tests, coverage, code-quality/lint, license headers, doc-comment audits, security scans, a full build), optionally diffs it against a baseline, and reports back only a compact summary. -
iru-isolated-skill-executor— runs one named skill end to end in a completely fresh context so an earlier exploration/planning transcript can’t bias it, while the caller keeps running afterward. -
iru-change-summarizer— fans out over a git commit/tag range and returns only the user-facing changes.
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.
A CLAUDE.md file
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
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 can be adopted in either way: by copying the .claude/skills/<name>/ directories directly, or by
adding it as a plugin marketplace (ai-catalog) and installing only the plugins for the stacks in use — iru-core
plus one plugin per stack, each skill page names the plugin that ships it. Plugins and
Packaging and distributing skills, agents, and CLAUDE.md cover when a plugin is worth the extra packaging step instead.
Further guides
Beyond this catalog’s own skills, the following pages cover the underlying artifacts (CLAUDE.md, skills, agents, plugins) more generally: how to create or update each one, how to write instructions for them that get good, consistent results without wasting context, and how they differ across AI coding assistants.
| Guide | Covers |
|---|---|
What |
|
A closer look at the three workflows a person runs most often — the typical development cycle starting from a ticket, filing a ticket before work begins, and generating a release — each with a fuller diagram than the one on this page. |
|
The catalog-wide UI contract: decomposing a design into composed components, virtualized collections with
reusable item components, UI tests over every state × left-to-right/right-to-left × light/dark with screenshots
under |
|
Where skills and agents live, when to reach for one versus the other, and the fastest reliable way to draft a new one — asking Claude Code itself, grounded in existing examples. |
|
What information |
|
Where this catalog’s pipelines are already built to grow by convention (the |
|
What a plugin bundles, its manifest/directory layout, and how marketplaces (private or public) distribute one across repositories. |
|
How to phrase instructions in a |
|
Copying files into |
|
How the catalog is put together: skills, agents, templates and references, plugin membership, and the pipelines that compose them. |
|
Measured token and size budgets, the model tier of every skill and agent, the prompt-cache analysis, and the before/after sample runs of the optimization (issue #11). |
|
How CLAUDE.md, skills, agents, and plugins map onto GitHub Copilot’s and OpenAI Codex’s equivalent files and features, and where the underlying models genuinely differ. |
Skills reference
| Name | Group | Purpose | Detail page |
|---|---|---|---|
|
Sets an Android project’s version in lib/app Gradle scripts, optionally syncing README and Antora mentions. |
||
|
Implements one Android/Kotlin task from an implementation plan, detecting lib/app, applying bundled conventions and the UI contract for UI tasks. |
||
|
Implements one bucket of Android/Kotlin tasks per Gradle module, then validates once for license, KDoc, tests, coverage, quality and the UI contract. |
||
|
Runs Android Lint, Detekt, and ktlint on a module and reports every static-analysis issue by tool. |
||
|
Detects and runs a module’s wired Android coverage path (Kover, AGP, or vendored JaCoCo CLI) and reports exact percentages. |
||
|
Audits Kotlin classes/packages for KDoc completeness, generates missing KDoc, and verifies the Dokka build. |
||
|
Brings a Kotlin/Android Gradle module’s JVM unit test coverage to 80% per class via generated/extended tests. |
||
|
Runs Android JUnit 4 unit tests via testDebugUnitTest by class/method/pattern/path, plus a ui selector for Roborazzi screenshot and accessibility runs. |
||
|
Build the existing Antora documentation site as-is, scaffolding it first via |
||
|
Verify (and backfill) license headers on source/test files against the repository’s actual license. |
||
|
Scan for accidentally committed secrets via |
||
|
Executes implementation_plan.md group by group, validates, updates docs, and archives the plan. |
||
|
Dispatches one plan group’s tasks to matching key-specific code-one-task-group skills; checks off plan boxes live. |
||
|
Draft and file a new GitHub issue, grounded in the codebase and confirmed with the user before creation. |
||
|
Draft and file a new Jira ticket via connected Jira MCP tools, the Jira counterpart to |
||
|
Generate (and, if a matching MCP allows it, execute) the queries a single database plan task calls for. |
||
|
Implement a bucket of database tasks sequentially, one task at a time — no baseline or bucket-wide validation. |
||
|
Implements one Django plan task (models, migrations, DRF/Ninja APIs, admin) with fast pytest tests and checks off its box. |
||
|
Implements one bucket of Django tasks, then validates the bucket once, with the PostgreSQL integration tier behind a repo-wide lock. |
||
|
Sets a .NET project’s version in Directory.Build.props/csproj and the MSIX package identity, for releases. |
||
|
Implement a single .NET plan task’s code and tests only — validation is handled by |
||
|
Implement a bucket of .NET tasks (in parallel where safe) and validate the whole bucket once. |
||
|
Run StyleCop.Analyzers/CA Roslyn analyzers via a SARIF-logged build and summarize every issue found. |
||
|
Run Coverlet via |
||
|
Audit and complete XML doc-comment coverage for given types, then attempt a DocFX build. |
||
|
Scans a .NET codebase for classes lacking tests or below 80% coverage, writes unit tests to clear the bar, and adds UI tests for screens that have none. |
||
|
Runs .NET tests via dotnet test by selector, Windows-desktop aware, with a ui selector for FlaUI and Terminal.Gui UI tests, screenshots and accessibility. |
||
|
Interview the user and write a spec-style GitHub issue (functional or documentation), review it in a loop, offer a split, and file it after confirmation. |
||
|
Read-only repository and ticket exploration that reports tech stack and a normalized Project type line. |
||
|
Implements one FastAPI plan task (routers, Pydantic schemas, services, Alembic migrations) with fast pytest tests. |
||
|
Implements one bucket of FastAPI tasks, then validates the bucket once, with the PostgreSQL integration tier behind a repo-wide lock. |
||
|
Regenerate this documentation site itself from the current set of skills and agents on disk. |
||
|
Sets a Go module’s in-tree Version literal to an exact value and verifies -ldflags -X overrides point at it. |
||
|
Implements a Go task from a plan in any module or Cobra CLI, incl. Bubble Tea screens per the UI contract, writes tests, compile-checks, checks it off. |
||
|
Implements a bucket of Go tasks, then validates once: licenses, godoc, tests, 80% coverage, race detector, quality, terminal-UI captures, container tests. |
||
|
Runs golangci-lint v2, go vet, gofmt and govulncheck on a Go module; reports issues by tool and rule id. |
||
|
Measures Go statement coverage from container-free tests via -coverpkg; reports per-file gaps against a bar. |
||
|
Audits Go packages for complete doc comments, fills gaps from the code, verifies with revive/godot/go doc. |
||
|
Runs Go tests with go test -json, race detector and testscript, splits fast from integration tests, checks terminal-UI captures, reports a summary. |
||
|
Takes a GitHub issue or Jira ticket from branch creation through plan, implementation and a reviewed draft PR. |
||
|
Sets a Maven or Gradle JVM (Java/Kotlin) project’s version to an exact value, with optional README/Antora sync. |
||
|
Implement a single Java plan task’s code and tests only, against its bundled Java code agreements — validation is handled by |
||
|
Implement a bucket of Java tasks (in parallel where safe) and validate the whole bucket once. |
||
|
Runs Checkstyle, PMD and SpotBugs via Maven or Gradle and summarizes issues by tool and file; read-only. |
||
|
Measures exact JaCoCo/Kover line coverage for JVM classes (Maven/Gradle, Quarkus) against an optional bar; read-only. |
||
|
Find every Java class with no tests or under 80% coverage and generate/extend tests until it clears the bar. |
||
|
Audit and complete Javadoc coverage for given classes, then verify it builds cleanly. |
||
|
Implement one Spring Boot plan task — module resolved first, bundled best-practice reference, unit tests only. |
||
|
Implement a bucket of Spring Boot tasks and validate it once — owns module boundaries and integration tests. |
||
|
Generate JMeter load tests for a service’s main happy paths, correlating response time, CPU, and memory against concurrency. |
||
|
Runs a JVM project’s JUnit tests via Maven Surefire or Gradle test, scoped by class/method/pattern/tag, and reports. |
||
|
Extension point: gather organization-specific context for a Jira ticket, called by |
||
|
Sets a Kotlin Multiplatform app’s version in gradle.properties and, for releases, the iOS Config.xcconfig. |
||
|
Implements one Kotlin Multiplatform task in the right source set, with tests, UI tests and screenshots for UI work, and compile checks for every target. |
||
|
Implements a Kotlin Multiplatform task bucket, then validates once across Android/JVM and iOS: license, KDoc, tests, 80% coverage, quality, UI captures. |
||
|
Runs detekt, ktlint, Android Lint and SwiftLint across a Kotlin Multiplatform project and reports issues by rule id. |
||
|
Reports Kover line/branch coverage for a Kotlin Multiplatform project’s JVM/Android targets; iOS is not measurable. |
||
|
Audits KDoc coverage across every Kotlin Multiplatform source set (expect/actual aware) and builds the Dokka site. |
||
|
Brings a Kotlin Multiplatform module’s JVM-measured coverage to 80% per class with kotlin.test tests, and adds UI tests for screens that have none. |
||
|
Runs Kotlin Multiplatform tests per target (Android host, JVM, iOS simulator, XCTest) plus a ui selector for screenshots and accessibility. |
||
|
Summarize the most relevant agreements/pending tasks about a subject, scoped by person/meeting if given. |
||
|
Collapse duplicate pending tasks and close out agreements whose tracked issue is already done. |
||
|
Mark one pending agreement/task completed: check off its agreement item and delete its pending file. |
||
|
File |
||
|
Bootstrap the |
||
|
Convert a pending/not-completed agreement into a GitHub issue via |
||
|
Convert a pending/not-completed agreement into a Jira ticket via |
||
|
Runs detekt and ktlint on JVM Kotlin projects (Gradle/Maven/Spotless) and reports issues by tool and rule id. |
||
|
Audits Kotlin classes/packages for complete KDoc, fills gaps, wires Dokka module docs, verifies the Dokka build. |
||
|
Implements one Kotlin Spring Boot plan task with unit tests only, checking Kotlin/Spring build plumbing first. |
||
|
Implements one Kotlin Spring Boot task bucket, then validates once: unit coverage gate and lock-serialized integration tests. |
||
|
Implements one NestJS plan task with unit and e2e specs and checks off its box. |
||
|
Implements one bucket of NestJS tasks, then validates it once with unit coverage, type-check, build and a locked e2e stage. |
||
|
Implements one Next.js plan task and tests for the detected version/router/caching profile, then ticks its checkbox. |
||
|
Implements one Next.js task bucket, then validates once: unit coverage, quality, next build route table, serialized Playwright. |
||
|
Sets a PHP project’s version to an exact value in every Laravel/WordPress/PrestaShop location (x.y.z-dev convention). |
||
|
Implements one PHP plan task (Laravel/WordPress/PrestaShop/library) with fast tests and checks off its box. |
||
|
Implements one bucket of PHP tasks, then validates the bucket once, with an integration stage behind a repo-wide lock. |
||
|
Runs PHPStan, Psalm, Pint, PHP-CS-Fixer, PHPCS and Rector and reports issues by rule id. |
||
|
Runs PHP tests with PCOV or Xdebug and reports exact per-class line and method coverage from Clover XML. |
||
|
Audits PHP files for complete PHPDoc, fills gaps per Laravel/WordPress/PrestaShop conventions, verifies with PHPStan/phpcs. |
||
|
Runs PHP tests via Pest, PHPUnit or artisan on host, Sail, ddev or wp-env and reports a summary. |
||
|
Writes a dependency-grouped, checkbox-driven implementation_plan.md for a ticket or described task, decomposing UI designs into component tasks with UI tests. |
||
|
Drafts a PR description from the real diff against an inherited base branch; opens or updates the PR on its host. |
||
|
Reviews an open PR by id for ticket intent, convention drift and stack pitfalls; posts findings only after confirmation. |
||
|
Sets a Python project’s version in pyproject.toml and related locations, optionally syncing README and Antora mentions. |
||
|
Runs Ruff, mypy/Pyright, Bandit and framework linters as wired and reports issues by rule code. |
||
|
Runs pytest with coverage.py and reports exact per-module line and branch coverage from Cobertura XML. |
||
|
Audits Python modules for complete docstrings, fills gaps in the project’s style, and verifies with Ruff and Sphinx. |
||
|
Runs a Python project’s pytest suite (incl. pytest-django) via uv, Poetry, PDM or a venv and reports a summary. |
||
|
Implements one plan task in a Quarkus service (Java/Kotlin) with tests, running only container-free test levels. |
||
|
Implements one Quarkus task bucket, then validates it once with unit-stage coverage and a lock-serialized container stage. |
||
|
Sets a React Native app’s version for the expo or metro toolchain, including native build numbers where owned. |
||
|
Implements a single React Native plan task for Expo or bare Metro apps, with tests and checkbox update, deferring every gate to the group skill. |
||
|
Implements a bucket of React Native tasks for Expo or Metro apps, then validates once: Jest, coverage, tsc, native builds, Expo prebuild, and e2e. |
||
|
Cuts a release_x.y.z branch from develop, delegates the version bump, drafts release notes and opens the release PR. |
||
|
Review a GitHub issue or draft against a quality checklist and return classified findings with the exact question for each. |
||
|
Sets a Rust crate or Cargo workspace to an exact SemVer version across Cargo.toml, path deps and Cargo.lock. |
||
|
Implements one Rust plan task (code + tests) in a Cargo crate/workspace, rustfmt + cargo check, then checks it off. |
||
|
Implements one Rust task bucket, then validates it once: license, rustdoc, tests, 80% coverage, clippy diff. |
||
|
Runs Clippy, rustfmt and cargo-deny on a Rust workspace; reports issues by tool and rule id, with baseline diff. |
||
|
Measures Rust line/region coverage with cargo-llvm-cov (lcov + JSON), reporting uncovered ranges per target. |
||
|
Audits Rust public items for complete rustdoc, fills gaps, verifies via doc lints, |
||
|
Runs Rust tests via cargo-nextest or |
||
|
Scaffolds a Gradle Kotlin DSL Android application module with signing, Compose/Views UI, Sonar, and distribution wiring. |
||
|
Creates or updates gitflow/main-only GitHub Actions CI/CD, security workflows and Dependabot config for an Android/Gradle repo. |
||
|
Creates or updates (Update / Keep / Replace) root and per-module |
||
|
Scaffolds a Gradle/Kotlin Android library repository (wrapper, lib module, Compose app sample) from a house template. |
||
|
Orchestrates an Android/Gradle repository’s flavor scaffold, Antora docs, gitignore, CI workflows, changelog, and README. |
||
|
Scaffolds an Angular app via |
||
|
Creates or updates a working Antora docs site (Node.js/Antora, antora.yml, starter pages), adding a User interface section for UI projects. |
||
|
Scaffold a native iOS/iPadOS/macOS/watchOS/visionOS app (SwiftUI or UIKit, MVVM or MVC): XcodeGen/Tuist, SwiftPM Core, tests, Fastlane. |
||
|
Creates or updates a root CHANGELOG.md from tags, GitHub Releases, readme.txt and diffs in Keep a Changelog format. |
||
|
Creates or updates CI, contract smoke test, release, sync and security workflows for Rust/Go/Swift/.NET CLI tools. |
||
|
Orchestrates a Rust/Go/Swift/.NET CLI repository bootstrap: scaffold, docs, gitignore, CI/release, changelog, README. |
||
|
Scaffolds an agent-friendly .NET 10 CLI: Core contract library, System.CommandLine AOT tool, MSTest tests, DocFX. |
||
|
Creates or merges a .NET command-line tool’s root |
||
|
Scaffolds an agent-friendly Go CLI (Cobra, exit-code contract, testscript, golangci-lint, GoReleaser, gendocs). |
||
|
Creates or merges a Go command-line tool’s root |
||
|
Scaffolds a new Ionic Angular/React app via the Ionic CLI, then adds Vitest, ESLint/Prettier, Playwright, Maestro, and Sonar. |
||
|
Creates or updates develop, main, sync and security GitHub Actions workflows plus dependabot.yml for Java/Maven. |
||
|
Creates or updates a JVM project’s root .gitignore (Java/Kotlin, Maven/Gradle, Quarkus); asks Update/Keep/Replace. |
||
|
Generates |
||
|
Orchestrator: bootstraps or updates a Java library repository end to end in one pass, gated by open-source/visibility/ci/publish/sonar args. |
||
|
Interviews once, then bootstraps or updates a Spring Boot hexagonal multi-module service (Java or Kotlin) via sub-skills. |
||
|
Sets up a Spring Boot service’s contract-first apis/ tree and OpenAPI/gRPC/GraphQL/AVRO/AsyncAPI generators (Java/Kotlin, Maven/Gradle). |
||
|
Generates build, deploy, undeploy and security GitHub Actions workflows plus Dependabot for a Java/Kotlin Spring Boot service. |
||
|
Scaffold a Hilla React frontend into a Spring Boot web module (Java or Kotlin, Maven or Gradle). |
||
|
Scaffolds the hexagonal source tree, profiles, migrations and ArchUnit test of a Java or Kotlin Spring Boot service. |
||
|
Generate the OpenTofu infrastructure-as-code deploying the service to AWS or Google Cloud. |
||
|
Generates the Maven or Gradle KTS multi-module build for a hexagonal Spring Boot service (Java/Kotlin) from springboot-stack.yml |
||
|
Writes compose.yaml, an API mock and a Testcontainers IT harness for a Spring Boot service (Java/Kotlin, Maven/Gradle). |
||
|
Scaffolds a Kotlin Multiplatform Android + iOS app: shared module, androidApp, XcodeGen iosApp, Kover and quality tools. |
||
|
Creates build, release, sync and security GitHub Actions workflows for a Kotlin Multiplatform app, with gated macOS jobs. |
||
|
Creates or updates root and per-module .gitignore files for a Kotlin Multiplatform Android + iOS app. |
||
|
Orchestrates a Kotlin Multiplatform app repository: scaffold, Antora, gitignore, workflows, changelog, and README. |
||
|
Scaffolds a native macOS app: XcodeGen project, UI-free Core package, Swift Testing/XCUITest, entitlements, DMG script. |
||
|
Creates build, release, sync, security and Dependabot GitHub workflows for a macOS app, with a cost-gated macOS job. |
||
|
Orchestrates a native macOS app repository: scaffold, Antora, gitignore, workflows, changelog, and README. |
||
|
Scaffolds or updates a NestJS service with shared npm scripts, validated config, health checks, ORM option, Dockerfile and Sonar. |
||
|
Scaffold a Next.js app via create-next-app flags plus Vitest, ESLint, Playwright, TypeDoc, Sonar, and static or Docker output. |
||
|
Writes build, release, sync, security and Dependabot GitHub workflows for Laravel, WordPress and PrestaShop repos. |
||
|
Creates or updates the root .gitignore for PHP/Composer projects with Laravel/WordPress/PrestaShop sections. |
||
|
Scaffolds or updates a Laravel app with Pest, Pint, Larastan, composer scripts, a tested sample slice and Playwright browser UI tests with accessibility checks. |
||
|
Scaffolds a PrestaShop 8/9 module with Composer, PHPUnit, PHPStan, PHP-CS-Fixer and a packaging script. |
||
|
Bootstraps a Laravel, WordPress plugin/theme or PrestaShop module repository: scaffold, docs, gitignore, CI, changelog, README. |
||
|
Scaffolds a WordPress plugin or block theme with Composer, WPCS, PHPStan, Brain Monkey and wp-env tests. |
||
|
Scaffolds or updates a Django project with DRF or Ninja, pytest-django, Ruff, mypy, a Dockerfile and a tested sample app. |
||
|
Scaffolds or updates a FastAPI service with SQLModel/SQLAlchemy, Alembic, pytest, Ruff, mypy and a Dockerfile. |
||
|
Scaffolds build, release, sync, security and Dependabot GitHub workflows for a FastAPI or Django repository. |
||
|
Creates or updates the root .gitignore for Python projects with FastAPI/Django sections, never ignoring lock files. |
||
|
Orchestrator: bootstraps a FastAPI or Django repository end to end — scaffold, Antora, gitignore, workflows, changelog, README. |
||
|
Creates/updates Quarkus service CI/CD and security GitHub Actions workflows, Dependabot and a secrets table. |
||
|
Bootstraps a Quarkus service repository: build, docs, gitignore, CI workflows, changelog and README. |
||
|
Scaffolds or updates a Quarkus service (Java/Kotlin, Maven/Gradle, single or hexagonal) from live code.quarkus.io data. |
||
|
Scaffolds a React Native app on Expo or bare Metro with Jest, a11y linting, a dev UI gallery, Maestro smoke and screenshot flows, build profiles and Sonar. |
||
|
Scaffolds a React + Vite + TypeScript web app with Vitest, ESLint or Oxlint, Prettier, Stylelint, Playwright e2e, UI-contract screenshot and axe tests, and optional Storybook. |
||
|
Creates or refreshes the root README.md (badges, status table, docs links, install or run steps) from the repo’s real state. |
||
|
Catalog-wide bootstrap front door: detects project type, asks shared cost-aware inputs, delegates to one stack orchestrator. |
||
|
Scaffolds an agent-friendly Rust CLI: Cargo workspace, clap, exit codes, JSON output, optional Ratatui, xtask docs. |
||
|
Creates or merges a Rust command-line tool’s root |
||
|
Scaffolds an agent-friendly Swift CLI: SwiftPM package, thin ArgumentParser executable, Kit library, tests, DocC. |
||
|
Create/update build, release, sync, security and Dependabot GitHub workflows for a Swift package or Apple app repo. |
||
|
Creates or refreshes a Swift/Xcode project’s root |
||
|
Scaffolds a SwiftPM library’s |
||
|
Bootstraps a Swift package or Apple app repository end to end: scaffold, docs, gitignore, CI, changelog, README. |
||
|
Creates or updates build/release/sync/security workflows and Dependabot for seven npm/TypeScript flavors, per-file choices. |
||
|
Creates or updates a TypeScript/npm project’s .gitignore, asking Update, Keep as is or Replace when one exists. |
||
|
Scaffolds |
||
|
Orchestrates scaffold, Antora, gitignore, CI workflows, changelog and README for a seven-flavor npm/TypeScript repository. |
||
|
Scaffolds a .NET 10 Windows desktop app (WPF, WinUI 3 or WinForms): UI-free Core, MSTest, analyzers, DocFX, MSIX. |
||
|
Creates build, release, sync, security and Dependabot GitHub workflows for a Windows desktop app, with FlaUI and MSIX jobs. |
||
|
Creates or updates the root .gitignore for a .NET Windows desktop app: build output, IDE state, MSIX, signing material. |
||
|
Orchestrates a Windows desktop app repository: scaffold, Antora, gitignore, workflows, changelog, and README. |
||
|
Split an oversized GitHub issue into dependency-ordered sub-issues under a root issue and milestone, after confirmation. |
||
|
Enables, disables or changes blue/green rolling deployments of an existing Spring Boot service. |
||
|
Sets a SwiftPM library’s |
||
|
Implements one Swift task from a plan in a package, Apple app or swift-argument-parser CLI, applying Swift 6 conventions, then checking it off. |
||
|
Implements a bucket of Swift tasks, then validates it once for license headers, DocC, tests, coverage, and quality, serializing simulator runs. |
||
|
Runs SwiftLint, the wired Swift formatter, and Periphery, and reports issues grouped by tool and rule id. |
||
|
Reports exact Swift line/function coverage via |
||
|
Audits Swift declarations and DocC catalogs for missing documentation, generates it, and verifies the doc build. |
||
|
Brings a Swift codebase’s test coverage to 80% by generating or extending Swift Testing/XCTest tests per type. |
||
|
Runs a Swift project’s tests via swift test or xcodebuild -only-testing by selector, plus a ui selector for screenshot and accessibility runs. |
||
|
Sets an npm/TypeScript project’s version to an exact value across |
||
|
Implements one TypeScript task from a plan, loading only its framework’s reference material, handing React Native apps to their own key, then checks it off. |
||
|
Implements every TypeScript task in a plan bucket, then validates the whole group once for headers, TSDoc, tests, coverage, and quality. |
||
|
Runs ESLint/Oxlint/Biome, tsc, Prettier, Stylelint (NestJS/Next.js aware) and reports issues by tool and rule id. |
||
|
Runs Vitest/Jest/ng test with coverage (NestJS/Next.js aware) and reports exact line/branch % and uncovered ranges. |
||
|
Scans a TypeScript/npm codebase for files with no tests or below 80% coverage, writes or extends unit tests, and adds Playwright UI tests for web UI gaps. |
||
|
Runs TypeScript unit tests via Vitest, Jest or ng test, plus opt-in e2e and UI suites (Playwright, Maestro, Detox) with screenshots and accessibility. |
||
|
Audits and fills TSDoc on exported TypeScript symbols, then verifies with TypeDoc or Compodoc, incl. NestJS/Next.js. |
||
|
Updates Antora AsciiDoc pages from a git diff, incl. a UI section with UI-test screenshots, editing only affected pages and never source code. |
||
|
Creates and refreshes a Java or Kotlin Spring Boot service’s Antora docs: architecture, use cases, database model, APIs, metrics, and a Hilla UI section. |
||
|
Implements one plan task in a Windows desktop app on .NET 10 (WPF, WinUI 3, WinForms): Core-first code, UI components, tests, compile-check, checkbox. |
||
|
Implements one bucket of Windows desktop app tasks, then validates once: license, docs, Core tests, 80% coverage, quality diff, FlaUI UI tests, UI contract. |
Agents reference
This repository defines three custom agents, all grouped under Sub-Agent
Infrastructure; the built-in agent types it also relies on (Explore, general-purpose) have no SKILL.md-style
file of their own and are instead described together in Agents.
| Name | Purpose | Detail page |
|---|---|---|
|
Fan out over a git commit/tag range and return only the user-facing changes. |
|
|
Run a single verification/quality-gate skill (tests, coverage, lint, license, docs, security, build) for any supported stack — Java/Kotlin on Maven or Gradle, PHP, Python (FastAPI/Django), .NET, TypeScript incl. NestJS/Next.js/React Native, Android, Kotlin Multiplatform, Swift — and report back only a compact summary, optionally vs. a baseline. |
|
|
Run one named skill end to end in a fresh context, so the caller can keep running afterward. |
Purpose groups
Repository Bootstrap
Scaffolding a repository’s build, docs, CI/CD, and top-level files from nothing — or updating an older or partial setup — so a new Java library starts out matching the same conventions as every other repository in the catalog.
|
Reach for this group when standing up a brand-new repository, or when bringing one with an older or partial
setup in line with the house pattern. |
-
iru-setup-repository— catalog-wide front door: detects/asks a repository’s project type and delegates to exactly one matching stack orchestrator. -
iru-setup-java-library-repository— orchestrator: bootstraps or updates a Java library repository end to end in one pass. -
iru-setup-java-library— generatespom.xmland the standard Maven source layout. -
iru-setup-antora— scaffolds the Antora documentation site. -
iru-setup-java-gitignore— creates or refreshes the root.gitignorefor any JVM project (Java/Kotlin, Maven/Gradle, Quarkus); also reused by the Spring Boot and Quarkus orchestrators. -
iru-setup-java-github-workflows— scaffolds/updates the CI/CD GitHub Actions pipeline. -
iru-setup-changelog— bootstrapsCHANGELOG.mdfrom release history, or appends missing releases to an existing one. -
iru-setup-readme— creates or refreshes the rootREADME.md.
Spring Boot Service Bootstrap
Standing up (or updating) a 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 service can be written in Java (Maven) or Kotlin (Maven or Gradle Kotlin DSL),
read from the manifest’s project.language/project.buildTool.
|
Reach for this group when starting a deployable microservice, and reach for Repository Bootstrap instead when starting a publishable library — the two differ in more than scale. A library is signed and published to Maven Central; a service is built into a container image, deployed to a cloud with OpenTofu, and can be torn down again.
|
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.
-
iru-setup-java-springboot— orchestrator: interviews the user, resolves the stack against the live Spring Initializr API, and runs the six sub-skills below plus the documentation skill in order. -
iru-setup-java-springboot-pom— generates the reactor: the root pom holding every version and the full quality plugin set, plus one pom per module. -
iru-setup-java-springboot-modules— scaffolds the source tree: domain ports, one worked adapter per kind, use cases, profiles, migrations, and the ArchUnit test. -
iru-setup-java-springboot-apis— sets up theapis/contract tree and the OpenAPI/protobuf/GraphQL/AVRO code generators plus the AsyncAPI documentation generators, including all of their HTML documentation. -
iru-setup-java-springboot-hilla— scaffolds a Hilla React frontend into the reactor’s web module (Vitest, ESLint, Sonar wiring), run only when the manifest recordsfrontend: hilla. -
iru-setup-java-springboot-testcontainers— writes onecompose.yamland the Testcontainers harness that launches it, so local runs and CI cannot drift apart. -
iru-setup-java-springboot-platform— generates the OpenTofu configuration for AWS or Google Cloud, preferring managed services and writing no secret anywhere. -
iru-setup-java-springboot-github-workflows— scaffolds the build, deploy, promote (when rolling deployments are on), and undeploy workflows. -
iru-springboot-rolling-deployments— switches blue/green rolling deployments on or off (or changes strategy) in an already-bootstrapped service, re-running the platform and workflows skills without applying any infrastructure. -
iru-update-java-springboot-documentation— creates and then keeps current the service’s own documentation pages. Unlike the rest of this group, it is meant to be re-run continuously, in the same spirit asiru-update-docsin Repository Maintenance.
Quarkus Service Bootstrap
Standing up (or updating) a Quarkus service — Java or Kotlin, Maven or Gradle, single-module or hexagonal
multi-module — resolved against the live code.quarkus.io data and recorded in a quarkus-stack.yml manifest.
|
|
-
iru-setup-quarkus-repository— orchestrator: one-pass Quarkus bootstrap chaining service scaffold, Antora, gitignore, workflows, changelog, and README. -
iru-setup-quarkus-service— interviews once, writesquarkus-stack.yml, scaffolds the service and applies the catalog’s conventions (JaCoCo, quality tooling, a tested sample), then verifies the gates. -
iru-setup-quarkus-github-workflows— writesbuild.yml,release.yml(container image),sync.yml,security.yml, and Dependabot for the service.
TypeScript/Node Bootstrap
Scaffolding (or updating) an npm/TypeScript repository end to end — library or one of six app flavors (React, Next.js, Angular, NestJS, React Native, Ionic) — so it starts out matching this catalog’s conventions the same way a new Java library does.
|
|
-
iru-setup-typescript-repository— orchestrator: bootstraps an npm/TypeScript repository (library, React, Next.js, Angular, NestJS, React Native, or Ionic) end to end in one pass. -
iru-setup-typescript-library— scaffoldspackage.json, tsconfig, Vitest, ESLint, TypeDoc, and a src/test skeleton for a new npm/TypeScript library. -
iru-setup-react-web— scaffolds a React + Vite + TypeScript web app with Vitest, ESLint/Oxlint, Prettier, Stylelint, Playwright, and Storybook. -
iru-setup-nextjs-web— scaffolds a Next.js app viacreate-next-appwith Vitest, ESLint/Prettier, Playwright, TypeDoc, a tested sample feature, and static-export or Docker output. -
iru-setup-nestjs-app— scaffolds or updates a NestJS service via the Nest CLI, adding validated config, health checks, an optional ORM with Testcontainers, a Dockerfile, and Sonar. -
iru-setup-angular-web— scaffolds an Angular app viang new, then adds Vitest coverage, ESLint, Prettier, Stylelint, Playwright, Compodoc, and Sonar. -
iru-setup-react-native-app— scaffolds a React Native app for theexpoormetrotoolchain with Jest, ESLint/Prettier, native build profiles, Maestro, and Sonar. -
iru-setup-ionic-app— scaffolds a new Ionic Angular/React app via the Ionic CLI, then adds Vitest, ESLint/Prettier, Playwright, Maestro, and Sonar. -
iru-setup-typescript-github-workflows— scaffolds build/release/sync/security GitHub Actions workflows across all seven flavors. -
iru-setup-typescript-gitignore— creates or refreshes the root.gitignore, diffing before overwrite.
PHP Bootstrap
Scaffolding (or updating) a PHP/Composer repository end to end — a Laravel application, a WordPress plugin or block theme, or a PrestaShop module.
|
|
-
iru-setup-php-repository— orchestrator: bootstraps a Laravel, WordPress plugin/theme, or PrestaShop module repository end to end in one pass. -
iru-setup-php-laravel— creates (or updates) a Laravel app and adds Pest, Pint, Larastan, composer scripts, and optional Sail/Boost/Dockerfile. -
iru-setup-php-wordpress— scaffolds a WordPress plugin (optionally with blocks) or block theme with unit/integration tests, WPCS, PHPStan, and packaging config. -
iru-setup-php-prestashop— scaffolds or updates a PrestaShop 8/9 module with a Symfony config page, tests, PHPStan, and a packaging script. -
iru-setup-php-gitignore— creates or merges the root.gitignorewith Laravel/WordPress/PrestaShop sections, never ignoringcomposer.lock. -
iru-setup-php-github-workflows— build, release, sync, security, and Dependabot workflows (PHP version matrix, Psalm taint analysis, Pages).
Python Bootstrap
Scaffolding (or updating) a Python web repository end to end — a FastAPI service or a Django project.
|
|
-
iru-setup-python-repository— orchestrator: bootstraps a FastAPI or Django repository end to end in one pass. -
iru-setup-python-fastapi— creates (or updates) a FastAPI service with an optional database layer and Alembic, pytest, Ruff/mypy, a Dockerfile, and a tested sample slice. -
iru-setup-python-django— creates (or updates) a Django project with DRF or Django Ninja, pytest-django, Ruff/mypy, a Dockerfile, and a tested sample app. -
iru-setup-python-gitignore— creates or merges the root.gitignorewith FastAPI/Django sections, never ignoring lock files. -
iru-setup-python-github-workflows— build, release (container image to GHCR), sync, security, and Dependabot workflows.
Android Bootstrap
Scaffolding (or updating) an Android/Gradle repository end to end — library or application — matching the house pattern this catalog’s Android skills are genericized from (https://github.com/albertoirurueta/irurueta-android-glutils).
|
|
-
iru-setup-android-repository— orchestrates an Android/Gradle repository’s flavor scaffold, Antora docs, gitignore, CI workflows, changelog, and README. -
iru-setup-android-library— scaffolds a Gradle/Kotlin Android library repository (wrapper, lib module, Compose app sample) from the house template. -
iru-setup-android-app— scaffolds a Gradle Kotlin DSL Android application module with signing, Compose/Views UI, Sonar, and distribution wiring. -
iru-setup-android-github-workflows— scaffolds gitflow/main-only CI/CD and security GitHub Actions workflows for a library or app repo. -
iru-setup-android-gitignore— creates or updates root and per-module.gitignorefiles.
Kotlin Multiplatform Bootstrap
Scaffolding (or updating) a Kotlin Multiplatform mobile app repository end to end — one shared Kotlin module
targeting Android and iOS, with either Compose Multiplatform shared UI (ui: compose) or native UIs (Jetpack
Compose on Android, SwiftUI on iOS) over shared logic (ui: native).
|
|
-
iru-setup-kmp-repository— orchestrator: bootstraps a Kotlin Multiplatform app repository end to end in one pass. -
iru-setup-kmp-app— scaffolds the Gradle build,shared/KMP module,androidApp/, XcodeGeniosApp/, Kover, detekt/ktlint, Dokka, and a tested sample. -
iru-setup-kmp-gitignore— creates or updates the root and per-module.gitignorefiles covering Gradle, Android, Xcode, and signing material. -
iru-setup-kmp-github-workflows— build, release, sync, security, and Dependabot workflows with a Linux Android job and a gated macOS iOS job.
Swift/Apple Bootstrap
Scaffolding (or updating) a Swift repository end to end — a SwiftPM library or a native Apple app — matching this catalog’s conventions from the first commit.
|
|
-
iru-setup-swift-repository— bootstraps a Swift package or Apple app repository end to end: scaffold, docs, gitignore, CI, changelog, README. -
iru-setup-swift-library— scaffolds a SwiftPM library’sPackage.swift, source/test layout, SwiftLint, formatter, DocC, and Sonar config. -
iru-setup-apple-app— scaffolds a native iOS/iPadOS/macOS/watchOS/visionOS app (SwiftUI, or UIKit on iOS/iPadOS; MVVM or MVC): XcodeGen/Tuist manifest, UI-free SwiftPM Core package, per-platform test targets, and Fastlane/Sonar config. -
iru-setup-swift-github-workflows— scaffoldsbuild.yml,release.yml,sync.yml,security.yml, anddependabot.ymlfor the CI/CD pipeline, with one simulator matrix leg per app platform scheme (visionOS reported unverified when the runner lacks its runtime). -
iru-setup-swift-gitignore— creates or refreshes the root.gitignore, showing a diff before overwriting an existing one. -
iru-setup-macos-repository— orchestrator for a native macOS desktop app (SwiftUI or AppKit, MVVM or MVC): scaffold, docs, gitignore, CI, changelog, README; reached viairu-setup-repositoryor standalone. -
iru-setup-macos-app— scaffolds the XcodeGen project, UI-freePackages/Core, Swift Testing/XCUITest targets, entitlements, and the DMG script. -
iru-setup-macos-github-workflows— build, release, sync, security, and Dependabot workflows with a Linux lint job and a cost-gated macOS job. The macOS chain reusesiru-setup-swift-gitignoreinstead of a macOS-specific gitignore skill.
Windows Desktop Bootstrap
Scaffolding (or updating) a Windows desktop app repository on .NET 10 end to end — WPF, WinUI 3, or Windows Forms over a UI-free Core project, with MVVM (WPF/WinUI) or MVC/MVVM (WinForms).
|
|
-
iru-setup-windows-repository— orchestrator: bootstraps a Windows desktop app repository end to end in one pass. -
iru-setup-windows-app— scaffoldsglobal.json, central package management, the UI-free Core, the WPF/WinUI/WinForms app, MSTest tests, DocFX, and MSIX packaging. -
iru-setup-windows-gitignore— creates or updates the root.gitignorecovering .NET output, IDE state, coverage, MSIX output, and signing material. -
iru-setup-windows-github-workflows— build, release, sync, security, and Dependabot workflows with a Linux Core job and a Windows job (FlaUI UI tests, MSIX).
Command-Line Tool Bootstrap
Scaffolding (or updating) a native, agent-friendly command-line tool repository — in Rust, Go, Swift, or C#/.NET —
with a stable exit-code and --json output contract, an optional terminal UI, a generated CLI reference page, and
release binaries plus package channels.
|
|
-
iru-setup-cli-repository— orchestrator: bootstraps a Rust, Go, Swift or .NET command-line tool repository end to end in one pass. -
iru-setup-rust-cli— scaffolds a Cargo workspace with a clap command tree, exit-code/JSON contract, optional Ratatui UI, tests, and anxtaskdocs generator. -
iru-setup-go-cli— scaffolds a Cobra CLI with optional Bubble Tea UI, testscript tests, golangci-lint, GoReleaser, and generated docs. -
iru-setup-swift-cli— scaffolds a SwiftPM package with a thin ArgumentParser executable over a testable Kit library, DocC, and a docs generator. -
iru-setup-dotnet-cli— scaffolds a .NET 10 System.CommandLine tool over a Core contract library, Native AOT, MSTest, DocFX, anddotnet toolpackaging. -
iru-setup-rust-gitignore,iru-setup-go-gitignore,iru-setup-dotnet-gitignore— create or merge the root.gitignorefor each language’s CLI layout (Swift reusesiru-setup-swift-gitignorewithflavor: cli). -
iru-setup-cli-github-workflows— CI, a CLI-contract smoke test, cross-platform release (archives, checksums, attestations, package channels), sync, and the shared security block.
Ticket Intake
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.
|
Reach for one of these when the work doesn’t have a ticket yet. Neither is required — a ticket can always be
filed by hand, or |
-
iru-create-github-issue— drafts and files a GitHub issue viagh issue create, matched against this repository’s actual label set. -
iru-draft-github-issue— interviews the user and writes a detailed, spec-style GitHub issue (functional or documentation), reviews it in a loop, offers a split, and files it after confirmation. -
iru-review-github-issue— reviews an existing issue or a draft against a quality checklist and returns classified findings (gap, pending, inconsistency, doubt) with the question to ask. -
iru-split-github-issue— splits an oversized issue into dependency-ordered sub-issues under a root issue and a milestone, after confirmation. -
iru-create-jira-ticket— drafts and files a Jira ticket via connected Jira MCP tools, resolving the target project and issue type against the real Jira configuration; supports an optional epic assignment and delegates toiru-jira-custom-contextfor organization-specific context. -
iru-jira-custom-context— extension point called byiru-create-jira-ticketto gather whatever organization-specific context (a required custom field, team ownership, customer/account, environment, compliance classification) a given Jira workflow needs, beyond the universal questions the caller already asks. Not useful standalone — it exists to be edited in place and invoked by that caller.
Issue-to-PR Development Cycle
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.
|
This is the group to reach for on a day-to-day basis: picking up a ticket or an ad hoc task and carrying
it through branch creation, research, planning, and implementation without re-explaining that process each
time. |
-
iru-issue— orchestrator: branch, explore, plan, implement, open PR, review — for a tracked ticket. -
iru-explore— read-only research pass over the codebase, optionally grounded in a GitHub issue or Jira ticket, reporting a normalizedProject type:line other skills (likeiru-setup-repository) can key off. -
iru-plan— writes a concrete, reviewableimplementation_plan.md, grouping tasks by dependency and tagging each with the language/framework key a downstream<key>-code-one-task-groupskill should handle it with. -
iru-code— executesimplementation_plan.mdend to end, one task group at a time, viairu-code-one-task-group, and gates completion on quality/security baselines. -
iru-code-one-task-group— implements one task group, resolving each task’s language and dispatching to its matching<key>-code-one-task-groupskill (e.g.iru-java-code-one-task-group,iru-java-springboot-code-one-task-group,iru-kotlin-springboot-code-one-task-group,iru-quarkus-code-one-task-group,iru-php-code-one-task-group,iru-dotnet-code-one-task-group,iru-windows-code-one-task-group,iru-typescript-code-one-task-group,iru-nestjs-code-one-task-group,iru-nextjs-code-one-task-group,iru-fastapi-code-one-task-group,iru-django-code-one-task-group,iru-react-native-code-one-task-group,iru-android-code-one-task-group,iru-kmp-code-one-task-group,iru-swift-code-one-task-group,iru-database-code-one-task-group) — or a best-effort direct implementation if none matches.
Java Development Tooling
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.
|
|
-
iru-java-code-one-task-group— implements a bucket of Java tasks (in parallel where safe) and validates the whole bucket once: license headers, Javadoc, tests, coverage, and a quality regression check. -
iru-java-code-one-task— implements a single task’s code and tests only; called once per task byiru-java-code-one-task-group. It ships its ownreference/library of this catalog’s general Java code agreements —vartype inference andfinalwherever possible (classes and methods included), the public-to-private declaration order every type follows with overloads kept contiguous, immutability and narrow visibility, exception and null conventions, full Javadoc, and JUnit test conventions — read by progressive disclosure so a one-method change doesn’t pay for all of it. The rules are the default for new code: a file that consistently does otherwise wins, and the divergence is reported instead of silently converted. -
iru-java-test— runs the JUnit suite via Maven Surefire or Gradletest(Java or Kotlin sources, incl. Spring Boot and Quarkus), scoped to a class/method/package/tag selector. -
iru-java-coverage— runs JaCoCo (Maven, Gradle, orquarkus-jacoco) or Kover and reports the exact measured coverage percentage for target class(es). -
iru-java-code-quality— runs Checkstyle/PMD/SpotBugs via Maven or Gradle and summarizes every issue found, grouped by tool. -
iru-java-generate-all-tests— finds every class with no test class or under 80% line coverage (viairu-java-coverage) and generates/extends tests until it clears the bar, across the whole codebase in one pass. -
iru-java-javadoc— audits and completes Javadoc coverage for given classes, then verifies it builds cleanly. -
iru-java-bump-version— sets a JVM project’s version to an exact value inpom.xml(single-module or reactor-wide) or the Gradle version location, with optional README/Antora sync; called byiru-releasewhen the detected ecosystem is Java/Kotlin on Maven or Gradle.
Kotlin Development Tooling
The Kotlin-specific point-in-time checks for JVM (non-Android) Kotlin code — static analysis and KDoc — that complement the build-tool-agnostic Java Development Tooling test/coverage skills for Kotlin Spring Boot services, Quarkus services, and plain Kotlin libraries.
|
Reached mostly as gates: the |
-
iru-kotlin-code-quality— runs detekt and ktlint (Gradle, Maven, or Spotless) and reports issues by tool and rule id, optionally diffed against a baseline. -
iru-kotlin-kdoc— audits Kotlin classes/packages for KDoc completeness, fills gaps, wires Dokka module docs, and verifies the Dokka build.
TypeScript Development Tooling
The TypeScript/npm counterpart to Java Development Tooling — implementing a single plan task end to end (routed to the detected framework’s reference file, whether plain TypeScript, React, Angular, React Native, or Ionic), plus the equivalent point-in-time checks (tests, coverage, lint, TSDoc) and a version-bump skill for the release pipeline.
|
Same shape as the Java group, one tool chain over: |
-
iru-typescript-code-one-task-group— implements a bucket of TypeScript tasks (in parallel where safe) and validates the whole bucket once: license headers, TSDoc, tests, coverage, and a quality regression check. -
iru-typescript-code-one-task— implements a single task’s code and tests only, routing to the detected framework’s reference file; called once per task byiru-typescript-code-one-task-group. -
iru-nestjs-code-one-task-group— implements a NestJS bucket and validates it once: unit-only coverage,tscandnest build, and an e2e stage behind a repo-wide lock. -
iru-nestjs-code-one-task— implements a single NestJS task with its unit specs (e2e specs written but not run); called once per task byiru-nestjs-code-one-task-group. -
iru-nextjs-code-one-task-group— implements a Next.js bucket and validates it once, including anext buildroute-table comparison and lock-serialized Playwright e2e. -
iru-nextjs-code-one-task— implements a single Next.js task for the detected version/router/caching profile; called once per task byiru-nextjs-code-one-task-group. -
iru-react-native-code-one-task-group— implements a React Native bucket and validates it once: Jest gates plus native Android/iOS builds, Expo prebuild checks, and lock-serialized e2e. -
iru-react-native-code-one-task— implements a single React Native task for the detectedexpoormetrotoolchain; called once per task byiru-react-native-code-one-task-group. -
iru-typescript-test— runs the unit test suite via Vitest, Jest, orng test, scoped by file, directory, or name pattern. -
iru-typescript-coverage— runs Vitest/Jest/Angular coverage and reports the exact measured line/branch percentages and uncovered line ranges. -
iru-typescript-code-quality— runs ESLint,tsc, Prettier, and Stylelint/Oxlint when configured, reporting every issue by tool and rule id. -
iru-typescript-tsdoc— audits TypeScript files for TSDoc completeness, fills gaps, and verifies the build with TypeDoc or Compodoc. -
iru-typescript-generate-all-tests— finds every file with no tests or under 80% coverage (viairu-typescript-coverage) and generates/extends tests until it clears the bar, across the whole codebase in one pass. -
iru-typescript-bump-version— sets an npm/TypeScript project’s version to an exact value acrosspackage.jsonand its lockfile; called byiru-releasewhen the detected ecosystem is TypeScript/npm. -
iru-react-native-bump-version— sets a React Native app’s version for theexpoormetrotoolchain, including native build numbers where the repository owns them; called byiru-releasefor React Native apps.
Android Development Tooling
The Android/Kotlin counterpart to Java Development Tooling — implementing a single plan task end to end against the detected lib/app module, plus the equivalent point-in-time checks (tests, coverage, lint/Detekt/ktlint, KDoc/Dokka) and a version-bump skill for the release pipeline.
|
Same shape as the Java group, one tool chain over: |
-
iru-android-code-one-task-group— implements a bucket of Android/Kotlin tasks (in parallel where safe) and validates the whole bucket once per module: license headers, KDoc, tests, coverage, and a quality regression check. -
iru-android-code-one-task— implements a single task’s code and tests only, detecting the lib/app module and applying the bundled Kotlin conventions; called once per task byiru-android-code-one-task-group. -
iru-android-test— runs the JUnit 4 unit test suite via AGP’stestDebugUnitTest, scoped by class/method/pattern/module. -
iru-android-coverage— detects and runs a module’s wired coverage path (Kover, AGP, or vendored JaCoCo CLI) and reports the exact measured percentage. -
iru-android-code-quality— runs Android Lint, Detekt, and ktlint on a module and reports every static-analysis issue by tool. -
iru-android-dokka— audits Kotlin classes/packages for KDoc completeness, generates missing KDoc, and verifies the Dokka build. -
iru-android-generate-all-tests— finds every class with no tests or under 80% coverage (viairu-android-coverage) and generates/extends tests per class until it clears the bar, across the whole module in one pass. -
iru-android-bump-version— sets an Android/Gradle project’s version across lib/appbuild.gradle.ktsand optionally README/Antora mentions; called byiru-releasewhen the detected ecosystem is Android/Gradle.
Kotlin Multiplatform Development Tooling
The Kotlin Multiplatform (Android + iOS) counterpart to Android Development
Tooling — implementing a single plan task across the shared module’s commonMain/androidMain/iosMain source
sets, the Android app, and the iOS host app, plus the per-target checks (tests, Kover coverage, detekt/ktlint/
Android Lint/SwiftLint, KDoc/Dokka) and a version-bump skill that keeps Android and iOS versions in step.
|
Same shape as the Android group: |
-
iru-kmp-code-one-task-group— implements a bucket of KMP tasks and validates it once: license headers, KDoc, Android/JVM tests, Kover coverage, quality, and the iOS stage. -
iru-kmp-code-one-task— implements a single task’s code and tests across the detected source sets; called once per task byiru-kmp-code-one-task-group. -
iru-kmp-test— runs tests per target: Android host/JVM, Kotlin/Native iOS simulator, and the iOS app’s XCTest bundle. -
iru-kmp-coverage— reports Kover line/branch coverage for the JVM/Android targets (iOS coverage is reported as not measurable). -
iru-kmp-code-quality— runs detekt, ktlint, Android Lint, and SwiftLint across every KMP module and reports issues by rule id. -
iru-kmp-dokka— audits KDoc across every source set (anexpectcarries the KDoc its `actual`s inherit) and verifies the Dokka multiplatform build. -
iru-kmp-generate-all-tests— finds every class with no tests or under 80% coverage (viairu-kmp-coverage) and generates/extends tests until it clears the bar. -
iru-kmp-bump-version— setsVERSION_NAME/VERSION_CODEingradle.propertiesand, for releases, the iOSConfig.xcconfigversions; called byiru-release.
Swift Development Tooling
The Swift/Apple counterpart to Java Development Tooling — implementing a single plan task end to end against the detected package-vs-app shape and target, plus the equivalent point-in-time checks (tests, coverage, lint, DocC) and a version-bump skill for the release pipeline.
|
Same shape as the Java group, one tool chain over: |
-
iru-swift-code-one-task-group— implements a bucket of Swift tasks and validates the whole bucket once: license headers, DocC, tests, coverage, and a quality regression check, with simulator-lock serialization. -
iru-swift-code-one-task— implements a single task’s code and tests only, detecting package-vs-app shape, target, platform (macOS/iOS-iPadOS/visionOS), UI framework (SwiftUI/UIKit/AppKit) and MVVM-vs-MVC architecture; called once per task byiru-swift-code-one-task-group. -
iru-swift-test— runs the test suite viaswift test --filter(package) orxcodebuild -only-testing(app), scoped to a selector. -
iru-swift-coverage— reports the exact measured line/function coverage viallvm-cov(SwiftPM) orxccov(Xcode); branch coverage is not available. -
iru-swift-code-quality— runs SwiftLint, the wired Swift formatter, and Periphery, and reports issues grouped by tool and rule id. -
iru-swift-docc— audits Swift declarations and DocC catalogs for missing documentation, generates it, and verifies the doc build. -
iru-swift-generate-all-tests— finds every type with no tests or under 80% coverage (viairu-swift-coverage) and generates/extends Swift Testing/XCTest tests per type, across the whole codebase in one pass. -
iru-swift-bump-version— sets a SwiftPM library’sversion.txt/CHANGELOG/README or an Apple app’sMARKETING_VERSION/CURRENT_PROJECT_VERSION; called byiru-releasewhen the detected ecosystem is Swift/Apple.
Spring Boot Development Tooling
The java-springboot and kotlin-springboot language/framework backends for the iru-code pipeline — the pairs of
skills that implement plan tasks in a DDD/hexagonal Spring Boot service (in Java or Kotlin), 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.
|
This group pairs with Spring Boot Service Bootstrap: that group creates the service, this one implements work in it. Both assume the same module layout, and the split of responsibility between the two skills here exists for one concrete reason — integration tests run once per task group, never once per task, because a task-level run would start the same Testcontainers stack repeatedly. You rarely invoke either directly; the Issue-to-PR Development Cycle reaches them
through |
-
iru-java-springboot-code-one-task-group— implements a bucket of Spring Boot tasks (in parallel where safe) and validates the whole bucket once, reusing the same language-level skills as the plain-Java group skill (iru-java-test,iru-java-coverage,iru-java-code-quality,iru-java-javadoc). It owns the two stages the per-task skill deliberately omits: the module-boundary checks (maven-enforcer-pluginbanned-dependencies plus the ArchUnit test, run early because they fail in seconds) and the Testcontainers-backed integration tests (run last, because they cost minutes). Its 80% coverage gate is measured from unit tests alone — integration tests raise the aggregate afterwards and that delta is reported, but it never satisfies the gate, so the coverage verdict holds even on a machine with no Docker. -
iru-java-springboot-code-one-task— implements a single task’s code and unit tests only, resolving which hexagonal module the code belongs in before writing anything. Likeiru-java-code-one-taskit ships its ownreference/library, here covering the architecture rather than the language — hexagonal architecture and module boundaries, DDD tactical patterns, SOLID, the distributed patterns (CQRS, transactional outbox, saga, eventual consistency, listen-to-yourself), and this catalog’s Java code style — read by progressive disclosure so a small task doesn’t pay for all of it. -
iru-kotlin-springboot-code-one-task-group— thekotlin-springbootcounterpart of the group skill above, on Maven or Gradle: gates withiru-kotlin-code-quality/iru-kotlin-kdoc(plus the Java gates for any Java sources), keeps the unit-only 80% coverage gate, and runs the Testcontainers integration stage behind the repo-wide.integration-test.lock. -
iru-kotlin-springboot-code-one-task— implements a single Kotlin Spring Boot task with unit tests only, first verifying the Kotlin/Spring build plumbing (all-open/no-arg). -
iru-java-springboot-performance-tests— generates an Apache JMeter suite underperformance/covering only the happy paths of the service’s main use cases, in three scenarios (low flat concurrency, high flat concurrency, and a symmetric scale-up/scale-down ramp). Unlike the two skills above it is never reached throughiru-code: it is run by a person, after real endpoints exist, and it deliberately sits outside the Maven reactor somvn verifynever triggers a load test.
Quarkus Development Tooling
The quarkus language/framework backend for the iru-code pipeline — implementing plan tasks in a Quarkus
service (Java or Kotlin, Maven or Gradle), created by Quarkus Service
Bootstrap.
|
|
-
iru-quarkus-code-one-task-group— implements a Quarkus bucket and validates it once, with unit-stage coverage and a lock-serialized Dev Services stage. -
iru-quarkus-code-one-task— implements a single Quarkus task (CDI/Panache/REST rules from its ownreference/library), running only container-free test levels.
PHP Development Tooling
The PHP/Composer counterpart to Java Development Tooling — implementing plan tasks in a Laravel app, WordPress plugin/theme, PrestaShop module, or plain Composer library, plus the point-in-time checks (tests, coverage, static analysis/style, PHPDoc) and a version-bump skill for the release pipeline.
|
Same shape as the Java group, one tool chain over: |
-
iru-php-code-one-task-group— implements a PHP bucket and validates it once: license headers, PHPDoc, fast tests, coverage, a quality diff, and a locked integration run. -
iru-php-code-one-task— detects the PHP flavor and implements a single task with its fast tests; called once per task byiru-php-code-one-task-group. -
iru-php-test— runs Pest, PHPUnit, or artisan tests on the host, Sail, ddev, or wp-env and reports a JUnit-based summary. -
iru-php-coverage— measures coverage with PCOV or Xdebug and reports exact per-class percentages from Clover XML. -
iru-php-code-quality— runs PHPStan/Psalm, Pint/PHP-CS-Fixer/PHPCS, and Rector as wired, reporting issues by tool and rule id. -
iru-php-phpdoc— audits and fills PHPDoc per flavor conventions, verifying with PHPStan/phpcs and phpDocumentor. -
iru-php-bump-version— sets a PHP project’s version in every Laravel/WordPress/PrestaShop location; called byiru-releasewhen the detected ecosystem is PHP.
Python Development Tooling
The Python counterpart to Java Development Tooling — implementing plan tasks in a FastAPI service or a Django project, plus the point-in-time checks (pytest, coverage.py, Ruff/mypy/Bandit, docstrings/Sphinx) and a version-bump skill for the release pipeline.
|
Same shape as the Java group, one tool chain over: |
-
iru-fastapi-code-one-task-group— implements a FastAPI bucket and validates it once: license headers, docstrings, fast tests, coverage, a quality diff, and a locked integration run. -
iru-fastapi-code-one-task— implements a single FastAPI task with its fast tests; called once per task byiru-fastapi-code-one-task-group. -
iru-django-code-one-task-group— the same bucket-level validation for Django, addingmanage.py checkand a migrations-are-current check. -
iru-django-code-one-task— implements a single Django task with its fast tests; called once per task byiru-django-code-one-task-group. -
iru-python-test— runs pytest (incl. pytest-django) through the project’s runner (uv, Poetry, PDM, or a venv) and reports a JUnit-based summary. -
iru-python-coverage— measures coverage with coverage.py and reports exact per-module line/branch percentages from Cobertura XML. -
iru-python-code-quality— runs Ruff, mypy/Pyright, Bandit, and framework-specific linters as wired, reporting issues by tool and rule code. -
iru-python-docstrings— audits and fills docstrings in the project’s style, verifying with Ruff and a Sphinx build. -
iru-python-bump-version— sets a Python project’s version; called byiru-releasewhen the detected ecosystem is Python.
.NET Development Tooling
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.
|
Same shape as the Java group, one tool chain over: |
-
iru-dotnet-code-one-task-group— implements a bucket of .NET tasks (in parallel where safe) and validates the whole bucket once: license headers, XML doc comments, tests, coverage, and a quality regression check. -
iru-dotnet-code-one-task— implements a single task’s code and tests only; called once per task byiru-dotnet-code-one-task-group. -
iru-dotnet-test— runs the test suite viadotnet test, scoped to a class/method/namespace/trait selector. -
iru-dotnet-coverage— runs Coverlet viadotnet testand reports the exact measured coverage percentage for target class(es). -
iru-dotnet-code-quality— runs StyleCop.Analyzers/CA Roslyn analyzers via a SARIF-logged build and summarizes every issue found. -
iru-dotnet-docfx— audits and completes XML doc-comment coverage for given types, then attempts a DocFX build. -
iru-dotnet-generate-all-tests— finds every class with no test class or under 80% line coverage (viairu-dotnet-coverage) and generates/extends tests until it clears the bar, across the whole codebase in one pass. -
iru-dotnet-bump-version— sets a .NET project’s version inDirectory.Build.props/*.csprojand the MSIX package identity; called byiru-releasewhen the detected ecosystem is .NET. -
iru-windows-code-one-task-group— the Windows desktop (WPF, WinUI 3, Windows Forms) variant of the group skill: dispatched for buckets taggedwindows, it detects the UI stack and MVVM/MVC shape once, runsiru-windows-code-one-taskper task, and validates the bucket once through theiru-dotnet-*gates andiru-check-license. -
iru-windows-code-one-task— implements a single Windows desktop task’s code and tests; called once per task byiru-windows-code-one-task-group.
Rust Development Tooling
The Rust counterpart to Java Development Tooling — implementing plan tasks in any Cargo crate or workspace
(a library, a service, or a command-line tool scaffolded by iru-setup-rust-cli),
plus the point-in-time checks (cargo-nextest/cargo test, cargo-llvm-cov, Clippy/rustfmt/cargo-deny, rustdoc) and a version-bump skill for the release pipeline.
|
Same shape as the Java group: |
-
iru-rust-code-one-task-group— implements a Rust bucket and validates it once: license headers, rustdoc, tests, 80% coverage, and a Clippy quality diff. -
iru-rust-code-one-task— implements a single Rust task with its tests, then rustfmt +cargo check; called once per task by the group skill. -
iru-rust-test— runs tests via cargo-nextest orcargo test, plus doctests and `#[ignore]`d container tests, reporting a compact summary. -
iru-rust-coverage— measures line/region coverage with cargo-llvm-cov and reports uncovered ranges per target. -
iru-rust-code-quality— runs Clippy, rustfmt and cargo-deny, reporting issues by tool and lint id with an optional baseline diff. -
iru-rust-rustdoc— audits public items for complete rustdoc, fills gaps, and verifies with doc lints,cargo docand doctests. -
iru-rust-bump-version— sets a crate/workspace version acrossCargo.toml, path dependencies andCargo.lock; called byiru-release.
Go Development Tooling
The Go counterpart to Java Development Tooling — implementing plan tasks in any Go module
(a library, a service, or a command-line tool scaffolded by iru-setup-go-cli),
plus the point-in-time checks (go test -json with -race, coverprofile statement coverage, golangci-lint/go vet/govulncheck, doc comments) and a version-bump skill for the release pipeline.
|
Same shape as the Java group: |
-
iru-go-code-one-task-group— implements a Go bucket and validates it once: license headers, doc comments, tests, 80% coverage,-race, and a quality diff. -
iru-go-code-one-task— implements a single Go task with its tests, thengo build/go vet; called once per task by the group skill. -
iru-go-test— runsgo test -json(race, testscript,integrationbuild tag) and reports a compact pass/fail summary. -
iru-go-coverage— measures statement coverage via-coverpkgand a profile parser, reporting per-file gaps against a bar. -
iru-go-code-quality— runs golangci-lint v2, go vet, gofmt and govulncheck, reporting issues by tool and rule id with a baseline diff. -
iru-go-godoc— audits packages for complete doc comments, fills gaps from the code, and verifies with revive/godot/go doc. -
iru-go-bump-version— sets a module’s in-treeVersionliteral and verifies-ldflags -Xoverrides point at it; called byiru-release.
Database Development Tooling
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.
|
|
-
iru-database-code-one-task-group— implements a bucket of database tasks sequentially, one at a time, then checks off completed tasks and notifies the user — no quality baseline or bucket-wide validation pass. -
iru-database-code-one-task— generates the queries a single task calls for, executes the read-only ones via a connected database MCP if one exists, and records both indatabase-report.md; called once per task byiru-database-code-one-task-group.
Pull Request Lifecycle
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).
|
Used automatically as the last leg of |
-
iru-pr-description— drafts a PR description from the real diff, and optionally opens/updates the pull request. -
iru-pr-review— reviews an open pull request against the linked ticket’s intent and this codebase’s conventions.
Repository Maintenance
Keeping an already-bootstrapped repository correct and current, well after its initial setup.
|
Intended for whoever maintains the repository over time rather than someone mid-feature: cutting releases, keeping docs from drifting after unrelated code changes, periodically verifying license headers, and scanning for accidentally committed secrets. |
-
iru-release— cuts a release branch, bumps versions via the ecosystem’siru-<key>-bump-versionskill (Java/Kotlin, TypeScript, Android, Swift, PHP, Python), drafts release notes/changelog, and opens the release PR. -
iru-update-docs— brings the Antora documentation module up to date with changes already made to the code. -
iru-build-docs— builds the existing Antora documentation site as-is (no content edits), scaffolding it first viairu-setup-antoraif it doesn’t exist yet. -
iru-check-license— verifies (and backfills) license headers against the repository’s actual license. -
iru-check-security— scans for accidentally committed secrets viadetect-secrets, maintaining a.secrets.baselineso repeat runs surface only what’s new.
Knowledge Base Management
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.
|
Reach for this group in a repository used to track meetings and decisions rather than just code.
|
-
iru-knowledge-setup— creates theknowledge/directory and its five subdirectories (inbox,meetings,people,agreements,pending), each seeded with a.gitkeep. -
iru-knowledge-process-inbox— files every transcription/document inknowledge/inboxinto a per-meeting summary, updated people profiles, and tracked agreements/pending tasks. -
iru-knowledge-briefing— read-only: searchesknowledge/people/meetings/agreements/pendingfor a given subject (optionally scoped by person or meeting) and reports back a summary — no file inknowledge/is edited. -
iru-knowledge-complete— checks off a completed agreement item and removes its pending file, given the task’s id. -
iru-knowledge-compact— only ever reduces the base: collapses duplicate pending tasks across meetings (keeping the one that already carries a tracker issue), closes out agreements whose GitHub issue/Jira ticket reads as completed, and repairs drift betweenknowledge/pendingandknowledge/agreements— always after confirming the full plan. -
iru-knowledge-to-issue— resolves a pending/not-completed agreement, gathers its meeting and codebase context, then hands it toiru-create-github-issueto draft and file a GitHub issue for it. -
iru-knowledge-to-jira— the Jira counterpart: resolves a pending/not-completed agreement, gathers its meeting and codebase context, then hands it toiru-create-jira-ticketto draft and file a Jira ticket for it.
Catalog Tooling
Maintaining this catalog’s own documentation rather than a consumer repository’s.
|
Only relevant if you’re working in this |
-
iru-generate-skill-docs— regenerates this documentation site itself from the current set of skills and agents on disk.
Sub-Agent Infrastructure
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.
|
Not something invoked directly the way a skill is — an agent is only ever reached indirectly, through a
skill’s own instructions naming it in an |
-
iru-gate-runner— runs a single verification/quality-gate skill and reports back only a compact summary, optionally diffed against a baseline. Used throughoutiru-code,iru-code-one-task-group, and every<key>-code-one-task-groupskill (Java, Spring Boot in Java or Kotlin, Quarkus, PHP, FastAPI, Django, .NET, TypeScript, NestJS, Next.js, React Native, Android, Kotlin Multiplatform, Swift), plus thegenerate-all-testsskills for every language and several bootstrap skills (verifying a scaffold or generated workflow actually builds). -
iru-isolated-skill-executor— runs one named skill end to end in a fresh context so the caller can keep running afterward. Used byiru-issueto delegate the entireiru-coderun for a ticket, byiru-codeitself to delegate each task group toiru-code-one-task-group, by every parallelizable<key>-code-one-task-groupskill to delegate each task in a bucket to its matching<key>-code-one-taskskill, and byiru-setup-repositoryand every stack orchestrator (iru-setup-java-library-repository,iru-setup-java-springboot,iru-setup-quarkus-repository,iru-setup-typescript-repository,iru-setup-php-repository,iru-setup-python-repository,iru-setup-android-repository,iru-setup-kmp-repository,iru-setup-swift-repository,iru-setup-macos-repository,iru-setup-windows-repository) to delegate each of the bootstrap skills it orchestrates. -
iru-change-summarizer— fans out over a git commit/tag range and returns only the user-facing changes. Used byiru-setup-changelogto summarize one release at a time when backfilling a long tag history, and byiru-releaseto summarize the single range since the previous release.
Dependency graph
An unlabeled edge means "invokes": a solid line when the caller runs the target directly via the Skill tool, a
dotted line when it runs the target inside a sub-agent (iru-gate-runner, iru-isolated-skill-executor, or
general-purpose). A dotted line labeled "spawns"/"uses" points at the agent type itself, via the Agent tool. code-review is an external skill this catalog does not define — iru-pr-review uses it only when it
happens to be available in the current session.
Common workflows
These sections walk through how the catalog’s skills compose for a few recurring jobs. Each is a real,
supported path through the graph above — not every skill in the catalog appears in one, since some
(the Java and .NET Development Tooling skills,
iru-check-license) are more often invoked as building blocks of a larger flow than run standalone by a person.
Setting up a new repository
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:
Before asking anything else it announces whether it is setting the repository up from scratch or updating an
existing one, with an inventory of every component it found. Each sub-skill then warns about any file it would
write that already exists and asks Update / Keep as is / Replace, explaining what each one costs you. The
orchestrator also asks the repository’s visibility, whether GitHub workflows are wanted at all (with ci: no the
iru-setup-java-github-workflows step is skipped entirely), whether CI runs unit tests only or the full suite, and
whether docs deploy to GitHub Pages — recommending the cheaper options for private repositories.
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).
The same six-step shape is shared by the other *-repository orchestrators — only the scaffold, gitignore, and
workflows skills change per stack:
iru-setup-repository is the usual way in: it detects a non-empty repository’s type via iru-explore (or asks
over up to six rounds — JVM services & libraries, Web & Node, PHP, Python, Mobile & Apple, Desktop & command line), collects the shared,
cost-aware inputs once, and delegates to exactly one orchestrator via iru-isolated-skill-executor, forwarding
mode: existing when the repository already has content. For a project type with a user interface it also asks
the shared accessibility input ("Support accessibility and assistive technologies?": enforce/report/off/none, or none to opt out; pre-selected from iru-explore’s `Accessibility: line on an existing repository), which the UI scaffold records in .ui-quality.yml
alongside a .ui-screenshots/ capture helper — see Building a user interface.
Setting up a command-line tool
iru-setup-cli-repository bootstraps a native, agent-friendly CLI — the twelfth *-repository orchestrator. It
asks the language once (and, for Rust/Go/.NET, whether a terminal UI is wanted), then runs the same six steps as
every other stack, each in its own iru-isolated-skill-executor context:
Decision points: the language (rust/go/swift/dotnet), ui: none|tui (forced to none for Swift), branching
(gitflow or main-only), mode: new|existing, and ci — ci: no skips the workflows step and its security block.
The orchestrator stops when the repository holds several competing manifests or isn’t a command-line tool. From
then on, planned work flows through the usual cycle below: iru-plan tags tasks rust, go, swift or dotnet,
and iru-code-one-task-group dispatches them to iru-rust-code-one-task-group, iru-go-code-one-task-group,
iru-swift-code-one-task-group or iru-dotnet-code-one-task-group, which detect the CLI shape and keep the
exit-code/--json contract and the generated CLI reference in sync. iru-release bumps the version through
iru-rust-bump-version / iru-go-bump-version / iru-swift-bump-version / iru-dotnet-bump-version.
Setting up a new Spring Boot service
iru-setup-java-springboot is the service-shaped counterpart to the flow above. It interviews the user once —
project identity, language (Java on Maven, or Kotlin on Maven or Gradle Kotlin DSL), 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. With ci: no the workflows sub-skill is skipped, so there are no
build, deploy, or undeploy workflows — deployment is then a manual tofu apply. On a repository that already has
some of this in place, the run announces an update, and each sub-skill asks Update / Keep as is / Replace for
every file it owns that already exists; only a genuinely incompatible repository (e.g. a Gradle build) gets a
hard stop.
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.
Filing a ticket before work begins
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.
For a detailed, spec-style issue use /iru-draft-github-issue, which interviews the user, reviews the draft in a loop
with iru-review-github-issue and offers iru-split-github-issue when the issue is too large.
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.
Typical development cycle, starting from a ticket
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-<key>-code-one-task-group skill matches (Java, Spring Boot in Java or Kotlin, Quarkus, PHP, FastAPI,
Django, .NET, TypeScript, NestJS, Next.js, Android, or Swift — e.g.
iru-java-code-one-task-group) — 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
(the plan key’s own iru-<key>-code-quality skill — Java, Kotlin, PHP, Python, .NET, TypeScript, Android, or Swift) 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.
Generating a release
iru-release must be run from develop, is ecosystem-agnostic (Java/Kotlin on Maven or Gradle, TypeScript/npm,
React Native (Expo or Metro), Android/Gradle, Kotlin Multiplatform, Swift/Apple, .NET (incl. Windows desktop apps), PHP/Composer, or
Python/FastAPI/Django), and delegates the actual version-file edit to that ecosystem’s own installed
iru-java-bump-version/iru-typescript-bump-version/
iru-react-native-bump-version/
iru-android-bump-version/iru-kmp-bump-version/
iru-swift-bump-version/iru-dotnet-bump-version/
iru-php-bump-version/iru-python-bump-version
skill (called with sync-files: yes, which folds in refreshing README.md/docs/antora.yml/Antora dependency
snippets), keeping only the release notes and PR description as its own work. See
guides/common-workflows.adoc#generating-a-release for a more detailed walkthrough.
Updating an existing repository with new functionality
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.
Building a user interface
Every stack with a user interface (web, mobile, desktop and terminal UIs) follows one catalog-wide UI contract, described in Building user interfaces. It runs through the ordinary development cycle above rather than a separate orchestrator:
-
Bootstrap:
iru-setup-repositoryand the stack orchestrators ask the sharedaccessibilityinput (enforce/report/off/none, UI project types only); the UI scaffold records it in.ui-quality.yml, wires a screenshot helper writing to.ui-screenshots/(gitignored by the matching-gitignoreskill), andiru-setup-antoraadds the User interface section described in itsreference/ui-docs.md. -
Planning:
iru-plandecomposes the design top-down (screen › region › component, reusing existing components; long collections become a virtualized container plus a reusable item component), emits one task per component or screen with its own UI tests, groups leaves first and composites after, and ends with an/iru-update-docstask. -
Coding: each UI coding skill (
iru-<key>-code-one-task) follows itsreference/ui-contract.mdandreference/ui-implementation.md; its group skill runs the stack’s test gate with theuiselector, and the*-generate-all-testsskills back-fill UI tests for existing screens and components. -
Documentation:
iru-update-docs(andiru-update-java-springboot-documentationfor Spring Boot/Hilla) turns the captured screenshots into navigation-flow, screen and component pages underimages/ui/, replacing images of changed components and discarding unused ones.
Managing a knowledge base of meetings
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:
Keeping this documentation current
|
This documentation site can be created or updated in two ways:
|
This page and every detail page under Catalog Tooling are themselves
generated — by iru-generate-skill-docs, from whatever skills/agents actually exist under
.claude/skills/ (and .claude/agents/, if any) at the time it runs:
Re-run it (/iru-generate-skill-docs) after adding, removing, or materially changing a skill or
agent, so this page and the detail pages it links to don’t drift from what’s actually on disk.
Each skill’s own detail page (linked from the table above) covers its exact inputs, outputs, and execution
flow. Each skill is also self-contained under its own .claude/skills/<name>/SKILL.md — copy the ones you
need into another repository’s .claude/skills/ directory to adopt them there.