How I Turned Kiro CLI Into a Principal-Level Engineering Partner with Skills and Steering Files

I'm a Principal Platform Engineer at a financial services company. I use Kiro CLI 8+ hours a day — not as a code completion tool, but as my primary engineering interface. Over the past two months, I've shaped it into something that catches production bugs before they ship, enforces TDD discipline when I'm tired, and orchestrates parallel work across multiple codebases.

Today I'm open-sourcing the entire framework: kiro-skills-library — 27 skills, 4 steering files, and an MCP integration guide.

Here's what I learned building it.

The Problem: AI Assistants Don't Have Discipline

Out of the box, AI coding assistants are eager to please. Ask them to "add a feature" and they'll jump straight to code. No design discussion. No tests first. No verification that it actually works. No branch created before the first edit.

That's fine for toy projects. In production — where a silently truncated LLM response can make 266 validation rules all return REVIEW_REQUIRED — you need discipline.

The Solution: Skills as Encoded Workflows

Kiro skills are markdown files that activate based on context. They're not prompts — they're workflow definitions that Kiro follows step by step.

Here's the key insight: skills encode the engineering practices you want to follow but sometimes skip under pressure.

Example: The Workflow Chain

Every non-trivial change follows this chain:

brainstorming → writing-plans → subagent-driven-development → verification-phase → finishing-a-development-branch

Each link is a skill. Each skill has explicit steps, checklists, and exit criteria. You can't skip verification because the skill won't let you claim "done" without proving it.

Example: Verification Phase

My verification-phase skill dispatches a panel of 4-6 expert reviewers in parallel — security, performance, test coverage, spec compliance, plus domain-specific experts chosen dynamically. They run with fresh context (no bias from the implementation session), then a synthesis pass deduplicates findings and produces a go/no-go verdict.

This caught a critical bug before it shipped: a single-batch LLM mode that would have silently truncated JSON responses in production, making the entire engine non-functional. The code "worked" — tests passed — but the verification panel spotted the token limit math didn't add up.

Example: Grill Me

Sometimes you don't need full brainstorming ceremony. You just want someone to poke holes in your plan. The grill-me skill does exactly that — relentless questioning without the overhead.

Steering Files: Shaping Every Interaction

Skills activate for specific tasks. Steering files shape every interaction. They're always-on context that defines how Kiro behaves.

Workflow Tiers

Not every change needs the same ceremony:

This prevents over-engineering simple fixes AND under-planning complex ones.

Context Window Protection

A single terraform plan can dump 50KB into your context window. My context-mode-routing.md steering file enforces rules:

• Shell output >20 lines → sandbox execution (only summaries enter context)
• File reads for analysis → process in sandbox, return findings only
• HTTP requests → fetch and index, search later

Without this, I was burning 30% of my context on raw command output.

HTML Output

Reports, analyses, and comparisons get generated as self-contained HTML files — dark mode aware, responsive, information-dense with collapsible sections. Instead of dumping 200 lines of markdown in chat, Kiro writes a file and tells me the path. I open it in a browser and get a polished result.

Self-Correction: The Secret Sauce

The most powerful pattern isn't any single skill — it's the self-correction loop in my steering file:

On correction → suggest concrete steering file update. Don't add rules speculatively.

Every time Kiro makes a mistake, it proposes a rule to prevent recurrence. Over two months, this has accumulated into a set of "hard rules" that represent every lesson learned:

• Never assume state — verify before claiming
• Code-review skill before creating any PR (no exceptions)
• No commits to main — worktree/branch first
• After fixing a PR review comment → reply AND resolve the conversation

These aren't theoretical best practices. They're scars from real production incidents.

The Numbers

• 27 skills covering the full development lifecycle
• 4 steering files shaping every interaction
• 4,200+ tests in the primary project built entirely through this workflow
• 14 engineers onboarded to Kiro at my organization using these patterns
• 2 months of daily production use refining the framework

What I Built With This

Using this framework daily, I've:

• Built an LLM-powered document validation engine from scratch (Python, AWS Bedrock, 4,200+ tests)
• Managed multi-account AWS infrastructure via Terraform + Digger CI
• Automated production log triage (OpenSearch → deduplicate → parallel RCA → Jira tickets)
• Investigated and executed a GitHub → Forgejo migration assessment
• Onboarded 14 engineers who report overwhelmingly positive productivity impact

Getting Started

git clone https://github.com/jacksonwilliamsva/kiro-skills-library.git

# Symlink skills you want
ln -s /path/to/kiro-skills-library/skills/verification-phase ~/.kiro/skills/

# Copy steering files
cp kiro-skills-library/steering/*.md ~/.kiro/steering/

Start with these three:

1. systematic-debugging — transforms how you approach bugs
2. verification-before-completion — stops you claiming "done" prematurely
3. workflow-principles.md steering file — gives structure to every session

What's Next

I'm working on:

• A sanitized version of my weekly log review skill (OpenSearch → Jira automation)
• More MCP integration guides (Ogham persistent memory, Atlassian Rovo)
• Enterprise adoption patterns from onboarding 14 engineers

If you're using Kiro and want to go beyond basic code completion, the repo is MIT licensed. PRs welcome.