--- name: iru-code description: Execute the tasks in implementation_plan.md at the repository root, one task group at a time — implement every task in a group (in parallel where the plan marks the group parallelizable), validate the whole group once (tests, coverage, code quality), and check off each task's checkbox directly in implementation_plan.md before moving to the next group. Dispatches each group to the `iru-code-one-task-group` skill, which in turn resolves the language/framework-specific `-code-one-task-group` skill declared by the plan (e.g. `iru-java-code-one-task-group`, `iru-dotnet-code-one-task-group`) — falling back to implementing a task directly when the plan names no matching key. Runs autonomously — user intervention is limited to unresolved errors, decisions only the user can make, or permissions the allowed-tools list doesn't cover. Warns the user up front if implementation_plan.md already exists at the repository root (expected only when resuming an interrupted prior run). On successful completion, updates the project's Antora documentation (via the `iru-update-docs` skill) to reflect all the changes the plan made, archives the plan to .archive/, asks the user whether to open follow-up tasks or GitHub issues if overall code quality isn't excellent, and asks for a final review of all code and documentation changes. Invoke as `/iru-code` once implementation_plan.md exists (e.g. produced by the `iru-plan` skill). model: sonnet allowed-tools: Read Edit Write Bash(mvn *) Bash(detect-secrets *) Bash(git status *) Bash(git diff *) Bash(git log *) Bash(find *) Bash(grep *) Bash(ls *) Bash(mkdir *) Bash(mv *) Bash(date *) Bash(gh issue create *) TaskCreate TaskUpdate TaskList TaskGet Skill Agent --- # Implementation Execute `implementation_plan.md` end to end: implement every task group listed against the real codebase, back each group with a single consolidated validation pass, check tasks off in the plan file as they land, and move on — with as little back-and-forth with the user as possible. This skill writes code; it is the execution counterpart to the `iru-plan` skill. It uses a medium model on purpose: the plan already carries the hard reasoning (task breakdown, dependency grouping, language/framework resolution) — this skill's job is to drive execution of that plan, not to re-derive it. On successful completion it brings the project's documentation in line with everything the plan changed (Step 8) and archives the plan file (Step 9) so the root only ever holds the plan for work that is still outstanding. ## Step 1 — Load the plan, and warn if one already exists Read `implementation_plan.md` at the repository root. - **Missing or empty**: tell the user there is nothing to execute and suggest running `/iru-plan` first. Stop — this is not a case to interrupt the user about, just report it. - **Present**: warn the user before doing anything else — this is a heads-up, not a question, so don't block on it unless the file looks genuinely inconsistent with the current task. Because a successful run always archives the plan to `.archive/` (Step 9), finding `implementation_plan.md` at the root when a run starts should only mean one of: - It was just written by the `iru-plan` skill for the task about to be executed (no checkboxes checked yet). - A previous `/iru-code` run on this same task was interrupted before finishing (some checkboxes checked, some not). - Unusually, every checkbox is already checked — a prior run finished all tasks but was interrupted before it could archive the file. Say so explicitly, then archive it immediately per Step 9 and report there is nothing left to execute, rather than re-running already-completed work. State which of these applies based on the checkbox state you see, then continue treating the file as the plan to execute/resume. If the plan's content clearly describes unrelated or stale work (not the task currently being asked about), stop and confirm with the user instead of assuming. - Otherwise, read the plan in full, including the "Task summary" and "Current code state" sections for context, and the numbered "Implementation steps" (organized into task groups) for the actual work list. ## Step 2 — Verify checkbox placeholders and task groups The `iru-plan` skill gives every top-level task and every sub-task its own empty markdown checkbox (`[ ]`), organized into task groups each marked `Parallelizable: yes`/`Parallelizable: no`. Track completion by checking those boxes — do not introduce a separate status tag or notation. - Confirm each task/sub-task line has a `[ ]`/`[x]` checkbox. If the plan predates this convention and is missing checkboxes on some lines, add `[ ]` to those lines now (don't guess completion state — treat anything without a checked box as not done) and save the file before continuing. - Confirm the plan organizes tasks into groups. If the plan predates the grouping convention and is a flat task list instead, treat every remaining (unchecked) top-level task as belonging to its own single-task group with `Parallelizable: yes` (a group of one is trivially parallelizable), preserving plan order — this keeps older plans executable without requiring the user to regenerate them. - Treat any task or sub-task whose checkbox is already `[x]` (from a prior run of this skill) as already done — this makes the skill resumable across interrupted runs. A group where every task is already `[x]` is itself done; skip it entirely in Step 4. ## Step 3 — Track progress, and capture project-wide quality and security baselines Mirror the plan's task groups into the session's task list (`TaskCreate`), one per pending group, so the user can see live progress at the group level. Mark each `TaskUpdate`d as completed as you finish it, in step with the plan-file confirmation in Step 5. This is in addition to, not a replacement for, updating `implementation_plan.md` — the plan file is the durable record; the task list is the live view. Before implementing anything, determine which language/framework(s) this plan is in play for: read the "Task summary" section's **Language/framework** line if the plan declared one key for the whole plan, or the per-task tags in "Implementation steps" if it declared them per task instead (this is exactly what the `iru-plan` skill's Step 5 produces). Collect the distinct set of keys found across the whole plan — usually just one (e.g. `java` or `dotnet`), occasionally more for a plan spanning several languages. For each distinct key, capture a project-wide quality baseline by delegating to the `iru-gate-runner` agent rather than running that language's quality skill directly — use the matching `-code-quality` skill for the detected language/framework, e.g. `iru-java-code-quality` when the plan is Java (Checkstyle/PMD/SpotBugs), or `iru-dotnet-code-quality` when it's .NET (StyleCop.Analyzers/CA rules), or whichever other `-code-quality` skill matches a key found in this repository's `.claude/skills`: `Agent({description: "Capture code-quality baseline ()", subagent_type: "iru-gate-runner", prompt: "Invoke Skill({skill: \"-code-quality\"}) unscoped. Report back only the total issue count per tool and the per-file list of issues."})`. `iru-gate-runner` runs in its own separate context and is built to report back just the issue list rather than the full generated reports, keeping that content out of the main context window since only the resulting list of issues is needed here. Record each returned list, keyed by its language/framework, as that key's baseline — the final check in Step 7 compares each one back against its own key's baseline to judge whether the plan's work left overall code quality at least as good as it found it. Skip capturing a baseline for any key that has no matching `-code-quality` skill installed in this repository, and skip this baseline capture entirely if no language/framework key could be determined for the plan at all. Also capture a project-wide security baseline the same way, by delegating to `iru-gate-runner` rather than running `iru-check-security` directly: `Agent({description: "Capture security baseline", subagent_type: "iru-gate-runner", prompt: "Invoke Skill({skill: \"check-security\"}) unscoped, project-wide. Report back only the count and the per-file list of flagged secrets (new since the last `.secrets.baseline` update, plus any still lacking a triage label)."})`. As with the quality baseline, this keeps the raw scan output out of the main context window since only the resulting issue count/list is needed here. Record that returned count/list as the baseline the final check in Step 7 compares against — the goal is to catch any task in this run that introduces a new secret into the codebase, not to fix pre-existing findings this run didn't cause. If the sub-agent reports that `detect-secrets` could not be installed and the user chose to continue without scanning, record that security scanning is unavailable for this run, skip this and the corresponding Step 7 security check entirely, and say so plainly in the Step 9 summary rather than silently omitting it. Skip this baseline capture outright if the `iru-check-security` skill is unavailable in this repository. ## Step 4 — Implement task groups one at a time, in plan order Process task groups strictly in the order they appear in the plan (the `iru-plan` skill orders them so each is buildable on top of the previous one). Skip any group that is already fully done per Step 2. For each remaining group, invoke the `iru-code-one-task-group` skill via the `iru-isolated-skill-executor` agent rather than calling `Skill(...)` directly: ``` Agent({ description: "Implement task group ", subagent_type: "iru-isolated-skill-executor", prompt: "Invoke Skill({skill: \"code-one-task-group\", args: \"\"}). Report back, per task in the group: the files touched, tests added/updated, coverage achieved, the code-quality outcome (including any issue left in place as unavoidable and why), whether license-header generation was skipped, and whether the task stopped on a blocker instead of finishing.", run_in_background: false }) ``` `iru-code-one-task-group` determines each task's language/framework, dispatches it to the matching `-code-one-task-group` skill when one is installed (or implements it directly as a best effort otherwise), runs it in parallel across the group's tasks when the plan marked the group `Parallelizable: yes`, checks off each task/sub-task's box in `implementation_plan.md` as it completes, and notifies the user of that per-task/ sub-task progress itself — none of that bookkeeping needs to happen again here. Running it via `iru-isolated-skill-executor` keeps its own file reads/edits/reasoning out of `iru-code`'s own context, the same way the one-task skills used to be invoked directly; this matters most on a plan with many groups, since without this every group's full implementation transcript would accumulate in `iru-code`'s context across the whole run instead of staying flat regardless of plan size. Wait for the agent to finish (`run_in_background: false` — Step 5 needs its outcome before confirming the group's completion and moving on) before proceeding. If the invoked `iru-code-one-task-group` skill reports that one of the group's tasks stopped short on a blocker (a failing test that suggests the plan's approach itself is wrong, or an ambiguity only the user can resolve), treat it the same as if it happened here: don't treat the group as complete, surface the blocker to the user via `AskUserQuestion`, and stop rather than moving to the next group. If it reports the user chose to skip license-header generation for some task, respect that choice for the rest of this run — don't ask again on later groups. Once `iru-code-one-task-group` reports every task in the group finished cleanly, proceed to Step 5 for this group, then continue to the next unchecked group. ## Step 5 — Confirm the group's checkboxes and notify the user `iru-code-one-task-group` already checks off each task/sub-task's own box in `implementation_plan.md` (and any progress note) as it completes them — this skill does not re-write those lines. Immediately after a group clears Step 4: - Re-read `implementation_plan.md` and confirm every task/sub-task in the group is now checked (`[x]`). If any line in the group is still unchecked despite a clean report, treat that as inconsistent — re-invoke `iru-code-one-task-group` scoped to just the unfinished task(s) before moving on, rather than silently proceeding. - Notify the user that the group completed: name the group, the tasks it covered, the files touched overall, and the aggregate coverage/code-quality outcome across the group's tasks — in addition to the plan file already reflecting it. This progress notification happens after every group, not just at the end of the whole run. - Update the mirrored entry in the session task list (Step 3) to completed. ## Step 6 — When to interrupt the user Keep interruptions rare — by design, this skill should run start-to-finish unattended on a well-formed plan. Stop and use `AskUserQuestion` (or plain text if no real choice is being offered) only when: - The `iru-code-one-task-group` skill invoked in Step 4 reports that one of the group's tasks stopped on a blocker — a test that keeps failing after a genuine fix attempt where the failure suggests the plan's described approach is actually wrong or infeasible against the real code, or an ambiguity that changes correctness or scope and can't be safely inferred (conflicting instructions, a choice only the user can make, a missing decision). Mirror the bar used by the `iru-plan` skill's Step 4: don't ask about things with an obvious best-practice answer. - A tool call needs a permission outside this skill's `allowed-tools` list and the underlying action is risky or irreversible (e.g. anything beyond the scoped `mvn`/read-only `git` commands this skill is pre-approved for) — in this case the harness will already prompt; just make the case for why it's needed if asked. - `implementation_plan.md` already has every checkbox checked when a run starts — handled in Step 1, not here; don't redo finished work. Do not stop merely because a task is nontrivial — implement it. Do not check a task's box to move past a blocker; leave it unchecked and surface the blocker instead (and skip Step 8's documentation update and Step 9's archiving — an incomplete plan stays at the root so the next run can resume it). ## Step 7 — Final verification Once every checkbox is checked, confirm the whole build — not just the incrementally-tested pieces — is healthy by running the full local verification from `CLAUDE.md` via the `iru-gate-runner` agent, for the same reason as the other verification steps in Step 4: `Agent({description: "Run full local verification", subagent_type: "gate-runner", prompt: "Run `mvn clean jacoco:prepare-agent install jacoco:report javadoc:jar source:jar -P '!build-extras'`. If it succeeds, report back only that the build succeeded. If it fails, report back only the failing module/goal, the failure reason, and the relevant error output/stack trace."})`. Running this via `iru-gate-runner` keeps the verbose build output out of the main context window. If it fails, fix it (or, if it's a genuine blocker per Step 6, stop and surface it) — do not archive a plan behind a broken build. Re-invoke the same agent call after fixing, and repeat until it reports success. Then assess overall code quality against the baseline(s) captured in Step 3, once per distinct language/framework key found in the plan: 1. For each key a baseline was captured for in Step 3, run its project-wide quality check by delegating to the `iru-gate-runner` agent, for the same reason as the other quality checks in this skill: `Agent({description: "Compare final quality against baseline ()", subagent_type: "iru-gate-runner", prompt: "Invoke Skill({skill: \"-code-quality\"}) unscoped, project-wide. Compare the reported issues against this baseline: . Report back only the total issue count per tool and the per-file list of issues."})` — e.g. `iru-java-code-quality` for the `java` baseline, `iru-dotnet-code-quality` for the `dotnet` baseline. Running each via `iru-gate-runner` keeps the full reports out of the main context window. Compare each returned counts/per-file list against that same key's Step 3 baseline. 2. If, across every key checked, the total issue count did not increase and is zero (or was already zero at baseline and still is), overall quality is excellent — proceed to Step 8. 3. Otherwise — one or more keys leave the project with more issues than it started with, or a nonzero count persists for one or more of them — do not silently proceed. Use `AskUserQuestion` to tell the user what remains (counts and a short summary per tool, grouped by language/framework key if more than one is involved) and ask whether they want to: - add follow-up task(s) to `implementation_plan.md` to fix the remaining issues before this run archives it (if chosen, add the task(s) — as a new group — with empty checkboxes and return to Step 4 to implement them — do not archive yet), or - file the remaining issues as new GitHub issues instead (`gh issue create`, one issue per distinct problem or logical group, with enough detail — file, line, tool, message — to act on later), or - leave it as-is and proceed to archive without further action. Respect whichever the user picks; only proceed to Step 8 once this choice has been acted on (issues filed, or explicit acknowledgment to proceed as-is). 4. If no language/framework key could be determined for the plan, or none of the keys involved have a matching `-code-quality` skill installed in this repository, skip this quality assessment entirely and proceed directly to the security assessment below. If only some keys have a matching skill, assess just those and note in the Step 9 summary which key(s) were skipped for lacking one. Then assess security against the baseline captured in Step 3 (skip this entire assessment if Step 3 recorded that security scanning is unavailable for this run, or if the `iru-check-security` skill is unavailable in this repository): 1. Run the project-wide security check by delegating to the `iru-gate-runner` agent, for the same reason as the quality check above: `Agent({description: "Compare final security scan against baseline", subagent_type: "gate-runner", prompt: "Invoke Skill({skill: \"check-security\"}) unscoped, project-wide. Report back only the count and the per-file list of flagged secrets (new since the last `.secrets.baseline` update, plus any still lacking a triage label)."})`. Running this via `iru-gate-runner` keeps the raw scan output out of the main context window. Compare the returned count/per-file list against the Step 3 baseline. 2. If the count did not increase (zero flagged secrets beyond what Step 3 already recorded), security is clean — proceed to Step 8. 3. If the count increased — this run's tasks introduced a new secret, or left one newly unaudited — treat this as a hard stop, unlike the quality gate above: there is no "leave as-is and proceed" option here, since that risks committing a real credential. Use `AskUserQuestion` to show the user exactly what's new (file, line, secret type) and ask them to either: - remove or rotate the real secret(s) now, or - mark any false positives themselves via `detect-secrets audit .secrets.baseline` (this skill never performs that labeling on the user's behalf — see `iru-check-security`'s own Step 6), then re-run this security check (repeat from item 1) until it reports no increase. Do not proceed to Step 8 — do not check off, archive, or otherwise treat any task as complete — while an unresolved increase remains. This is what keeps a leaked secret from ever reaching a state that this skill, or any skill/session that picks up after it (e.g. `iru-pr-description`, `iru-issue`, or the user's own next `git commit`), could commit, push, or include in a pull request. 4. If the `iru-check-security` skill is unavailable in this repository, or Step 3 recorded that scanning was skipped for this run, skip this security assessment and proceed to Step 8 directly. ## Step 8 — Update documentation Once Step 7 passes clean (healthy build, and the quality and security gates both resolved), bring the project's Antora documentation in line with everything this run actually changed, by delegating to the `iru-update-docs` skill: `Skill({skill: "iru-update-docs"})`. Invoked with no argument, `iru-update-docs` covers uncommitted changes plus any commits already made on the current branch that aren't on the base branch — which is exactly this run's surface, since Step 9 hasn't committed or archived anything yet. That means it picks up every group processed across all of Step 4's iterations, not just the last one, so the docs reflect the plan's full scope rather than only its final group. - If this repository has no Antora documentation site, `iru-update-docs` should report that plainly rather than fail — treat that as nothing to do here and continue to Step 9. - If `iru-update-docs` needs to ask something only the user can resolve (per its own rules), let it surface via `AskUserQuestion` rather than guessing on its behalf. - Note what `iru-update-docs` changed (which pages, for which behavior) so it can be folded into the Step 9 summary alongside the code changes. Then continue to Step 9. ## Step 9 — Archive the plan and ask for review Only after Step 7 passes clean, with every task's checkbox checked, both the quality and security gates above resolved, and Step 8's documentation update done: 1. Determine an identifier for the archived filename: - If the plan was grounded in a GitHub issue (check the "Task summary" section and the plan's origin for an issue reference, e.g. "issue #42"), use that issue id. - Otherwise, use the current timestamp: `date +%Y%m%d%H%M%S`. 2. Create the archive directory if it doesn't exist yet (`mkdir -p .archive`), then move the plan there, renamed to embed that identifier: `mv implementation_plan.md .archive/implementation_plan_.md` (e.g. `.archive/implementation_plan_42.md` or `.archive/implementation_plan_20260707153000.md`). The repository root must no longer have an `implementation_plan.md` once this step completes successfully. 3. Summarize for the user: which groups/tasks were completed, the files touched overall, the coverage achieved per task/class, the final code-quality outcome (excellent / follow-up filed / issues left as-is per Step 7), the final security outcome (clean / not run, since a resolved-but-triggered gate is otherwise indistinguishable from clean once Step 7 passes), what Step 8 updated in the documentation (or that there was no documentation site to update), and where the plan was archived to. 4. Explicitly ask the user to review the code and documentation changes (e.g. `git diff` / `git status`) before anything is committed. Do not commit, push, or open a PR — this skill's job ends at working, tested, reviewable code. This applies with extra force if Step 7's security gate ever fired during this run: even though it must have been resolved to reach this point, remind the user to double-check the resolution (secret actually removed/rotated, or genuinely a false positive) before they or any subsequent skill commits, pushes, or opens a PR.