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 determines which language/framework key(s) are in play, captures a project-wide code-quality baseline (via iru-java-code-quality, iru-dotnet-code-quality, or whichever <key>-code-quality skill matches) 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) — 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.

Purpose group

Issue-to-PR Development Cycle

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).	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).

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.
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.
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 outcome/documentation updates, 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 --> 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 --> 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 / .NET 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) via mvn clean jacoco:prepare-agent install jacoco:report javadoc:jar source:jar -P '!build-extras' (or the equivalent for other languages/frameworks in play), run directly as a raw command rather than via a skill.

Invoked by

Issue — Step 6, when the user chooses automatic implementation over manual review, invokes iru-code via the iru-isolated-skill-executor agent so the whole implementation run starts from a clean context.
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.
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.