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.

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.

Used by

  • Issue — Step 6, when the user chooses automatic implementation over manual review, hands off the entire iru-code skill run so implementation starts from a clean context; iru-issue itself keeps running afterward to push the branch and open the pull request once this agent reports back.

  • Code — Step 4, once per plan task group, to invoke iru-code-one-task-group — since that skill hands back a self-contained summary, isolating it keeps `iru-code’s own context flat regardless of how many groups the plan has.

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

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

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.