iru-code

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 `<key>-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 new tickets (on whichever tracker the plan originated from — a GitHub issue via `gh issue create`, or a Jira ticket via the `iru-create-jira-ticket` skill) 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 /. Track completion by checking those boxes — do not introduce a separate status tag or notation.