Explore

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

Produce a grounded understanding of this repository’s codebase and, when available, of a specific tracked ticket — a GitHub issue or a Jira ticket — without writing a plan or making code changes. This is read-only research: its output is a report, not a diff.

Purpose

iru-explore gets an agent (or a human) oriented before any decision or code change is made. Given a ticket id, it auto-detects whether it’s a GitHub issue or a Jira key and narrows the investigation to only the areas that ticket implicates; given none, it does a general architectural tour of the repository. For a Jira ticket, it also fetches the ticket’s epic and any linked/related tickets one hop out (since an epic or a linked ticket often carries context — a shared constraint, what a "blocks"/"relates to" link actually means — that the leaf ticket’s own fields omit), and downloads and reads any implementation_plan_*.md file attached to the ticket, its epic, or its linked tickets: exactly the naming convention iru-code archives completed plans under and iru-issue attaches back onto a resolved ticket, so a match here is a previously-completed plan for similar or related work travelling with the ticket itself. It also detects which platform hosts the repository (GitHub, Bitbucket, Azure DevOps, or TFS) and the language(s)/framework(s) in play — both in the existing codebase and in whatever change is being requested — so its "Tech stack" report can be reused directly by later skills (iru-plan, iru-code, iru-update-docs, PR/branch creation) instead of each re-detecting the same facts. Language/framework detection covers Vite+React, Angular CLI, Hilla (Spring Boot + Vaadin + Hilla), Kotlin Spring Boot, Quarkus (Java or Kotlin), NestJS, Next.js, PHP (Laravel, WordPress plugin/theme, PrestaShop module, plain Composer package), Python (FastAPI, Django, plain package), React Native (Expo vs. bare Metro toolchain), Ionic/Capacitor, Kotlin Multiplatform (Compose Multiplatform vs. native UI), Android (library vs. application, Compose), SwiftPM/Xcode/XcodeGen/Tuist stacks (Apple apps' target platforms incl. visionOS, SwiftUI vs. UIKit, MVVM vs. MVC), macOS desktop apps (SwiftUI vs. AppKit, MVVM vs. MVC), and Windows desktop apps on .NET (WPF, WinUI 3, Windows Forms; MVVM vs. MVC), and command-line tools (Rust clap/Ratatui, Go Cobra/Bubble Tea, Swift ArgumentParser, .NET System.CommandLine — with the terminal-UI library and e2e test setup), in addition to the classic Java/.NET ones and plain Rust/Go projects — for JVM backends it also records the build tool (Maven vs. Gradle Kotlin/Groovy DSL, wrapper) and whether the layout is a hexagonal multi-module reactor or layered, and for NestJS, Next.js, PHP, and Python (requires-python, package manager, test runner, settings module/API layer/persistence) the module format/test runner/router/version details — and the report boils that detection down to a single normalized Project type: line — the shared vocabulary the iru-setup-repository bootstrap front door reads to pre-select the right stack orchestrator on an existing repository. This works even when the current working directory isn’t a git repository at all: it warns the user once, records that explicitly, and keeps going with whatever sources don’t need git (a Jira ticket, a documentation MCP, and any files actually present) — a GitHub issue lookup in that case falls back to asking the user for the target owner/repo explicitly. It also checks for a .archive/ directory — where iru-code archives every completed implementation_plan.md — and, if it holds a plan whose topic overlaps with the current task, reads it as concrete precedent for how a similar task was previously scoped and broken into task groups, rather than planning from a cold start. If a documentation MCP (e.g. Confluence, Notion) is connected, it also does a targeted search for pages relevant to the ticket or codebase, folding anything relevant into the report as extra context for a later plan. Either way it never edits a file, and it never proposes an implementation — that is `iru-plan’s job, run as a separate, explicit step.

Purpose group

Issue-to-PR Development Cycle

Plugin

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

Invocation

/iru-explore
/iru-explore <ticket-id>

Inputs

Argument Required Description Default

ticket-id

No

A GitHub issue number or a Jira key (e.g. PROJ-123) to ground the exploration in — auto-detected by pattern (a bare number/#N is GitHub, a letter-hyphen-digits key is Jira; the skill asks if genuinely ambiguous). When given, the investigation is scoped to the files, classes, and behavior the ticket describes.

None — if omitted, the skill asks whether to explore a specific ticket anyway; declining falls back to a general codebase tour.

Outputs

  • A plain-text report in the conversation — never a written file.

  • Always a Tech stack section: codebase languages/frameworks (per module, if more than one), the languages/frameworks implicated by the requested change, a normalized Project type: line, the Antora docs location (or "none found"), an Accessibility: line (present, partial, absent, or not applicable without a UI, with the evidence summary and the .ui-quality.yml level: enforce, report, off, none or missing), and the detected repository host (GitHub/Bitbucket/Azure DevOps/TFS, "no remote configured", or "none — not a git repository") — structured so later skills in the same conversation can read it directly instead of re-detecting it. It also carries a User interface line: none, or the UI stack(s) and where, rough counts of screens and reusable components, the .ui-quality.yml accessibility level when present, and whether the Antora module already has a ui/ section (or, for a requested change that adds UI, the screens/components it introduces) — which tells iru-plan to decompose the work into screens/components with virtualized collections, UI tests, screenshots and accessibility checks (omitted when accessibility: none), and iru-update-docs to maintain the UI pages (see Building user interfaces).

  • The Project type: line is a single-token-per-module normalization of the detected stack — this exact vocabulary is a shared contract with iru-setup-repository, which reads it verbatim to pre-select the right bootstrap flow on an existing repository:

    Value Meaning

    java-library

    Java/Kotlin library (pom.xml/build.gradle*, no Spring Boot, no Quarkus, no Android plugin)

    java-springboot

    Spring Boot service (no Hilla markers)

    java-springboot-hilla

    Spring Boot + Vaadin + Hilla (hilla-spring-boot-starter/vaadin-spring-boot-starter, @vaadin/hilla, src/main/frontend/)

    kotlin-springboot

    Kotlin Spring Boot service (Kotlin plugin or src/main/kotlin/ plus spring-boot-starter*, no Hilla markers)

    kotlin-springboot-hilla

    Kotlin Spring Boot plus the Hilla markers

    java-quarkus

    Quarkus service in Java (io.quarkus plugin, quarkus-bom, or io.quarkus:quarkus-* dependencies)

    kotlin-quarkus

    Quarkus service in Kotlin (quarkus-kotlin, Kotlin plugin, or src/main/kotlin/)

    typescript-library

    Plain TypeScript/npm library, no app framework

    react-web

    Vite + React (or another React web setup, not Native/Ionic)

    angular-web

    Angular CLI web app, not layered under Ionic

    nestjs

    NestJS backend (@nestjs/core, nest-cli.json, NestFactory in src/main.ts)

    nextjs

    Next.js web app (next dependency, next.config.*, app/ and/or pages/)

    php-laravel

    Laravel application (laravel/framework plus artisan)

    php-wordpress-plugin

    WordPress plugin (main PHP file with a Plugin Name: header)

    php-wordpress-theme

    WordPress theme (style.css with Theme Name: and/or theme.json)

    php-prestashop-module

    PrestaShop module (class extending Module, config.xml)

    php-library

    Any other Composer package with no Laravel/WordPress/PrestaShop markers

    python-fastapi

    FastAPI service (fastapi dependency plus a FastAPI( app, e.g. app/main.py)

    python-django

    Django project (django dependency plus a manage.py)

    python-library

    Any other Python package (pyproject.toml/setup.py, no Django/FastAPI/other web framework)

    android-library

    Gradle com.android.library module

    android-app

    Gradle com.android.application module

    swift-library

    SwiftPM .library(…​) product

    apple-app

    An Xcode/XcodeGen/Tuist app target (or a SwiftPM .executable(…​) product that is not an ArgumentParser command-line tool) — lists detected platforms in parentheses (ios, ipados, macos, watchos, visionos); its Build & layout: line records the iOS target’s UI framework (swiftui, or uikit — a UIApplicationDelegate + UIWindowSceneDelegate with no SwiftUI App) and MVVM vs. MVC from Packages/Core/Sources/Core/ViewModels/ vs. Controllers/

    macos-app

    An Xcode/XcodeGen/Tuist app whose only platform is macOS and that is not in the iru-setup-apple-app Targets/<Platform>/ layout — lists its UI framework in parentheses (swiftui or appkit). Takes precedence over apple-app (macos) except for an iru-setup-apple-app scaffold (Targets/macOS/…​), which stays apple-app (macos); macOS plus any other Apple platform stays apple-app

    react-native-app

    Expo / React Native app — lists its toolchain in parentheses (expo or metro)

    kmp-app

    Kotlin Multiplatform app with Android + iOS targets (iosApp/, commonMain/) — lists its UI approach in parentheses (compose or native); its Android host module is part of the same value

    ionic-app

    Ionic/Capacitor hybrid app — lists its underlying framework in parentheses (angular or react)

    windows-app

    A WinExe *.csproj with UseWPF/UseWinUI/UseWindowsForms (Windows desktop app) — lists its UI stack in parentheses (wpf, winui or winforms); its src/<App>.Core class library and test projects are part of the same value, never extra dotnet entries or multiple

    cli-tool

    A command-line tool — lists its language in parentheses (rust, go, swift or dotnet): Rust binary + clap (or ratatui), Go package main + Cobra/urfave/kong (or Bubble Tea), a Package.swift .executableTarget on ArgumentParser, or an Exe *.csproj (no WPF/WinUI/WinForms) with System.CommandLine/Spectre.Console.Cli/PackAsTool. Its Build & layout: line names the argument parser, the terminal-UI library (ui: tui) and the e2e test setup. Takes precedence over rust/go/swift-library/apple-app/dotnet for the same module; its library unit (src/lib.rs, internal/, <Bin>Kit, src/<Tool>.Core) and a Rust xtask/ member are part of the same value

    rust

    Any other Cargo.toml crate or workspace (library, service)

    go

    Any other go.mod module (library, service)

    dotnet

    Any other .NET project (.csproj/.fsproj/.sln/.slnx — library, ASP.NET Core, MAUI/Xamarin; a WPF/WinForms library with no WinExe stays dotnet)

    other

    A stack was detected but has no key above (e.g. Vue, Flutter, Micronaut, Flask, Ruby, C/C++, a KMP library with no app)

    unknown

    Nothing matched any manifest or source-level signal

    multiple

    More than one module with a distinct project type — followed by one <module-path>: <type> sub-line per module

  • An optional Build & layout: line for JVM backends (build tool, wrapper, hexagonal vs. layered), NestJS (module format, test runner, persistence), Next.js (version, router, cacheComponents), PHP (version, test runner), and Python (requires-python, package manager, test runner, FastAPI layout/persistence/Alembic, or Django settings module/app layout/DRF vs. Ninja), React Native (SDK/CLI version, router, EAS, e2e tool), KMP (modules, Kover/detekt/ktlint), Apple apps (iOS UI framework SwiftUI vs. UIKit, MVVM vs. MVC), macOS desktop apps (UI framework, MVVM vs. MVC from Packages/Core/Sources/Core/ViewModels/ vs. Controllers/, App Sandbox/hardened-runtime entitlements, ExportOptions-*.plist/scripts/make-dmg.sh), Windows desktop apps (UI stack, MVVM vs. MVC from the Core project layout, test framework, FlaUI UI tests, MSIX packaging files), and command-line tools (Rust: clap/Ratatui, tokio, assert_cmd/insta, deny.toml, nextest/cargo-llvm-cov; Go: Cobra/Bubble Tea, testscript, golangci-lint, GoReleaser; Swift: ArgumentParser targets; .NET: System.CommandLine, Native AOT, PackAsTool). Django and FastAPI markers win over python-library; Flask/Pyramid/Tornado are other.

  • If a documentation MCP (e.g. Confluence, Notion) is connected: a Related documentation section listing relevant pages found (title, link, one-line summary), or a note that none was relevant/connected.

  • A Related past implementation plans section covering both the local .archive/ check and, for a Jira ticket, any implementation_plan_*.md downloaded from the ticket/epic/linked tickets: name and source (local vs. downloaded) of any plan(s) used as precedent, its original topic, and what carries over — or a note that neither source had anything relevant.

  • If a ticket was explored: the task restated in plain language, the specific files/classes/methods relevant to it, how the current code behaves in that area, and anything ambiguous or missing that would block implementation. For a Jira ticket, also its epic (if any) and any linked/related tickets, each with a one-line summary of what it adds.

  • If codebase-only: a summary of the architecture areas covered and anything notable found.

  • If the working directory isn’t a git repository: an explicit warning stating what that disabled (git-remote- dependent tooling, git log history) versus what still ran normally (Jira, a documentation MCP, file-based codebase checks).

  • No code, configuration, or documentation is ever modified.

Execution flow

flowchart TD A[Start /iru-explore] --> B{Ticket id given?} B -- yes --> C["Detect type: Jira key pattern\nvs. bare number/#N (GitHub)"] B -- no --> D["Ask user: explore a ticket,\nor just the codebase?"] D -- ticket id given --> C D -- declined / none --> E0{Is cwd a git\nrepository?} C --> F0{Is cwd a git\nrepository?} F0 -- no --> F1["Warn user; record\n'not a git repository'"] F0 -- yes --> F["Detect repository host\n(GitHub/Bitbucket/Azure DevOps/TFS)"] F1 --> G F --> G["Fetch ticket: gh issue view\n(GitHub, or ask for owner/repo\nif not a git repo) or Jira MCP tools (Jira)"] G --> G1{Jira ticket?} G1 -- yes --> G2["Fetch epic + linked tickets\n(one hop out); download/read any\nattached implementation_plan_*.md"] G1 -- no --> H G2 --> H["Narrow exploration to files/classes/\nerror messages the ticket names,\nplus their closest structural neighbors"] H --> I["Check existing tests covering that area"] E0 -- no --> F1B["Warn user; record\n'not a git repository'"] E0 -- yes --> E["Detect repository host\n(GitHub/Bitbucket/Azure DevOps/TFS)"] F1B --> J E --> J["General orientation pass:\narchitecture, modules, recent git\nhistory (skipped if not a git repo)"] I --> O["Check .archive/ for a plan whose\ntopic overlaps the current task"] J --> O O --> K["Detect tech stack (incl. Spring Boot/Quarkus,\nNestJS, Next.js, PHP, Python (FastAPI/Django), Vite+React, Angular,\nHilla, React Native (Expo/Metro), Ionic, KMP, Android, SwiftPM/Xcode (Apple apps: platforms incl. visionOS,\nSwiftUI/UIKit, MVVM/MVC), macOS apps,\nWindows apps (WPF/WinUI/WinForms),\nRust/Go/Swift/.NET command-line tools)\n+ Antora docs; derive normalized\nProject type: line;\nUser interface line (stack, screens, .ui-quality.yml, ui/ docs)"] K --> K2["UI projects only: read-only accessibility scan\n(present / partial / absent) and\n.ui-quality.yml level"] K2 --> M{"Documentation MCP\nconnected (Confluence, Notion, ...)?"} M -- yes --> N["Search it for pages relevant\nto the ticket/codebase"] M -- no --> L["Report findings: Tech stack +\nRelated past implementation plans\n(+ epic/linked tickets,\n+ Related documentation)"] N --> L

Dependencies

Invokes

None — iru-explore is a leaf skill; it does not call any other skill in this catalog.

Invoked by

  • Setup Repository — Step 1, to detect the Project type: line when the working directory is non-empty.

  • Setup Readme — Step 2, to get the Project type: line when no report is in the conversation.

  • Plan — Step 3, grounds the plan in the codebase unless already explored in the conversation.

  • Issue — Step 5.1, to explore the ticket.

  • PR Review — Step 5, learns architecture, conventions and tech stack before judging the diff.

  • Create GitHub Issue and Create Jira Ticket — each runs iru-explore with no argument (general orientation, since no ticket exists yet) to ground the ticket they draft in the real codebase.

  • Knowledge to Issue — runs iru-explore with no argument to ground the purpose statement it synthesizes for a converted agreement in the real codebase, reused as-is when it then runs iru-create-github-issue.

  • Knowledge to Jira — the Jira counterpart: same use of iru-explore with no argument to ground the purpose statement it synthesizes, reused as-is when it then runs iru-create-jira-ticket.

  • Database Code One Task — reused from earlier in the conversation if it already ran, or run fresh otherwise, to ground the query/queries in the real schema, database engine, and any ticket context.

  • Java Spring Boot Performance Tests — Step 1, to survey a large service for its candidate use cases, so the caller gets the candidate list rather than the file contents.

Release does not invoke iru-explore itself — it reads the Project type: and Repository host: lines from an iru-explore report already produced earlier in the same conversation (or falls back to inspecting the repository’s manifests directly) to pick which iru-<key>-bump-version skill and git-host tooling to use.

Related agents

  • The built-in Explore agent (see Agents) — Step 4 uses it for the actual codebase search (module structure, abstractions, control flow) instead of manually reading every file.

Source

SKILL.md on GitHub — the file this page was generated from.