Isolated Skill Executor

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

A custom agent that runs a single named skill end to end in a completely fresh context — no memory of the caller’s prior conversation — so an earlier exploration/planning transcript can’t bias the run, while the caller keeps executing afterward.

Purpose

iru-isolated-skill-executor formalizes a delegation shape distinct from Gate Runner: instead of isolating a single verbose report, it isolates an entire multi-step skill run from everything that happened before it in the conversation. This matters when a heavyweight skill like iru-code is about to execute a plan — carrying the whole iru-explore/iru-plan transcript into that execution would waste context and risk anchoring the implementation on intermediate exploration detail rather than the finished plan. Running the skill in a sub-agent achieves that fresh start without clearing the calling skill’s own conversation, which would stop it from being able to keep running afterward (e.g. to open a pull request once implementation finishes).

It also tracks any explicit gate/hard-stop condition the caller names in its prompt (e.g. whether iru-code’s security gate, backed by `iru-check-security, ever fired during the run) and reports that condition as its own field, separate from ordinary completion or failure — since the caller may need to treat it as disqualifying even if the delegated skill went on to resolve it and finish cleanly.

Plugin

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

Tools

Inherits full tool access (no restriction) — the delegated skill may itself need anything from Bash and Edit/Write to further Skill/Agent delegation, so this agent cannot be scoped narrower than the skills it might be asked to run.

The agent is pinned to model: inherit. Callers dispatch it as subagent_type: "iru-isolated-skill-executor" when it is installed under .claude/agents/, or as "iru-core:iru-isolated-skill-executor" when it is installed through the iru-core plugin (use whichever name appears in the available agent types).

Used by

  • Issue — Step 6, runs the whole iru-code skill in a fresh context.

  • Code — Step 4, one per task group to run iru-code-one-task-group.

  • Java Code One Task Group and .NET Code One Task Group — once per task in a bucket (potentially many at once, in parallel, when the group is marked parallelizable), to invoke the matching <key>-code-one-task skill — since that skill always re-checks the current code state from disk itself and hands back a self-contained summary, isolating it keeps the caller’s own context flat regardless of how many tasks the bucket has.

  • Rust Code One Task Group and Go Code One Task Group — once per task in a bucket, to invoke iru-rust-code-one-task / iru-go-code-one-task, the same way as the Java/.NET groups.

  • Setup CLI Repository — runs the scaffold, changelog and readme sub-skills of a command-line tool repository in fresh contexts.

  • Java Spring Boot Code One Task Group — once per task in a bucket (many at once when the group is marked parallelizable) to invoke iru-java-springboot-code-one-task, for the same reason as its Java/.NET siblings: that skill re-resolves the target module and the current code state from disk itself and hands back a self-contained summary, so isolating it keeps the caller’s context flat however many tasks the bucket has.

  • TypeScript Code One Task Group, Android Code One Task Group, and Swift Code One Task Group — Step 2, once per task in a bucket, to invoke the matching <key>-code-one-task skill in a fresh context, concurrently when the bucket is marked parallelizable — the same reason as their Java/.NET/Spring Boot siblings above.

  • KMP Code One Task Group and React Native Code One Task Group — Step 2, once per task in a bucket, to invoke iru-kmp-code-one-task / iru-react-native-code-one-task in a fresh context, concurrently when the bucket is marked parallelizable — the same reason as their siblings above.

  • Setup Repository — Step 4, runs the chosen stack orchestrator in a fresh context.

  • Setup KMP Repository — Steps 4–9, once per each of the six bootstrap skills it chains (iru-setup-kmp-app, iru-setup-antora, iru-setup-kmp-gitignore, iru-setup-kmp-github-workflows, iru-setup-changelog, iru-setup-readme), since each re-derives what it needs from the filesystem.

  • Setup Java Library Repository — Steps 3–8, once per each of the six bootstrap skills it orchestrates, since every one of them re-derives what it needs from the filesystem rather than from anything said earlier in the conversation.

  • Setup Java Spring Boot — Step 8, one per sub-skill so its output stays out of context.

  • Setup TypeScript Repository — Step 5-10, runs each sub-skill in a fresh context.

  • Kotlin Spring Boot Code One Task Group — Step 2, one agent per task.

  • NestJS Code One Task Group — Step 2, one agent per task, in parallel when allowed.

  • Next.js Code One Task Group — Step 2, one agent per task.

  • PHP Code One Task Group — Step 2, one agent per task, in parallel when allowed.

  • Quarkus Code One Task Group — Step 2, one agent per task.

  • Setup PHP Repository — Step 5-10, runs each sub-skill in a fresh context.

  • Setup Quarkus Repository — Step 3-8, one per sub-skill to keep transcripts out of context.

  • Django Code One Task Group, FastAPI Code One Task Group and Windows Code One Task Group — Step 2, once per task in a bucket, to invoke the matching <key>-code-one-task skill in a fresh context, in parallel when allowed.

  • Setup macOS Repository, Setup Python Repository and Setup Windows Repository — run each bootstrap sub-skill in a fresh context.

  • Spring Boot Rolling Deployments — delegates each enable/disable sub-step in order, keeping their output out of the caller’s context.

  • Setup Android Repository — spawned once per sub-skill (Steps 4–9), so all six sub-skills' own exploration/file-read transcripts don’t accumulate in this orchestrator’s context over the course of a single bootstrap run.

  • Setup Swift Repository — spawned once per sub-skill (Steps 5–10), so all six sub-skills' own exploration/file-read transcripts don’t accumulate in this orchestrator’s context over the course of a single bootstrap run.

Why this one specifically

The point of this delegation isn’t to suppress a verbose report (that’s iru-gate-runner’s job) — it’s to prevent context contamination from an earlier phase of the same overall task, while letting the orchestrating skill resume control afterward. A plain `general-purpose sub-agent could do this mechanically, but naming the pattern lets its system prompt bake in the specific obligation to track and report a caller-named gate condition explicitly, rather than every caller re-explaining that nuance in its own prompt.

Source

isolated-skill-executor.md on GitHub — the file this page was generated from.