Gap Analysis: Kiro by AWS

[don-petry]

Investigate and explore the capabilities offered by Kiro and compare to the current and envisioned capabilities of this repo to identify gaps and opportunities.

[github-actions[bot]]

Gap Analysis: Kiro by AWS — Enhancement

This analysis maps Kiro's capabilities against the current and envisioned capabilities of petry-projects/.github-private, identifies gaps and opportunities, and proposes a phased validation path.

---

1. Problem Framing

Kiro (launched May 2026) represents AWS's bet that the unit of agentic software work is a formal specification, not a prompt. It packages spec-driven development, event-driven agent hooks, steering rules, autonomous background agents, cloud automations (scheduled recurring tasks), and multi-repo coordination into a single platform — all backed by Bedrock model routing. The question is: where does this repo already match or exceed Kiro, where are there genuine gaps, and which gaps are worth closing for an internal DevX/agent-ops repo?

---

2. Prior Art & Competitive Landscape

Capability	Kiro	This Repo	Gap?
Spec-driven planning (requirements → design → task DAG)	Native: requirements.md → design.md → tasks.md with EARS notation; wave-based parallel task execution	Initiative planner pipeline: Discussion → plan.schema.json (epic + story DAG with blocked_by edges, acceptance criteria, open questions) → initiative driver releases stories to dev-lead	Partial parity. This repo's pipeline is more rigorous (JSON-schema-validated, critic-reviewed, human-gated), but lacks Kiro's bidirectional spec-sync (keeping specs and code in lockstep post-implementation).
Agent hooks (event-driven automation)	IDE-level: file save/create/delete triggers run agent prompts or shell commands; .kiro/hooks/ JSON; 8 trigger types including PreToolUse, PostToolUse, UserPromptSubmit	Workflow-level: dev-lead-intent.sh classifies GitHub events (CI failure, review comments, mentions, rebase conflicts) into intents; pr-review-sweep.yml re-dispatches on workflow_run	Different layer. Kiro hooks are developer-local (IDE events). This repo hooks are CI/CD events. Neither substitutes for the other. The gap is in pre-commit / pre-push developer-local agent hooks.
Steering rules (persistent project context)	.kiro/steering/ with inclusion: always|fileMatch|manual|auto; global ~/.kiro/steering/; YAML frontmatter; also reads AGENTS.md	CLAUDE.md + AGENTS.md + prompts/ library + per-tier prompt files (triage.md, deep-review.md, etc.)	Parity, arguably ahead. This repo's prompt library is more structured (tier-specific, model-aware). Kiro's inclusion: auto (description-based matching) is a nice ergonomic that CLAUDE.md lacks.
Multi-engine model routing	Bedrock-based: Claude Sonnet for specs, Amazon Nova for code gen	engine.sh: 3-provider (Claude/Copilot/Gemini), per-tier model chains, in-engine fallback before cross-provider fallback, token logging	Ahead. This repo's routing is more sophisticated (rate-limit cascading, per-tier timeout budgets, cost-aware tier selection).
Autonomous background agent	Kiro Autonomous Agent: describe a goal → agent plans, writes code, opens PRs, monitors CI, responds to review feedback; multi-repo	dev-lead agent: intent-classified event → fix CI / address reviews / fix issues / rebase; single-repo per invocation; human-gated initiative release	Partial gap. Kiro's autonomous agent handles the full lifecycle (plan → implement → PR → CI → review feedback loop) in one session. This repo splits it across multiple workflow runs with human gates. The gap is less about capability and more about session continuity — a single long-running agent context vs. stateless per-event invocations.
Cloud automations (scheduled recurring agent tasks)	Kiro web: up to 5 cron schedules per automation, multi-repo, sandbox execution, auto-PR	Workflow-level: feature-ideation.yml (weekly ideation), initiative-driver.yml (6h sweep), actions-fleet-monitor.yml, auto-rebase-health.yml, readme-refresh.yml, dependency-advisory.yml	Parity, arguably ahead. This repo has more scheduled automations, each purpose-built and battle-tested. Kiro's automations are more general-purpose but less mature.
Canary/ring rollout for agents	No equivalent — Kiro versions itself as a product, not per-agent	canary-rollout.sh: ring-staged, health-gated promotion with channel tags; auto-cut, drift detection, blocker issue triage, fleet-status dashboard	Significantly ahead. This is a genuine differentiator. Kiro has no safe self-hosting release strategy for agents that modify their own infrastructure.
Eval/quality gates	Kiro uses property-based testing and automated reasoning for requirements validation	evals/ directory with case schemas, judge prompts, held-out eval regression gates (Sonnet 5 >= Sonnet 4.6), eval-score-gated canary promotion	Ahead for agent quality. This repo's eval system gates agent promotions on measured quality. Kiro's validation is code-focused, not agent-behavior-focused.
MCP integration	Native: Kiro Powers marketplace, AWS-specific MCP servers (CDK, CloudFormation, pricing), dynamic activation	Opt-in: REVIEW_MCP_CONFIG in engine.sh, convention-based (.github/review-mcp.json), allowed-tools merge	Gap. Kiro's MCP is richer (marketplace of pre-packaged servers, dynamic activation). This repo's MCP is functional but minimal.
Multi-repo coordination	Native: single task spans multiple repos, creates PRs on each, reads across all	Not present — each workflow invocation is scoped to one repo; fleet operations iterate repos but don't coordinate cross-repo changes	Gap. For org-level automation, coordinated multi-repo changes (e.g. a breaking API change + all downstream consumers) would be valuable.
Security model	Isolated sandbox per session, configurable network/secrets/MCP access, never auto-merges	agent-shield.yml (immutable), holdout-guard.yml/sh (held-out path protection), push-protection, safety-checks.sh, human gates on initiative:auto	Parity, different emphasis. Kiro's is sandbox-isolation; this repo's is audit-trail + immutable guards + human gates. Both are strong.

---

3. Options Table — Actionable Gaps Worth Closing

#	Gap	Option A (Adapt from Kiro)	Option B (Build Native)	Recommendation
G1	Spec-sync (bidirectional spec↔code drift detection)	Adopt Kiro's approach: store specs alongside code, detect drift on save	Build a spec-drift.yml workflow: compare plan.schema.json stories' acceptance criteria against merged PR diffs; flag when an initiative's design doc diverges from what shipped	Option B. Already have the plan schema and initiative pipeline; a drift-detection workflow is a natural extension. Lower risk than introducing a new spec format.
G2	MCP server ecosystem for review tiers	Integrate Kiro's AWS MCP servers via the existing REVIEW_MCP_CONFIG	Curate a small registry of high-value MCP servers (Context7 for docs, a security-scanner server, a dependency-graph server) and document onboarding in AGENTS.md	Option B. The MCP plumbing exists in engine.sh. The gap is curation and documentation, not infrastructure.
G3	Multi-repo coordinated changes	Use Kiro Autonomous Agent for cross-repo tasks	Extend initiative-driver.sh to accept a target_repos list and open linked PRs across repos, with a shared epic tracking the cross-repo initiative	Option B. The initiative planner already supports target_repo. Extending the driver to multi-repo is incremental.
G4	Session continuity (long-running agent context)	N/A (Kiro's is proprietary)	Implement a lightweight state file (.dev-lead-session.json) that persists across workflow runs for a single initiative story, carrying forward context from prior attempts	Option B with caution. Biggest risk is state staleness. Start with a read-only context summary, not mutable state.
G5	Developer-local agent hooks (pre-commit spec enforcement)	Adopt Kiro's .kiro/hooks/ format	Ship a .claude/hooks/ or .github/hooks/ convention with Claude Code hooks (UserPromptSubmit, PreToolUse) that enforce steering rules locally	Evaluate. Claude Code already supports hooks in settings.json. The gap may be documentation and templates, not capability. Verify Claude Code hook coverage before building anything.

---

4. Risks & Unknowns

• Vendor lock-in risk: Kiro's deepest advantages (Powers marketplace, Bedrock routing, Autonomous Agent) are AWS-proprietary. Adopting Kiro patterns is fine; depending on Kiro infrastructure would conflict with this repo's multi-provider engine strategy.
• Spec-sync complexity: Bidirectional drift detection between natural-language specs and code is an unsolved hard problem. Kiro's implementation is opaque — it's unclear how well it handles refactors that legitimately diverge from the original spec. Start with one-way detection (spec → code) before attempting bidirectional.
• Multi-repo coordination blast radius: A single agent session modifying multiple repos simultaneously is powerful but dangerous. This repo's per-repo isolation with human gates is a deliberate safety choice. Any multi-repo extension must preserve the initiative:auto opt-in and per-repo holdout-guard protections.
• Session continuity vs. statelessness: Kiro's long-running sessions accumulate context but also accumulate hallucination risk. This repo's stateless per-event model is safer. A middle ground (read-only context summaries, not mutable shared state) balances both.

---

5. Phased Validation Path

Phase 0 — Audit (1 week): Verify Claude Code's current hook support against Kiro's 8 trigger types. Document which gaps are real vs. already covered. Check if inclusion: auto (description-based steering activation) is achievable with Claude Code skills.

Phase 1 — MCP Curation (2 weeks): Pick 2-3 high-value MCP servers, onboard them via the existing REVIEW_MCP_CONFIG convention, and measure review quality delta on 10 PRs. This is the lowest-risk, highest-signal experiment.

Phase 2 — Spec-Drift Detection (3 weeks): Build a spec-drift.yml workflow that runs post-merge and compares initiative story acceptance criteria against the merged diff. Surface drift as a Discussion comment on the source idea. No new spec format — reuse plan.schema.json.

Phase 3 — Multi-Repo Initiative Driver (4 weeks): Extend initiative-driver.sh to coordinate cross-repo stories within a single epic. Preserve per-repo initiative:auto gating. Pilot on a real cross-repo initiative (e.g. a shared library API change).

---

6. Success Metrics

Phase	Metric	Target
Phase 1 (MCP)	Review findings that cite external documentation (MCP-sourced)	≥ 20% of deep-review findings reference MCP context
Phase 2 (Spec-drift)	Spec-drift alerts on initiatives where shipped code diverged from plan	≥ 1 true-positive drift detection per month
Phase 3 (Multi-repo)	Cross-repo initiatives completed without manual coordination	≥ 1 cross-repo initiative fully driven by the pipeline

---

7. Key Takeaway

This repo is ahead of Kiro in model routing, canary rollout, eval-gated promotion, and scheduled automation maturity. Kiro's genuine advantages are in spec-code synchronization, MCP ecosystem richness, and multi-repo session coordination. The highest-value gaps to close are MCP curation (Phase 1) and spec-drift detection (Phase 2) — both build on existing infrastructure with minimal new risk.

Sources: Introducing Kiro, Kiro Autonomous Agent, Kiro Specs Docs, Kiro Steering Docs, Kiro Hooks Docs, Kiro Powers, Kiro Cloud Automations, Claude Code vs Kiro, AI Coding Agents 2026 Comparison, Kiro GitHub Action

[github-actions[bot]]

📋 Initiative planned by the BMAD Scrum Master (Bob).

Epic #1142 — Kiro gap-closure: reconcile the analysis, then ship spec-drift detection and scope multi-repo coordination

5 stories created (inert — labelled initiative, NOT initiative:auto):

• [Phase 0] Kiro capability reconciliation + gap decision record #1143 (M) — [Phase 0] Kiro capability reconciliation + gap decision record
• [Phase 1] Spec-drift detector script + pure-classifier unit tests #1144 (M) — [Phase 1] Spec-drift detector script + pure-classifier unit tests
• [Phase 1] Spec-drift frozen offline eval + tune to zero false positives #1145 (M) — [Phase 1] Spec-drift frozen offline eval + tune to zero false positives
• [Phase 1] Wire spec-drift.yml post-merge + advisory comment surface #1146 (M) — [Phase 1] Wire spec-drift.yml post-merge + advisory comment surface
• [Phase 2] Multi-repo initiative coordination — design-only spike #1147 (M) — [Phase 2] Multi-repo initiative coordination — design-only spike

Open questions for review:

• Spec-drift advisory surface: Story 4 posts the drift comment on the closed initiative story issue (and optionally its epic). The source analysis (Phase 2) suggested surfacing drift as a comment on the source Ideas Discussion instead. Confirm the preferred surface — story issue only, or also mirror onto the source Discussion — before building the Discussion path.

---

Review the epic and its sub-issue DAG, adjust as needed, then add initiative:auto to epic #1142 to hand it to initiative-driver for auto-implementation.