Setup Repository

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

The catalog’s single entry point for bootstrapping any repository. It does not scaffold anything itself — it detects or asks which of the supported project types applies (Java, Spring Boot, Quarkus, TypeScript, web, NestJS, PHP, Python (FastAPI and Django), Android, Swift/Apple (Swift libraries, and iOS/iPadOS/macOS/watchOS/visionOS apps in SwiftUI or UIKit, MVVM or MVC), cross-platform mobile — React Native, Ionic or Kotlin Multiplatform — and macOS/Windows desktop apps, and agent-friendly command-line tools in Rust, Go, Swift or C#/.NET), announces whether the run is a from-scratch setup or an update of an existing repository, collects the handful of questions genuinely shared across every stack, and hands off to exactly one of twelve existing stack orchestrators. For project types with a user interface it also asks whether to support accessibility and assistive technologies, and how strictly automated checks gate the UI tests (the accessibility input, with an opt-out none; in an existing repository it is pre-selected from iru-explore’s `Accessibility: detection), part of the catalog’s UI contract.

Purpose

iru-setup-repository exists so a user doesn’t need to already know which of this catalog’s stack-specific orchestrators (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-swift-repository, iru-setup-kmp-repository, iru-setup-macos-repository, iru-setup-windows-repository, iru-setup-cli-repository) applies to their repository. It surveys the working directory (running iru-explore when it already holds code) to detect the project type, asks only the cross-cutting questions the detected/chosen type still needs, and delegates the actual scaffolding — the downstream orchestrator asks its own project-identity questions and does the real work. Run against a repository that already has code, it forces mode: existing and prints an inventory of every component the pipeline owns (build manifest, source layout, Antora docs, .gitignore, each CI workflow, Dependabot, Sonar config, quality config, changelog, README, license) marked absent / present / partial. mode: existing no longer means "update silently": every delegated component warns about each pre-existing artifact it finds and asks whether to keep, update, or replace it (this front door never asks that on their behalf), unless on-existing pre-answers it for scripted runs.

The shared questions are visibility-aware and cost-aware, stated per GitHub’s current pricing (the user should double-check their plan): standard Actions runners are free for public repositories while private/internal ones consume included minutes (2,000/month on Free, 3,000 on Pro/Team, 50,000 on Enterprise Cloud), macOS minutes cost roughly 10x Linux, SonarCloud is free only for public/open-source projects, and GitHub Pages on a private repository needs Pro/Team/Enterprise Cloud and is publicly reachable unless private access control is used.

Purpose group

Repository Bootstrap

Plugin

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

Invocation

/iru-setup-repository

Optionally followed by an args block of key: value lines, e.g.:

/iru-setup-repository
project-type: android-app
mode: new
open-source: yes
visibility: public
ci: yes
ci-tests: full
pages: yes
distribution: store
sonar: cloud

Inputs

Argument Required Description Default

project-type

No

Any value from the shared vocabulary (java-library, java-springboot, java-springboot-hilla, kotlin-springboot, kotlin-springboot-hilla, java-quarkus, kotlin-quarkus, typescript-library, react-web, nextjs, angular-web, nestjs, php-laravel, php-wordpress-plugin, php-wordpress-theme, php-prestashop-module, php-library, python-fastapi, python-django, python-library, android-library, android-app, swift-library, apple-app (with its platforms in parentheses, e.g. apple-app (ios, visionos)), macos-app, react-native-app, ionic-app, kmp-app, windows-app, cli-tool (with its language in parentheses, e.g. cli-tool (rust)), rust, go, dotnet, other, unknown). Pre-resolves Step 2 when supplied.

Detected by Step 1’s iru-explore survey, or asked in Step 2

mode

No

new or existing.

existing when the repository is non-empty, new when it’s empty

on-existing

No

ask/keep/update/replace — how every delegated component treats prior setup it finds. Meant for scripted runs: this skill never asks it and forwards it only when it arrived in args.

ask (each component warns and asks per artifact)

open-source

No

yes/no. Drives the recommended defaults for publish/distribution and sonar.

Asked directly, no default

visibility

No

public/private/internal — the GitHub repository’s visibility; internal is treated like private for every cost decision. open-source: yes with a private/internal repository is contradictory and triggers a warning and a question.

Detected via gh repo view --json visibility when a GitHub remote exists, else asked (Public recommended when open source, otherwise Private)

ci

No

yes/no — whether GitHub Actions workflows are generated or updated at all. no makes the delegated orchestrator skip its workflows step entirely, including the shared security block (Dependabot, dependency-review, CodeQL, OSV-Scanner, gitleaks) and, for Spring Boot, the deploy/undeploy workflows; ci-tests and pages are then not asked.

Asked; Yes recommended, with the included-minutes and macOS cost stated for private repositories

ci-tests

No

unit/full — only with ci: yes. unit runs unit tests only (cheaper; integration, instrumentation, and e2e tests stay local); full adds the stack’s integration / emulator / Playwright / XCUITest suites (and, for kmp-app, Kotlin/Native iOS simulator tests plus the iosApp XCTest suite on macOS runners, ~10x cost; React Native adds Maestro flows on an Android emulator).

Asked; full recommended for public, unit for private/internal

pages

No

yes/no — whether CI publishes the Antora docs to GitHub Pages; only with ci: yes. With no the docs are built and uploaded as a workflow artifact only.

yes without asking for public repositories; asked for private/internal with No recommended

publish

No

yes/no — library project types only (never asked for app types, services, or web-app types).

yes when open source, otherwise asked with no recommended

distribution

No

App project types: none/internal/store. Quarkus: registry/none (GHCR image); NestJS: internal/none; Laravel: none/internal; WordPress and PrestaShop: none/internal/store; FastAPI and Django: none/internal/store (GHCR image). Never asked for Spring Boot, react-web, angular-web, or nextjs (the latter decided downstream from its output mode).

store only when open source, otherwise asked with internal recommended (flavor-specific defaults for the service and PHP types)

sonar

No

cloud/self-hosted/none. With ci: no nothing would send reports automatically, so none is recommended and any Sonar configuration is build-side only.

cloud only when the repository is public and open source; otherwise asked with none recommended and self-hosted SonarQube as the second option

sonar-organization

No

SonarCloud organization slug, collected only when sonar: cloud.

None

sonar-project-key

No

Sonar project key, collected when sonar: cloud or sonar: self-hosted.

None

sonar-host-url

No

Self-hosted SonarQube host URL, collected only when sonar: self-hosted.

None

accessibility

No

enforce, report, off, or none (opt out entirely) — UI project types only: whether accessibility and assistive-technology support is wanted and how strictly the UI tests' automated accessibility checks gate (axe-core on the web, Android’s Accessibility Test Framework, Xcode’s accessibility audit, Axe.Windows). Asked once in Step 3 ("Support accessibility and assistive technologies?") with Enforce recommended for new projects; in mode: existing it is pre-selected from iru-explore’s `Accessibility: line (present enforce, partial report with a mixed-compliance warning, absent none) after showing the evidence, forwarded to every orchestrator that recognizes it, and recorded by the UI scaffold in .ui-quality.yml at the repository root. For Spring Boot without Hilla and for command-line tools the orchestrator asks (or applies it only for a terminal UI / Hilla frontend).

Asked for UI types (enforce recommended); not asked or forwarded for types without a UI

flavor

No

The delegated orchestrator’s own flavor value (for example library/react/nextjs/angular/nestjs/ react-native/ionic for TypeScript, laravel/wordpress-plugin/wordpress-theme/prestashop-module for PHP, fastapi/django for Python); usually redundant with project-type and can be left unset.

Derived from project-type per Step 2’s mapping table

language, build-tool, layout, frontend

No

JVM stack-shape keys (java/kotlin — for cli-tool, language is instead rust/go/swift/dotnet, resolved by Step 2’s follow-up; maven/gradle, Quarkus single/hexagonal, Spring Boot none/hilla). Never asked here; forwarded only when supplied via args or pre-set by Step 1’s detection, otherwise the delegated orchestrator asks them.

Detected from the build (Kotlin Spring Boot build tool), else left to the orchestrator

rolling-deployments, deployment-strategy, advance

No

Spring Boot only, meaningful only with ci: yes: rolling-deployments is yes/no, deployment-strategy is rolling/blue-green/canary/linear, advance is auto/manual/hybrid. Blue/green rolling deployments are a stack-shape choice that iru-setup-java-springboot asks itself in its Step 3c, so they are never asked here; they are forwarded only when supplied via args (and never with ci: no, since rolling deployments need the generated workflows). See Spring Boot Rolling Deployments.

Left to the orchestrator

python-version

No

Python version floor for the Python flavors. Never asked here; forwarded only when supplied via args, otherwise iru-setup-python-repository asks it.

Left to the orchestrator

platforms

No

Comma-separated Apple platforms (ios/ipados/macos/watchos) for a Swift library or Apple app; a Swift library gets a follow-up multi-select for tvos/visionos/linux, and an Apple app a narrower "Also target visionOS?" follow-up (never tvos/linux), appended to the same list, since iru-setup-swift-repository never re-asks a key the front door already supplied. Picking macos alone for an Apple app suggests the macOS desktop app type instead.

Pre-filled from Step 1’s detected apple-app (…) parenthetical when present, else asked

framework

No

Ionic app framework, angular or react.

Pre-filled from Step 1’s detected ionic-app (…) parenthetical when present, else asked

toolchain

No

React Native toolchain, expo (Expo Router, config plugins, no committed native projects) or metro (bare React Native CLI with committed android//ios/ projects, React Navigation, CocoaPods and an iOS CI job on macOS).

Pre-filled from Step 1’s detected react-native-app (…) parenthetical when present, else asked (Expo recommended)

native-builds

No

React Native build strategy, eas or local; only with toolchain: expo — never asked or forwarded for metro.

eas, asked to confirm

ui

No

UI approach: Kotlin Multiplatform compose (shared Compose Multiplatform UI) vs. native (Jetpack Compose + SwiftUI), macOS swiftui/appkit, Windows wpf/winui/winforms, a command-line tool’s none/tui, or an Apple app’s SwiftUI vs. UIKit. Never asked here; forwarded only when Step 1 detected it (from the kmp-app (…)/macos-app (…)/windows-app (…) parenthetical, or ui: tui from a cli-tool (…) whose Build & layout: names a terminal-UI library) or args supplied it (the only route for an Apple app), otherwise the delegated orchestrator asks.

Left to the orchestrator

architecture

No

mvvm or mvc for the desktop apps and for an Apple app. Likewise never asked here, only forwarded when supplied via args; otherwise detected or confirmed by iru-setup-macos-repository/iru-setup-windows-repository (from ViewModels/ vs. Controllers/), or asked by iru-setup-swift-repository for an Apple app.

Left to the orchestrator

integration-branch

No

Pass-through only — never actively asked by this skill; forwarded to the delegated orchestrator when supplied.

None

stable-branch

No

Pass-through only, forwarded when supplied.

None

license

No

Pass-through only, forwarded when supplied.

None

developer-name

No

Pass-through only, forwarded when supplied.

None

developer-email

No

Pass-through only, forwarded when supplied.

None

organization-url

No

Pass-through only, forwarded when supplied.

None

Other key: value lines

No

Opaque pass-through (for example name, package, description, scope, orm, database, api, output, e2e, slug, vendor, php-version, group-id, artifact-id, java-version, namespace, for kmp-app the identity keys app-name, application-id, bundle-id, for macos-app app-name, bundle-id, team-id, min-macos, sandbox, and for windows-app app-name, display-name, publisher, package-name, signing, winget, and for cli-tool bin-name, description, owner, channels, homebrew-tap, cross-os-ci, crate-name, module-path, tool-name, package-id). Forwarded verbatim only when the delegated orchestrator’s own Step 0 recognizes the key; dropped keys are listed in the final report.

None

Outputs

  • No files are written directly by this skill — every artifact (source scaffold, Antora docs, .gitignore, CI workflows, CHANGELOG.md, README.md) is produced by whichever single stack orchestrator Step 4 delegates to, exactly as that orchestrator’s own page describes.

  • No .ui-quality.yml is written here either — the delegated UI scaffold writes it from the forwarded accessibility value.

  • An up-front announcement (Step 1): "from scratch" or "updating an existing repository", the latter with the absent / present / partial component inventory.

  • A final report (Step 5): the resolved project-type (with, for the app types, the platforms/framework/toolchain/UI approach that came with it, and the MVVM/MVC architecture the desktop orchestrators reported), the setup mode and where it came from, and every shared input as actually applied (visibility and how it was resolved, ci, ci-tests, pages, accessibility for a UI type, and so on); a per-component table of what the delegated orchestrator did (created / updated / replaced / kept as is / skipped (ci: no)) with every mismatch it flagged between a kept file and this run’s choices; cost notes tied to the visibility; a ci: no note when workflows and the security block were skipped; any key that could not be forwarded; one consolidated secrets/environments table; and an explicit warning block (review every generated file; every listed secret and matching external account must already exist; which values were inferred rather than asked). For Spring Boot types it adds one line on rolling deployments as the orchestrator reported them: enabled or not (with ci: no, "not offered - needs the workflows"), and when enabled the strategy, advance mode, whether promote.yml was generated (a rolling strategy keeps the single-job deploy.yml and generates none), and that /iru-springboot-rolling-deployments enable|disable switches it later.

  • When the detected or chosen type is dotnet (a plain .NET library or service — Windows desktop apps are windows-app, a .NET command-line tool is cli-tool (dotnet), above; the .NET gate skills iru-dotnet-test/-coverage/-code-quality/-docfx and iru-setup-antora/-changelog/-readme can still be run individually), rust/go (a Rust crate or Go module that is not a command-line tool; the Rust/Go gate skills can still be run by hand), php-library, python-library (a plain Python package; the Python gate skills and individual repository-file skills can still be run by hand), other or otherwise unsupported: a plain report that no bootstrap orchestrator exists in this catalog for it, with no delegation attempted.

Execution flow

flowchart TD A["Start /iru-setup-repository\nStep 0: parse args"] --> B{"Step 1: Survey working directory\n(git ls-files / manifest files present?)"} B -- "Non-empty repo" --> C["Run iru-explore\nread Project type: line"] B -- "Empty repo" --> D["mode: new\n(skip iru-explore)"] C --> C1["Announce: updating an existing repository;\nprint component inventory\n(absent / present / partial)"] D --> D1["Announce: setting up from scratch"] C1 --> E{"Detected project type"} E -- "dotnet / rust / go / php-library / python-library" --> G["Report: no bootstrap\norchestrator for it; stop"] E -- "other / unknown / multiple" --> F E -- "a supported type" --> H["Pre-select matching\nStep 2 option as (detected)"] H --> I D1 --> F["Step 2: Ask project type\n(skipped if already resolved via args)\nup to 6 AskUserQuestion rounds of 3 types\n+ 'Something in the next group':\nJVM, Web and Node, PHP, Python, Mobile and Apple,\nDesktop and command line\n(macOS app / Windows app / CLI tool)\n(bounded follow-ups for bundled options)"] F -- "'None of these'\nin round 6" --> G F -- "resolved" --> I["Step 3: Ask shared inputs once, in order:\nopen-source, visibility (args, gh, or ask),\nci, sonar, ci-tests, pages,\npublish/distribution, conditional questions,\naccessibility (UI types only)\n(Apple platforms incl. visionOS, Ionic framework,\nReact Native toolchain; cost notes per visibility)"] I --> J["Step 4: Delegate via\niru-isolated-skill-executor\nto exactly one of twelve\nstack orchestrators\n(each component warns and asks\nkeep / update / replace)"] J --> K["Step 5: Report mode, resolved inputs,\nper-component actions and mismatches,\ncost notes, secrets table, warnings"]

Dependencies

Invokes

  • Explore — Step 1, directly (not via a sub-agent), and only when the working directory is non-empty: reads its ## Tech stack report’s - Project type: line to pre-select Step 2’s option and set mode: existing.

  • Exactly one of the following twelve, via the iru-isolated-skill-executor agent in Step 4, chosen by the resolved project-type — never more than one per run outside the multiple case:

    • Setup Java Library Repository — for java-library.

    • Setup Java Spring Boot — for java-springboot, java-springboot-hilla, kotlin-springboot, kotlin-springboot-hilla (language, build tool, frontend and, with ci: yes, blue/green rolling deployments asked by the orchestrator itself; the rolling-deployments/deployment-strategy/advance keys are forwarded only when supplied via args). Related: Spring Boot Rolling Deployments.

    • Setup Quarkus Repository — for java-quarkus, kotlin-quarkus.

    • Setup TypeScript Repository — for typescript-library, react-web, nextjs, angular-web, nestjs, react-native-app (with toolchain: expo|metro), ionic-app (via its own flavor arg).

    • Setup PHP Repository — for php-laravel, php-wordpress-plugin, php-wordpress-theme, php-prestashop-module (via its own flavor arg).

    • Setup Python Repository — for python-fastapi, python-django (via its own flavor arg: fastapi or django).

    • Setup Android Repository — for android-library, android-app (via its own flavor arg).

    • Setup Swift Repository — for swift-library, apple-app (via its own flavor arg, plus platforms; for an app, ui (SwiftUI/UIKit) and architecture (MVVM/MVC) only when supplied via args, otherwise that orchestrator asks them).

    • Setup KMP Repository — for kmp-app (cross-platform Kotlin Multiplatform; apps only, so never sent publish or flavor).

    • Setup macOS Repository — for macos-app (a native macOS desktop app; only ui is forwarded from the detected parenthetical, architecture is detected or confirmed by the orchestrator). Reached from the Round 6 "Desktop & command line" of the project-type interview, or by detection; an apple-app whose platforms include macOS plus another platform — or a macOS-only iru-setup-apple-app scaffold — stays apple-app and never offers macos-app.

    • Setup Windows Repository — for windows-app (a C#/.NET 10 desktop app: WPF, WinUI 3 or Windows Forms; MSIX/WinGet/Microsoft Store), likewise forwarding only ui.

    • Setup CLI Repository — for cli-tool (an agent-friendly command-line tool in Rust, Go, Swift or C#/.NET). Reached from Round 6’s "Command-line tool" option, whose bounded follow-up picks the language (forwarded as language; pre-filled from a detected cli-tool (…) parenthetical), or by detection; ui: tui is forwarded only when detected or supplied via args, and the terminal UI, channels, cross-os-ci and identity are asked by the orchestrator. Never sent publish or flavor.

Invoked by

None from inside this catalog — it is a top-level entry point invoked by a person.

Related agents

  • iru-isolated-skill-executor — spawned once in Step 4 to run the chosen stack orchestrator end-to-end in a fresh context, so that orchestrator’s own multi-step exploration/scaffolding transcript doesn’t accumulate in this front door’s context.

Source

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