— a single pass tends to smear them all together. The agent is trying to juggle everything in its head, and inevitably something gets dropped.
Elyra's @elyracode/subagents extension takes a gentler, more deliberate approach: it gives your main agent the ability to hand off focused little jobs to specialized child agents, each one with a narrow mandate and its own house rules.
Instead of one agent doing everything, you get a small cast of agents, each with a clear role:
Agent What it does scout Reads the codebase to understand structure, data flow, and risks. Never edits files. reviewer Reviews code for correctness, tests, security, and simplicity. Never edits files. planner Creates a concrete implementation plan with file paths and steps. Never edits files. worker Edits files and actually implements the plan. oracle Challenges assumptions and offers a second opinion. Never edits files. researcher Looks up documentation, specs, and external information. Never edits files. delegate A general-purpose agent for anything that doesn't fit the others.
Notice how most of them are read-only by design. That's intentional. A reviewer that can't edit files can't quietly "just fix it" when it spots a problem — it has to describe the issue clearly enough for the worker to act on. That little constraint, it turns out, produces much better feedback.
elyra install npm:@elyracode/subagents
That's the whole installation. The extension registers its tools, its commands, and a small skill file that teaches Elyra when delegating is the right move.
There's no special syntax to memorize. Just talk about delegation the way you'd talk to a colleague, and Elyra will pick the right agent:
Use scout to understand the payment flow before we touch anything.
Get a second opinion from oracle on whether this migration is safe.
Have reviewer check the auth changes for session fixation risks.
The bundled skill file teaches Elyra the delegation patterns, so it can read your intent and pick sensibly.
If you'd rather be explicit, the extension ships with a handful of commands:
/run <agent> <task> — Hand off a single task:
/run scout trace the data flow from checkout to payment processing
/run reviewer review the changes in src/auth/ for session fixation risks
/run planner plan how to add two-factor authentication
/agents — Lists the available agents and what each one does.
/parallel — Runs several agents on different angles of the same problem at once:
/parallel reviewer 'check correctness' -> reviewer 'check test coverage' -> reviewer 'check security'
This is lovely when you want several focused review passes instead of one broad sweep. Each reviewer gets a narrow mandate, so nothing slips through the cracks.
Some tasks follow a natural rhythm, and the extension ships with three predefined workflows that chain agents together for you.
/build-feature add a wallet system with balance tracking and transaction history
This walks through: scout (understand the codebase) → planner (draft an implementation plan) → oracle (poke holes in the plan) → worker (implement it) → reviewer (review the result) → worker (clean up the issues).
The scout goes first so the planner doesn't propose anything that fights with the existing architecture. The oracle catches risky assumptions before a single line of code is written. The reviewer catches the bugs that always sneak in afterward.
/deep-review the authentication system
This runs three review passes in sequence — one for correctness, one for test coverage, one for security — and then hands all three reports to the oracle for synthesis. What you get back is a single prioritized list of things actually worth fixing.
Compared to asking for a "full review," these focused passes tend to catch more. A reviewer looking only for security issues won't get distracted by formatting nits, and vice versa.
/ui-review build a settings page with profile editing
This one runs: worker (build the UI) → reviewer (check the visuals, accessibility, responsive behavior) → worker (fix what was found) → reviewer (verify the fixes).
The reviewer looks at contrast ratios, spacing, focus states, and how things behave at different screen sizes. If your project has a screenshot tool or a design system checker, the reviewer will reach for those too.
There's also a couple of commands for giving your changes a once-over before you push:
/git-review
This grabs the git diff and reviews it for correctness, security, missing tests, and accumulating debt. It finishes with a clear go/no-go verdict.
If you want it to happen on its own:
/setup-git-hook
That installs a .git/hooks/pre-push hook so Elyra's review runs before every push. If something looks off, the push is blocked. You can always slip past it with git push --no-verify when you really need to.
The quiet insight behind all of this is that constraints make agents better at their job. A read-only reviewer can't take the shortcut of "just fixing" the code — it has to explain itself. A planner that can't edit files has to produce a plan clear enough for someone else to follow. A scout that only reads and greps stays fast precisely because it's never tempted to start implementing.
It mirrors how good human teams work, really. You don't ask one person to architect, implement, review, and test a feature in a single sitting. You split the concerns, let each person focus on their piece, and bring it all together at the end.
The agents themselves are deliberately simple — each one is just a system prompt, a tool allowlist, and a read-only flag. No elaborate orchestration framework lurking underneath. The parent Elyra session coordinates everything, and each child agent does its narrow task and reports back.
Install the extension, try /run scout on a corner of your codebase you haven't visited in a while, and see what turns up. Then point /deep-review at your most critical module. The focused passes have a way of surfacing things a broad "review this code" prompt would have walked right past.
elyra install npm:@elyracode/subagents