Gate Runner

This documentation was generated with the assistance of AI. Please report any inaccuracies.

A custom agent that runs a single verification/quality-gate skill — tests, coverage, code-quality/lint, license headers, doc-comment audits, UI test runs, security scans, or a full project build — across any of the catalog’s language tracks (Java and Kotlin on Maven or Gradle, Spring Boot, Quarkus, PHP, .NET, TypeScript including NestJS and Next.js, Python including FastAPI and Django, Android, Kotlin Multiplatform, React Native, Swift, Windows desktop apps, Rust, Go), in an isolated context, optionally diffs the result against a baseline, and reports back only a compact, structured summary.

Purpose

iru-gate-runner exists to collapse a pattern that used to be hand-written, nearly identically, at more than a dozen call sites across iru-code, iru-code-one-task-group, and every <key>-code-one-task-group skill (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-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-android-code-one-task-group, iru-kmp-code-one-task-group, iru-react-native-code-one-task-group, iru-windows-code-one-task-group, iru-rust-code-one-task-group, iru-go-code-one-task-group, iru-swift-code-one-task-group): invoke a verification skill, diff it against a baseline if one is given, and return only the distilled outcome — never the raw Surefire/JaCoCo/lcov/clover.xml/xccov/SARIF/checkstyle-result.xml/pmd.xml/spotbugsXml.xml/eslint/detekt/ktlint/ phpstan/psalm/phpcs/swiftlint/detect-secrets output or a full build log. Centralizing the "report back only X, not the full report" convention in one agent definition means it only has to be stated — and changed, if it ever needs to be — once.

It always prefers invoking the matching Claude Code skill over a raw command:

Tests — iru-java-test (Maven or Gradle, Java or Kotlin sources), iru-dotnet-test (incl. Windows desktop solutions — WPF/WinUI/WinForms — with a ui selector for FlaUI desktop UI tests on Windows), iru-typescript-test, iru-php-test (Pest/PHPUnit), iru-python-test (pytest, incl. pytest-django), iru-android-test, iru-kmp-test (Kotlin Multiplatform — Android host/JVM tests, plus Kotlin/Native iOS tests and the iOS host app’s XCTest on macOS), iru-swift-test, iru-rust-test (cargo-nextest or cargo test, doctests, #[ignore]`d container tests), `iru-go-test (go test -json, -race, integration build tag).
Coverage — iru-java-coverage (JaCoCo from Maven or Gradle, quarkus-jacoco, or Kover), iru-dotnet-coverage, iru-typescript-coverage (lcov line/branch %), iru-php-coverage (PHPUnit/Pest Clover XML line %; branch coverage reported as unavailable rather than invented), iru-python-coverage (coverage.py Cobertura XML line/branch %), iru-android-coverage (JaCoCo XML line/branch %), iru-kmp-coverage (Kover XML line/branch %; JVM/Android targets only — iOS reported as not measurable), iru-swift-coverage (llvm-cov/xccov %), iru-rust-coverage (cargo-llvm-cov line/region %), iru-go-coverage (coverprofile statement %; Go has no branch coverage).
Code quality/lint — iru-java-code-quality (Checkstyle/PMD/SpotBugs), iru-dotnet-code-quality (StyleCop/CA rules), iru-kotlin-code-quality (detekt/ktlint), iru-typescript-code-quality (ESLint/Biome/oxlint), iru-php-code-quality (PHPStan/Psalm error identifiers, PHPCS/Pint/PHP-CS-Fixer sniffs and rules), iru-python-code-quality (Ruff rule codes, mypy error codes, Bandit test ids), iru-android-code-quality (Detekt/ktlint/Android Lint), iru-kmp-code-quality (detekt/ktlint/Android Lint/SwiftLint across KMP modules), iru-swift-code-quality (SwiftLint), iru-rust-code-quality (clippy lint ids, rustfmt, cargo-deny), iru-go-code-quality (golangci-lint <linter>:<rule> ids, go vet, govulncheck) — all keyed by the tool’s own stable rule id so a baseline diff matches on rule plus file, not on message text or shifting line numbers.
Doc-comment audits — iru-java-javadoc, iru-kotlin-kdoc (KDoc/Dokka), iru-dotnet-docfx, iru-typescript-tsdoc, iru-php-phpdoc, iru-python-docstrings (docstrings + Sphinx), iru-android-dokka, iru-kmp-dokka (KDoc + Dokka multiplatform), iru-swift-docc, iru-rust-rustdoc (rustdoc + doctests), iru-go-godoc (Go doc comments).
UI test runs — the ui/e2e selector of the test gates (iru-android-test, iru-dotnet-test, iru-typescript-test, iru-swift-test, …) that runs component, screen and flow tests capturing .ui-screenshots/ across states, left-to-right/right-to-left and light/dark, with accessibility checks applied at the level set in .ui-quality.yml. See Building user interfaces.
iru-check-license, iru-check-security, and full project builds (Maven, Gradle, npm, Composer, uv, Cargo, Go, …).

It falls back to the equivalent raw command (mvn test -Dtest=X, ./gradlew test --tests X, dotnet test --filter, vendor/bin/phpunit --filter X, uv run pytest tests/test_x.py, …) only when the prompt says the matching skill is unavailable or none exists in the repository. If an invoked skill needs a decision only a person can make (for example `iru-check-license’s header convention or `iru-check-security’s audit labeling), the agent lets that skill surface its own question and relays the user’s choice in its report, and it never modifies files beyond what the invoked skill does itself.

What it reports is exactly what the prompt asks for: for runs and builds, only pass or the failing names with their reasons; for coverage, only the requested percentages; for quality/security scans, a per-tool issue count and the per-file list (or only the newly introduced issues when a baseline was supplied); for license and doc audits, which files were missing, fixed or compliant; for UI test runs, pass/fail plus the screenshot count per kind (component/screen/flow), any malformed screenshot file name, any screen or component missing a state × direction × theme capture, the accessibility level applied and the violation count by rule id (never the images or the raw accessibility report), and every UI stage that could not run (no browser, device, simulator or host OS) reported as unverified with its reason.

When .ui-quality.yml says accessibility: none (opted out entirely) or off (rules apply, checks not run), accessibility checks are not applicable: it skips them and reports "accessibility: opted out" (none) or "accessibility checks off" (off) — never "unverified" and never a failure.

Plugin

Shipped by the iru-core plugin of the ai-catalog marketplace (install with /plugin install iru-core@ai-catalog; see Plugins).

Tools

Skill, Bash, Read — enough to invoke a skill (or fall back to a raw command) and read whatever report file it produces; no Edit/Write access, since this agent only runs and reports, it never modifies files itself.

The agent is pinned to model: haiku. Callers dispatch it as subagent_type: "iru-gate-runner" when it is installed under .claude/agents/, or as "iru-core:iru-gate-runner" when it is installed through the iru-core plugin (use whichever name appears in the available agent types).

Used by

Code — Step 3, 7, baselines, final comparisons and full build verification.
Code One Task Group — Step 3, license, doc, test, coverage and quality checks in the fallback path.
Java Code One Task Group and .NET Code One Task Group — every delegated check while validating one task group’s bucket: pre-change quality baseline, license headers, Javadoc/XML doc comments, scoped test run, coverage check, full test suite, and the post-change quality diff — all run once per bucket rather than once per task.
Java Spring Boot Code One Task Group — every check in its baseline and bucket-validation passes: the quality baseline and its later regression diff, license headers, Javadoc, the module-boundary checks (maven-enforcer-plugin plus the ArchUnit test), scoped unit tests, coverage read from the JaCoCo aggregate, the reactor-wide unit suite, and — the clearest case for this agent anywhere in the catalog — the Testcontainers-backed integration run, where a multi-container Failsafe log is enormous and all the caller needs back is a pass/fail plus whether a failure was an assertion or an environment problem.
TypeScript Code One Task Group, Android Code One Task Group, and Swift Code One Task Group — the same per-bucket pattern as the Java/.NET one-task-groups: a pre-change quality baseline and its later regression diff (iru-typescript-code-quality/ iru-android-code-quality/iru-swift-code-quality), license headers, the doc-comment audit (iru-typescript-tsdoc/iru-android-dokka/iru-swift-docc), the scoped test run (iru-typescript-test/iru-android-test/iru-swift-test), the coverage check (iru-typescript-coverage/iru-android-coverage/iru-swift-coverage), and the full test suite — all run once per bucket rather than once per task.
KMP Code One Task Group — Steps 1 and 3, the same per-bucket pattern for Kotlin Multiplatform: a pre-change quality baseline and its later diff (KMP Code Quality), license headers, the KDoc/Dokka audit (KMP Dokka), scoped and full Android/JVM tests and the Kotlin/Native iOS and iosApp XCTest runs (KMP Test), and the Kover coverage check (KMP Coverage).
Windows Code One Task Group — the same per-bucket pattern for Windows desktop apps (WPF, WinUI 3, Windows Forms): baseline and quality diff (iru-dotnet-code-quality), license headers, XML docs (iru-dotnet-docfx), scoped and full tests (iru-dotnet-test, including the lock-serialized ui selector on Windows), and the Core-project coverage check (iru-dotnet-coverage).
React Native Code One Task Group — Steps 1 and 3, the same per-bucket pattern for React Native (Expo or Metro): baseline and quality diff (iru-typescript-code-quality), license headers, TSDoc (iru-typescript-tsdoc), scoped and full Jest runs (iru-typescript-test), coverage (iru-typescript-coverage), plus the Maestro/native-build checks it adds.
Rust Code One Task Group and Go Code One Task Group — the same per-bucket pattern for Rust and Go: quality baseline and diff (iru-rust-code-quality/iru-go-code-quality), license headers, doc audits (iru-rust-rustdoc/iru-go-godoc), scoped and full tests (iru-rust-test/iru-go-test), and the coverage check (iru-rust-coverage/iru-go-coverage).
Setup Rust CLI, Setup Go CLI, Setup Swift CLI and Setup Dotnet Cli — the verification step that closes out each command-line tool scaffold (build, lint, tests, coverage, release dry run), run through this agent because the logs are long.
KMP Generate All Tests — Steps 3, 6 and 7, the coverage measurement before and after generating tests (KMP Coverage) and the full test suite run (KMP Test).
TypeScript Generate All Tests, Android Generate All Tests, and Swift Generate All Tests — Steps 3 and 6 (the coverage measurement taken before and after generating tests, via iru-typescript-coverage/iru-android-coverage/iru-swift-coverage) and Step 7 (the full test suite run once every file/class/type has its own generated tests).
Setup Java Spring Boot Hilla — Step 8, verify prepare-frontend and vitest coverage gates.
Setup Android Library (Step 11) and Setup Android App (Step 7) — the Gradle verification that closes out Android scaffolding (./gradlew --offline help, then :lib:assembleDebug/:app:assembleDebug).
Setup Swift Library (Step 13) — swift build and swift test against the freshly scaffolded package.
Setup Apple App — Step 7, runs YAML/swiftc parse and swift build/test checks on the scaffold.
Setup Swift GitHub Workflows — Step 13, verification pass: YAML validation, uses: ref resolution, dry run.
Setup Java Spring Boot — Step 10, three Maven or Gradle verification builds.
Kotlin Spring Boot Code One Task Group — Step 1, 3, baselines, every validation, integration run and aggregate coverage read.
NestJS Code One Task Group — Step 1, 3, baseline and every validation check.
Next.js Code One Task Group — Step 1, 3, baseline, every gate, next build and Playwright runs.
PHP Code One Task Group — Step 1, 3, baseline and every validation check.
FastAPI Code One Task Group — Step 1, 3, baseline and every validation check (Python Test, Python Coverage, Python Code Quality, Python Docstrings, license headers, container-backed integration runs).
Django Code One Task Group — Step 1, 3, baseline and every validation check (Python Test, Python Coverage, Python Code Quality, Python Docstrings, license headers, container-backed integration runs).
Quarkus Code One Task Group — Step 1, 3, baseline, validation, container-stage and coverage runs.
Setup Java Spring Boot APIs — Step 7, runs generation and compile verification.
Setup Java Spring Boot GitHub Workflows — Step 5, runs the workflow’s Maven/Gradle commands locally first.
Setup Java Spring Boot Modules — Step 12, runs mvn clean test or ./gradlew clean test, returns compact summary.
Setup Java Spring Boot Poms — Step 6, Verifies Maven validate/dependency:tree or Gradle help/build/dependencies.
Setup Java Spring Boot Testcontainers — Step 6, runs compose config, test, verify/integrationTest and stack up/down checks.
Setup PHP GitHub Workflows — Step 5, runs the workflows' composer commands locally, compact results.
Setup Quarkus GitHub Workflows — Step 5, runs workflow test/static-analysis/docs commands locally.
Setup Quarkus Service — Step 9, runs each verification gate with a compact result.
.NET Generate All Tests — Steps 3, 6, and 7, to run iru-dotnet-coverage/iru-dotnet-test and report back only a compact summary instead of a raw coverage/test log.
Java Generate All Tests — Steps 3, 6, and 7, to run iru-java-coverage/iru-java-test and report back only a compact summary instead of a raw coverage/test log.
Plan — recommends this agent for the scoped test-run step it writes into generated plans.
Setup CLI GitHub Workflows, Setup KMP App, Setup KMP GitHub Workflows, Setup macOS App, Setup macOS GitHub Workflows, Setup Python GitHub Workflows, Setup Windows App and Setup Windows GitHub Workflows — the local verification pass that closes out each scaffold or workflows skill (build, lint, tests), run through this agent because the logs are long.
Java Spring Boot Performance Tests — spawned for each of Step 9’s verification commands, since a load-test log is enormous.

Why this one specifically

Every one of these delegations exists to keep something noisy (a report, a build log) out of the calling skill’s own context window, and to diff against a baseline so only newly-introduced issues are ever reported — not to use any capability unique to a broadly-scoped agent. A narrow, purpose-built agent with Skill/Bash/ Read-only tool access is a tighter fit than the default general-purpose type, and lets every caller state the delegation in one line ("run X, diff against this baseline, report Y") instead of re-explaining the summarize-don’t-dump convention every time.

Source

iru-gate-runner.md on GitHub — the file this page was generated from.