| name | kiro-delegate |
| description | Claude plans and verifies, Kiro CLI implements on its own flat-rate subscription credits — a cost-savings implementation-delegation workflow, not a second opinion (see co-agent for that). Kiro implements inside an isolated git worktree; only the captured, scope-guarded diff ever reaches the main tree. Triggers on 'kiro한테 시켜서 구현', 'kiro로 구현', 'kiro한테 구현 위임', 'delegate implementation to kiro', 'kiro implement this'. For read-only review of a diff, use the /kiro:review command instead — this skill is write-capable (it commits) and deliberately does NOT own review triggers. |
| triggers | ["kiro한테 시켜서 구현","kiro로 구현","kiro한테 구현 위임","delegate implementation to kiro","kiro implement this"] |
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash","AskUserQuestion"] |
kiro-delegate — Cost-Savings Implementation Delegation
Claude (or Codex, in the Codex-plugin variant) plans, decomposes, and verifies. Kiro
CLI does the token-expensive part — writing the code and reviewing diffs — running on
its own flat-rate subscription credits instead of this session's budget. This is
deliberately not a multi-AI review/consensus tool (that's co-agent — different
goal: diversity of opinion, not cost). Kiro is delegated to because it's cheaper for the
work, not because a second opinion is wanted.
Full trust-boundary rationale, CLI adapter detail, and spec format: see
references/kiro-headless.md and references/spec-format.md. The orchestration
agent (agents/kiro-delegate-agent.md) carries the authoritative step-by-step pipeline
— this file routes intent and covers the commands.
This skill covers implementation delegation only; review is a separate command.
This skill (and kiro-delegate-agent) is write-capable — it plans, implements, and
commits — so its triggers are all explicit implementation-delegation phrasings.
Read-only review of a diff is the /kiro:review command (kiro_review.py), a
distinct entry point that never loads this write-capable skill. That separation is
structural (the review triggers are simply not in this skill's triggers: set), not a
prose convention — so a "review this with kiro" request can't accidentally activate the
implement-and-commit pipeline.
What "safe" means here — and what it doesn't (co-agent can't allow this at all)
co-agent:harness refuses Kiro as an implementer (SANDBOX_IMPLEMENTERS = codex, agy
only) because Kiro has no cwd-confined write sandbox. This plugin narrows the claim
rather than pretending the sandbox exists: only a change captured from inside the
assigned worktree, and within the plan's declared file set, can ever reach the main
tree — that is enforced by worktree.py capture-diff + scope_guard.py (the latter
checks the plan-wide union of every task's files, not a single task in isolation, so
per-task boundaries during a wave come from serializing implementer runs per file set,
not from scope_guard.py itself). It does not constrain what an auto-approved
execute_bash call can do to the rest of the host while Kiro is running (read
credentials, delete files outside the worktree) — running Kiro with execute_bash
trusted is a decision you make about kiro-cli itself, independent of this pipeline's
worktree/capture/scope-guard layers. See plugins/kiro/CLAUDE.md → "Trust decision"
before enabling default_delegate. Kiro never commits.
Commands
| Command | Purpose |
|---|
/kiro:setup | Detect kiro-cli, probe real usability, list available models, write .kiro/agents/{kiro-implementer,kiro-reviewer}.json, set default_delegate/review.on_commit |
/kiro:delegate <request> | Plan → spec → Kiro implements per task → Claude verifies + commits → delegation-rate report |
/kiro:review [paths...] | Run the same Kiro-powered review the pre-commit hook runs, on demand (default: staged changes) |
/kiro:configure | Inspect/change default_delegate, delegate/review models, parallel_tasks, max_fix_rounds, review.on_commit, review.block |
Pre-commit review (opt-in)
review.on_commit is off by default — the staged diff CONTENT is sent to Kiro's
backend, so enabling is a deliberate choice. The plugin-written kiro-reviewer agent
carries a tool-layer preToolUse guard that confines fs_read to the isolated temp
dir holding only the diff (a prompt-injection payload in an untrusted diff can't make
it read an unrelated path); if that agent file is missing or tampered, kiro_review.py
fails open and skips the review entirely by default rather than falling back
unguarded — this applies to both the automatic hook and the manual /kiro:review
command, since a warning printed right before an already-unguarded call runs isn't a
real chance to object to it. /kiro:review can still run unguarded, but only via an
explicit --allow-unguarded the command gates behind an AskUserQuestion confirmation
first. Turn the hook on via /kiro:setup or
/kiro:configure set review on_commit on. Once on, a
PreToolUse(Bash) hook runs before every git commit: it sends the staged diff to Kiro
on the configured review model (meant to be Kiro's strongest/newest —
/kiro:setup helps you pick one, e.g. gpt-5.6-sol) and blocks the commit (exit 2) only
on critical findings by default (review.block: critical | warning | none). It
fails open — a missing/timed-out/unauthenticated Kiro never blocks a commit; the
review is skipped and a warning is printed instead. Bypass a single commit with an
inline KIRO_REVIEW=off git commit ... prefix — the hook recognizes this literal
prefix in the command text itself (not the hook process's own environment, which a
same-line assignment never reaches; a separately-exported value from a prior command
also won't help, since shell state doesn't persist between Bash tool calls) — or turn
it off persistently with /kiro:configure set review on_commit off.
Delegate vs. review — different models, on purpose
- Delegate (implement) model —
delegate.model. Flat-rate CLI, so no per-token cost
trade-off; point it at whatever finishes tasks correctly (fewer fix-rounds = pure
wall-clock savings).
- Review model —
review.model. Deliberately kept at Kiro's strongest available
model even if the delegate model is lighter — the review is the safety net behind
whatever the implementer produced, so it shouldn't be the weak link.
Default-delegate mode
default_delegate (off by default) routes implementation requests through this
pipeline automatically, without needing a "delegate to kiro" trigger phrase — falling
back to Claude writing the code whenever Kiro is unavailable or exhausts its fix loop.
Set it from /kiro:setup or /kiro:configure set default_delegate on.
Never
- Never run Kiro with cwd = the repo root (or anything other than its assigned worktree)
in write mode.
- Never apply an uncaptured or unscoped patch to the main tree.
- Never let Kiro run
git commit/push/reset.
- Never let a stuck task silently drop work — it becomes a reported Claude fallback.
References
references/kiro-headless.md — CLI invocation, auth, trust boundary, model tieringreferences/spec-format.md — Kiro spec structure + tasks.md format the scripts parsescripts/worktree.py, scripts/scope_guard.py, scripts/parse_plan.py — copied
verbatim from co-agent (the isolation/scoping mechanics are identical; only the
implementer CLI differs)scripts/kiro_config.py — layered settings (kiro.defaults.json ← .claude/kiro.local.json,
gitignored by convention; if a consumer repo commits it anyway, its
default_delegate/review.on_commit values are ignored and fall back to off — a
committed file can't silently opt an installing user into diff egress or
auto-delegation)scripts/kiro_review.py — the Kiro-run review used by /kiro:review and the hookscripts/kiro_setup.py — probe, model listing, .kiro/agents/*.json generation
