Kiro is a closed commercial product. Verbatim system prompts from the IDE are not publicly available. However, the canonical spec file formats, steering file structure, and community-documented prompting techniques are all public and are documented here with verbatim examples.
From the official Kiro repo at .kiro/specs/github-issue-automation/requirements.md:
# Requirements Document
## Introduction
This specification defines an automated GitHub issue management system for the Kiro repository.
The system will use AWS Bedrock's Claude Sonnet 4.5 model to intelligently categorize issues,
detect duplicates, and manage issue lifecycle through automated workflows.
## Glossary
- **Issue_Manager**: The automated system that processes GitHub issues (implemented in TypeScript)
- **Bedrock_Classifier**: The AWS Bedrock Claude Sonnet 4.5 model used for intelligent classification
- **Duplicate_Detector**: The component that identifies duplicate issues using AI
## Requirements
### Requirement 1: Automatic Label Assignment
**User Story:** As a repository maintainer, I want issues to be automatically labeled when created,
so that I can quickly identify and prioritize issues without manual categorization.
#### Acceptance Criteria
1. WHEN a new issue is created, THE Issue_Manager SHALL analyze the issue title and body using Bedrock_Classifier
2. WHEN the analysis is complete, THE Label_Assigner SHALL assign relevant feature/component labels from the predefined set
3. WHEN the analysis is complete, THE Label_Assigner SHALL assign relevant OS-specific labels if applicable
4. WHEN the analysis is complete, THE Label_Assigner SHALL assign relevant theme labels based on issue category
5. WHEN labels are assigned, THE Issue_Manager SHALL add the "pending-triage" label to indicate maintainer review is needed
6. WHEN label assignment fails, THE Issue_Manager SHALL log the error and continue without blocking issue creation
### Requirement 2: Duplicate Issue Detection
**User Story:** As a repository maintainer, I want duplicate issues to be automatically identified,
so that I can consolidate discussions and avoid fragmented conversations.
#### Acceptance Criteria
1. WHEN a new issue is created, THE Duplicate_Detector SHALL search for similar existing issues using Bedrock_Classifier
2. WHEN similar issues are found with high confidence (>80%), THE Duplicate_Detector SHALL add a comment listing the potential duplicates
3. WHEN duplicate issues are identified, THE Issue_Manager SHALL add the "duplicate" label to the new issue
4. WHEN no duplicates are found, THE Issue_Manager SHALL proceed without adding duplicate-related comments or labels
5. WHEN the duplicate detection analysis completes, THE comment SHALL include links to all identified duplicate issues with similarity scores
Key structural pattern:
## Introduction — scoped natural language description## Glossary — defines named actors/components (capitalized, used in EARS clauses)### Requirement N: Title — numbered requirements**User Story:** — "As a [role], I want [goal], so that [benefit]"#### Acceptance Criteria — numbered list of EARS clauses- EARS format:
WHEN [event], THE [Actor] SHALL [response]
From .kiro/specs/github-issue-automation/tasks.md:
# Implementation Plan: GitHub Issue Automation
## Overview
This implementation plan breaks down the GitHub issue automation system into discrete, manageable tasks.
The system will be built incrementally using TypeScript, starting with core infrastructure,
then adding AI-powered classification, duplicate detection, and finally the automated lifecycle management workflows.
## Tasks
- [x] 1. Set up project structure and dependencies
- Create `scripts/` directory for TypeScript modules
- Create `package.json` with dependencies: @aws-sdk/client-bedrock-runtime, @octokit/rest, fast-check
- Create `tsconfig.json` for TypeScript configuration
- Set up Node.js environment configuration
- _Requirements: 5.1, 5.2_
- [ ] 2. Implement core data models
- [x] 2.1 Create data models module (`data_models.ts`)
- Implement `ClassificationResult` interface
- Implement `DuplicateMatch` interface
- Implement `LabelTaxonomy` interface with all label categories
- Export DEFAULT_LABEL_TAXONOMY constant
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
- [ ]* 2.2 Write unit tests for data models
- Test interface type checking
- Test DEFAULT_LABEL_TAXONOMY contains all required labels
- Test edge cases (empty values, undefined handling)
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
- [ ] 5. Checkpoint - Core classification working
- Ensure all tests pass, ask the user if questions arise.
Key structural patterns:
- [x] / - [ ] — progress tracking (checked = complete)- [ ]* — asterisk denotes optional/deferred task- Hierarchical numbering:
1, 1.1, 1.2, 2, 2.1, etc.
- Implementation details as sub-bullets under each task
_Requirements: X.Y, Z.W_ — traceability links back to requirements.md- "Checkpoint" tasks with explicit human review gates
From .kiro/specs/github-issue-automation/design.md (first 80 lines):
# Design Document: GitHub Issue Automation
## Overview
This design describes an automated GitHub issue management system that leverages AWS Bedrock's
Claude Sonnet 4.5 model for intelligent issue classification, duplicate detection, and lifecycle management.
The automation handles four primary workflows:
1. **Issue Triage** - Automatically labels new issues and detects duplicates
2. **Duplicate Closure** - Closes confirmed duplicate issues after a grace period
3. **Stale Issue Management** - Closes inactive issues awaiting user response
4. **Label Management** - Ensures label taxonomy is properly maintained
## Architecture
### High-Level Architecture
```mermaid
graph TB
A[New Issue Created] --> B[Issue Triage Workflow]
B --> C[Bedrock Classifier]
C --> D[Label Assignment]
C --> E[Duplicate Detection]
...
Component Architecture
- GitHub Actions Workflows - Orchestration layer
- Bedrock Integration Module - TypeScript module interfacing with AWS Bedrock API
- Label Assignment Module - Analyzes AI output and applies appropriate labels
- Duplicate Detection Module - Compares issues and identifies duplicates
- Issue Lifecycle Manager - Handles closing of duplicate and stale issues
Components and Interfaces
1. Issue Triage Workflow
File: .github/workflows/issue-triage.yml
Trigger: issues event with opened action
Responsibilities: [...]
Environment Variables: [...]
Outputs: [...]
2. Bedrock Classifier Module
File: scripts/classify_issue.ts
Interface:
async function classifyIssue(
issueTitle: string,
issueBody: string,
labelTaxonomy: LabelTaxonomy
): Promise<ClassificationResult>
Bedrock API Configuration:
- Model ID:
us.anthropic.claude-sonnet-4-20250514-v1:0
- Temperature: 0.3 (for consistent classification)
Prompt Structure:
You are an expert GitHub issue classifier for the Kiro project.
Analyze the following issue and recommend appropriate labels from the taxonomy below.
ISSUE TITLE: {title}
ISSUE BODY: {body}
LABEL TAXONOMY: {taxonomy}
Provide your response in JSON format:
{
"labels": ["label1", "label2", ...],
"confidence": {"label1": 0.95, ...},
"reasoning": "Brief explanation of label choices"
}
**Key structural patterns:**
- `## Overview` — summary paragraph
- `## Architecture` — Mermaid diagrams + numbered component list
- `## Components and Interfaces` — one subsection per component with file path, trigger, TypeScript interfaces, environment variables
- Embedded code blocks for interfaces, prompt templates, configuration
---
## Excerpt 4: Steering File Format
From `jasonkneen/kiro` repo at `.kiro/steering/steering-creation-guide.md`:
```markdown
---
inclusion: manual
---
# Steering Document Creation and Usage Guide
## What Are Steering Documents?
Steering documents are contextual guidelines that influence how I approach development tasks.
They contain project-specific standards, conventions, and best practices that help me provide
more relevant and consistent assistance.
## How Steering Documents Work
### Inclusion Mechanisms
1. **Always Included (Default)**: Documents without front-matter are included in every interaction
2. **File Match Conditional**: Documents with `inclusion: fileMatch` and `fileMatchPattern` are
included when specific files are in context
3. **Manual Inclusion**: Documents with `inclusion: manual` are only included when explicitly
referenced with `#steering-name`
### Content Structure I Follow:
```markdown
---
inclusion: [always|fileMatch|manual]
fileMatchPattern: 'pattern' # if fileMatch
---
# Clear Title
## Organized Sections
- Specific, actionable guidelines
- Code examples where relevant
- Reference to external files using #[[file:path]]
---
## Excerpt 5: EARS Notation Reference (from jasonkneen SKILL.md)
This is the canonical EARS format documentation used in Kiro's spec methodology:
```markdown
**EARS Format Patterns:**
WHEN [event] THEN [system] SHALL [response]
IF [precondition] THEN [system] SHALL [response]
WHEN [event] AND [condition] THEN [system] SHALL [response]
**Example:**
**User Story:** As a new user, I want to create an account, so that I can access personalized features.
**Acceptance Criteria:**
1. WHEN user provides valid email and password THEN system SHALL create new account
2. WHEN user provides existing email THEN system SHALL display "email already registered" error
3. WHEN user provides password shorter than 8 characters THEN system SHALL display "password too short" error
4. WHEN account creation succeeds THEN system SHALL send confirmation email
Key prompting technique: EARS forces declarative, event-driven phrasing. Each criterion is independently verifiable and maps directly to a test case. The named Glossary actors (capitalized) carry through from requirements.md into design.md and tasks.md, creating a consistent vocabulary across all three artifacts.
Note on System Prompts
Kiro's internal IDE system prompts are proprietary and not publicly disclosed. The blog post series on kiro.dev/blog covers architectural decisions (AST-based editing, program analysis for safe refactoring) but does not quote system prompts. The community repo jasonkneen/kiro is described as "Complete System Prompts for Kiro IDE by Amazon" but this appears to be a community-reconstructed set of prompts/skills, not official internal prompts. The formats documented above (requirements.md, design.md, tasks.md, steering file front matter) represent the full public specification of Kiro's artifact formats.