Code

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

Execute implementation_plan.md end to end, one task group at a time — implement every task in a group, validate the group once, check off its checkboxes in implementation_plan.md, and move to the next. This skill orchestrates the actual implementation work; it is the execution counterpart to the iru-plan skill.

Purpose

iru-code is the autonomous orchestration engine of the catalog. Given a plan produced by iru-plan (or by iru-issue, which runs iru-plan internally), it first gates on open questions: no implementation starts while the plan still contains an unresolved [NEEDS CLARIFICATION marker (the form iru-plan persists when it could not ask), so each one is put to the user via AskUserQuestion and the answer is written back into the plan. It then determines which language/framework key(s) are in play, captures a project-wide code-quality baseline (via iru-java-code-quality, iru-kotlin-code-quality, iru-php-code-quality, iru-python-code-quality, iru-dotnet-code-quality, iru-typescript-code-quality, iru-android-code-quality, iru-kmp-code-quality, iru-swift-code-quality, iru-rust-code-quality, iru-go-code-quality, resolved per key: framework keys share their language’s gate, e.g. java-springboot uses the Java one, kotlin-springboot the Kotlin one, quarkus the Java or Kotlin one depending on the build, nestjs/nextjs/react-native the TypeScript one, kmp the Kotlin Multiplatform one, fastapi/django the Python one, windows the .NET one, rust the Rust one, go the Go one) and a project-wide security baseline (via iru-check-security), then works through every task group in plan order — dispatching each group to iru-code-one-task-group, which resolves each task’s language and delegates to the matching <key>-code-one-task-group skill (implementing, testing, and validating the whole group once), checking off the plan’s checkboxes and notifying the user as it goes so the run is resumable if interrupted and progress is visible group by group. On successful completion it runs a full local verification build, re-checks the quality and security baselines (the security gate is a hard stop on any increase, unlike the quality gate), and verifies acceptance-criteria coverage (every row of the plan’s ## Acceptance criteria coverage table must name at least one task, and all named tasks must be checked, else the run is blocked) — if quality regressed, the user can choose to file the remaining issues as new tickets on whichever tracker the plan itself originated from (a GitHub issue via gh issue create, or a Jira ticket via the iru-create-jira-ticket skill, detected from the plan’s own Source: line) — updates the project’s Antora documentation via iru-update-docs, archives the plan to .archive/ under a filename that embeds the originating GitHub issue number or Jira key (falling back to a timestamp with no identifiable ticket), and asks the user for a final review; it never commits, pushes, or opens a PR itself.

Catalog agents are dispatched by their plugin-safe name: subagent_type: "<agent-name>" (for example "iru-gate-runner") when installed under .claude/agents/, or "iru-core:<agent-name>" when installed as a plugin, whichever appears in the available agent types.

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-code

Inputs

Argument Required Description Default

Argument	Required	Description	Default
(none)	—	`iru-code` takes no arguments. It always reads `implementation_plan.md` from the repository root — the file produced by the `iru-plan` skill (directly, or via `iru-issue`) — including its task groups, each with a `Parallelizable` verdict and its tasks' language/framework key(s). It also scans the plan for unresolved `[NEEDS CLARIFICATION` markers (and asks the user to resolve them) and, when present, uses the `## Acceptance criteria coverage` table for the final coverage check; plans from an older `iru-plan` without that table remain executable, with a one-time warning that the check is skipped.	Not applicable — if `implementation_plan.md` is missing or empty, the skill tells the user there is nothing to execute and suggests running `/iru-plan` first, then stops.

(none)

—

iru-code takes no arguments. It always reads implementation_plan.md from the repository root — the file produced by the iru-plan skill (directly, or via iru-issue) — including its task groups, each with a Parallelizable verdict and its tasks' language/framework key(s). It also scans the plan for unresolved [NEEDS CLARIFICATION markers (and asks the user to resolve them) and, when present, uses the ## Acceptance criteria coverage table for the final coverage check; plans from an older iru-plan without that table remain executable, with a one-time warning that the check is skipped.

Not applicable — if implementation_plan.md is missing or empty, the skill tells the user there is nothing to execute and suggests running /iru-plan first, then stops.

Outputs

Source and test files created/modified per task, via iru-code-one-task-group and the language-specific <key>-code-one-task-group skill it dispatches to (or a best-effort direct implementation when no key/ matching skill applies).
Tests achieving at least 80% line coverage for the changed/new classes per group, verified against the real coverage report — the responsibility of the dispatched group skill.
License headers and language-appropriate documentation (Javadoc, XML doc comments, etc.) kept current per group, validated once for the whole group rather than once per task.
implementation_plan.md with each completed task’s (and sub-task’s) checkbox checked ([ ] → [x]) and a progress note — updated live by iru-code-one-task-group as each task lands, confirmed by iru-code once the whole group clears.
Resolved clarifications: every [NEEDS CLARIFICATION marker is replaced in place by the user’s decision (affected tasks adjusted, Open clarifications: reduced to none) before any implementation; if the user declines or cannot be asked, the run stops with the plan untouched and the open markers reported.
A user-facing progress notification after every completed group, in addition to the plan file already reflecting it.
A project-wide quality baseline (Step 3) compared against the final state (Step 7) per language/framework key involved — if it regressed, the user is asked to add follow-up tasks, file new tickets on whichever tracker the plan originated from (GitHub via gh issue create, or Jira via the iru-create-jira-ticket skill), or accept it as-is before archiving.
A project-wide security baseline (Step 3, via iru-check-security) compared against the final state (Step 7) — any increase is a hard stop: the user must resolve it (remove/rotate the secret, or audit a false positive themselves) before the run can proceed to archiving.
An acceptance-criteria coverage check (Step 7): each row of the plan’s coverage table names at least one task and all its tasks are checked [x]; an uncovered or unchecked row blocks archiving until follow-up tasks are added or the user rules the criterion out of scope. Skipped for a plan without that section.
A full local verification build confirmed healthy before archiving.
The project’s Antora documentation brought up to date via iru-update-docs (Step 8), covering everything this run changed — or a plain note that there’s no Antora module to update.
On success: implementation_plan.md moved to .archive/implementation_plan_<ticket-id-or-timestamp>.md — the bare GitHub issue number, the Jira key as-is (e.g. PROJ-123), or a timestamp with no identifiable ticket — a summary of groups/tasks completed/files touched/coverage/quality/security/acceptance-criteria coverage outcome/documentation updates (and any clarifications resolved), and a request for the user to review the code changes — no commit, push, or PR is ever made by this skill.
On an unresolved blocker: the plan stays unchecked and at the repository root (not archived) so a later run can resume it.

Execution flow

flowchart TD A[Start /iru-code] --> B{implementation_plan.md\npresent?} B -- missing/empty --> Z["Stop: suggest running /iru-plan first"] B -- present --> C["Warn if plan already exists\n(fresh / resumed / all-checked)"] C --> D["Verify every task/sub-task has a\n[ ]/[x] checkbox and groups exist\n(flat plans treated as single-task groups)"] D --> D2{"Unresolved NEEDS CLARIFICATION\nmarkers in the plan?"} D2 -- yes, user declines or not askable --> Z2["Stop: report open markers,\nplan left untouched"] D2 -- yes, resolved via AskUserQuestion --> E D2 -- no --> E E["Mirror pending groups into\nsession task list (TaskCreate)"] E --> F["Determine language/framework key(s);\ncapture per-key quality baseline via\n<key>-code-quality + security\nbaseline via check-security (sub-agents)"] F --> G{Next unchecked\ntask group?} G -- none left --> P["Step 7: full build verification\n+ quality/security baseline comparison"] G -- yes --> H["Invoke code-one-task-group for\nthe whole group via isolated-skill-executor"] H -- blocker reported --> L["Surface blocker to user and stop"] H -- clean report --> M["Confirm group's boxes checked;\nnotify user of group completion"] M --> G P -- build fails --> P P -- build passes --> Q{"Quality regressed\nvs. baseline (any key)?"} Q -- yes --> R["Ask user: follow-up tasks,\nfile new tickets (GitHub or Jira,\nper plan origin), or accept as-is"] R -- follow-up group added --> G Q -- no / resolved --> S{Security count\nincreased?} S -- yes --> T["Hard stop: ask user to\nremove/rotate or audit;\nre-check until resolved"] T --> S S -- no --> CV{"Every acceptance-criteria row\ncovered and its tasks checked?"} CV -- no --> CW["Ask user: add follow-up group\nor mark criterion out of scope"] CW -- follow-up group added --> G CV -- yes / no coverage section --> U["Step 8: update-docs skill\n(Antora documentation)"] U --> V["Archive plan to .archive/,\nsummarize, ask for final review"]

Dependencies

Invokes

Code One Task Group — Step 4, once per plan group, in order, passing that group’s full text and any relevant code-state context — invoked via the iru-isolated-skill-executor agent rather than a direct Skill call, so each group’s own file re-reads/edits/reasoning stay out of iru-code’s own context. That skill resolves each task’s language, dispatches it to the matching `<key>-code-one-task-group skill, checks off boxes, and hands back a short, self-contained summary.
Update Docs — Step 8, once per run (not per group), invoked directly via Skill once the build, quality, and security gates all pass, so the project’s documentation reflects everything the whole plan changed.
Create Jira Ticket — Step 7, conditionally: only when the final quality check regresses against baseline, the plan’s own Source: line identifies it as Jira-originated, and the user chooses to file the remaining issues as new tickets rather than adding a follow-up task group or accepting them as-is. Invoked directly via Skill, passing each issue’s file/line/tool/message detail so the drafted ticket doesn’t need to re-ask the user for context already known. The GitHub equivalent uses gh issue create directly rather than the Create GitHub Issue skill.

Each of the following is invoked via the iru-gate-runner agent rather than directly, so verbose report output stays out of `iru-code’s own context window and only the distilled outcome comes back:

Java Code Quality / Kotlin Code Quality / PHP Code Quality / Python Code Quality / .NET Code Quality / TypeScript Code Quality / Android Code Quality / KMP Code Quality / Swift Code Quality / Rust Code Quality / Go Code Quality — whichever one each key resolves to (java/java-springboot → Java; kotlin-springboot and a Kotlin quarkus → Kotlin; quarkus on Java → Java; php → PHP; fastapi/django → Python; typescript/nestjs/ nextjs/react-native → TypeScript; kmp → Kotlin Multiplatform; windows → .NET; rust → Rust (clippy/rustfmt/cargo-deny); go → Go (golangci-lint/go vet/govulncheck); other keys → iru-<key>-code-quality) — Step 3 (project-wide baseline, once per language/framework key involved) and Step 7 (final project-wide comparison against that baseline).
Check Security — Step 3 (project-wide baseline) and Step 7 (final comparison) — any increase is a hard stop, unlike the quality gate’s "accept as-is" option.
A final full-build verification (Step 7), run once per language/framework key in the plan through iru-gate-runner as a raw command rather than via a skill: the full verification command the repository’s CLAUDE.md names for that stack, else a per-key default (mvn clean jacoco:prepare-agent install jacoco:report javadoc:jar source:jar -P '!build-extras' for java on Maven, mvn -B -ntp clean verify for java-springboot, ./mvnw -B -ntp clean verify or ./gradlew build for kotlin-springboot and quarkus (container-backed tests need Docker), composer validate --strict plus the project’s composer test/lint scripts for php, ruff check/ruff format --check/mypy/pytest under the project runner (uv run, poetry run, pdm run or .venv) for fastapi/django (plus manage.py check and makemigrations --check --dry-run for django, alembic check for FastAPI with Alembic; integration tests need Docker), dotnet build && dotnet test (plus dotnet publish -c Release -r <host RID> for a command-line tool, so trim/AOT warnings surface), the package manager’s lint/typecheck/test scripts for typescript (then npm run build for nestjs/nextjs), ./gradlew build for android, ./gradlew build plus (on macOS) the iOS host app’s xcodebuild build for kmp (iOS reported as unverified on other hosts), the typescript scripts plus ./gradlew assembleDebug/pod install + xcodebuild build (Metro toolchain) or npx expo export (Expo toolchain) for react-native, swift build && swift test or xcodebuild build-for-testing for swift (-destination 'platform=macOS' plus swift test in Packages/Core for a macOS desktop app; unverified off macOS), dotnet build -c Release plus dotnet test --filter "TestCategory!=UI" for windows (on a non-Windows host with -p:EnableWindowsTargeting=true, running only the portable Core tests and reporting the app run, WinUI build and UI tests as unverified; on Windows the desktop UI tests also run through iru-dotnet-test’s `ui selector), cargo fmt --all --check + cargo clippy … -D warnings + cargo test --workspace (plus cargo deny check and, for a CLI with an xtask, cargo xtask docs) for rust, and go build ./… + go vet ./… + go test -race ./… (plus golangci-lint, govulncheck, goreleaser check when configured) for go; a swift command-line tool is just swift build && swift test; container-backed Rust/Go tests need Docker); skipped when no key could be resolved.

Invoked by

Issue — Step 6, full implementation run in a clean context, via the iru-isolated-skill-executor agent.
Also invoked directly by a person via /iru-code, once a iru-plan-produced implementation_plan.md exists at the repository root — no orchestrating skill required.

Related agents

iru-gate-runner — spawned for each project-wide quality/security baseline capture and comparison (Steps 3 and 7) and the final build verification. Per-group implementation and validation (license headers, doc comments, scoped tests, coverage, per-group quality) is no longer spawned directly by iru-code — it happens two levels down, inside whichever <key>-code-one-task-group skill handles each group’s bucket of tasks (Java, Spring Boot, Kotlin Spring Boot, Quarkus, PHP, FastAPI, Django, .NET, TypeScript, NestJS, Next.js, Android, Kotlin Multiplatform, React Native, Swift, Windows desktop, Rust, Go).
iru-isolated-skill-executor — spawned once per task group (Step 4) to invoke iru-code-one-task-group, so a plan with many groups doesn’t accumulate every group’s full implementation transcript in `iru-code’s own context.

Source

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