Prompt file imported from y047aka/DeepSpaceNine-RTA-Chart (
.codex/prompts/kiro/steering-custom.md). Copyright stays with the author.
Kiro Custom Steering Creation
Create custom steering documents in .kiro/steering/ for specialized contexts beyond the three foundational files (product.md, tech.md, structure.md).
Current Steering Status
Existing Steering Documents
- Foundational steering files: Discover via list_dir/glob_file_search under
.kiro/steering/ - Custom steering count: Count non-core
.mdfiles in.kiro/steeringvia list_dir/glob_file_search
Project Analysis
- Specialized areas: Discover notable directories via glob_file_search (e.g.,
**/api/**,**/auth/**,**/security/**,**/test*/**,**/spec*/**) - Config patterns: Discover common config files via glob_file_search (e.g.,
*.config.*,*rc.*,.*rc)
Task: Create Custom Steering Document
You will create a new custom steering document based on user requirements. Common use cases include:
Common Custom Steering Types
-
API Standards (
api-standards.md)- REST/GraphQL conventions
- Error handling patterns
- Authentication/authorization approaches
- API versioning strategy
-
Testing Approach (
testing.md)- Test file organization
- Naming conventions for tests
- Mocking strategies
- Coverage requirements
- E2E vs unit vs integration testing
-
Code Style Guidelines (
code-style.md)- Language-specific conventions
- Formatting rules beyond linters
- Comment standards
- Function/variable naming patterns
- Code organization principles
-
Security Policies (
security.md)- Input validation requirements
- Authentication patterns
- Secrets management
- OWASP compliance guidelines
- Security review checklist
-
Database Conventions (
database.md)- Schema design patterns
- Migration strategies
- Query optimization guidelines
- Connection pooling settings
- Backup and recovery procedures
-
Performance Standards (
performance.md)- Load time requirements
- Memory usage limits
- Optimization techniques
- Caching strategies
- Monitoring and profiling
-
Deployment Workflow (
deployment.md)- CI/CD pipeline stages
- Environment configurations
- Release procedures
- Rollback strategies
- Health check requirements
Inclusion Mode Selection
Choose the inclusion mode based on how frequently and in what context this steering document should be referenced:
1. Always Included (Use sparingly for custom files)
- When to use: Universal standards that apply to ALL code (security policies, core conventions)
- Impact: Increases context size for every interaction
- Example:
security-standards.mdfor critical security requirements - Recommendation: Only use for truly universal guidelines
2. Conditional Inclusion (Recommended for most custom files)
- When to use: Domain-specific guidelines for particular file types or directories
- File patterns:
"*.test.js","src/api/**/*","**/auth/*","*.config.*" - Example:
testing-approach.mdonly loads when editing test files - Benefits: Relevant context without overwhelming general interactions
3. Manual Inclusion (Best for specialized contexts)
- When to use: Specialized knowledge needed occasionally
- Usage: Reference with
@filename.mdduring specific conversations - Example:
deployment-runbook.mdfor deployment-specific tasks - Benefits: Available when needed, doesn't clutter routine interactions
Document Structure Guidelines
Create the custom steering document with:
-
Clear Title and Purpose
- What aspect of the project this document covers
- When this guidance should be applied
-
Specific Guidelines
- Concrete rules and patterns to follow
- Rationale for important decisions
-
Code Examples
- Show correct implementation patterns
- Include counter-examples if helpful
-
Integration Points
- How this relates to other steering documents
- Dependencies or prerequisites
Security and Quality Guidelines
Security Requirements
- Never include sensitive data: No API keys, passwords, database URLs, secrets
- Review sensitive context: Avoid internal server names, private API endpoints
- Team access awareness: All steering content is shared with team members
Content Quality Standards
- Single responsibility: One steering file = one domain (don't mix API + database guidelines)
- Concrete examples: Include code snippets and real project examples
- Clear rationale: Explain WHY certain approaches are preferred
- Maintainable size: Target 2-3 minute read time per file
Instructions
-
Ask the user for:
- Document name (descriptive filename ending in .md)
- Topic/purpose of the custom steering
- Inclusion mode preference
- Specific patterns for conditional inclusion (if applicable)
-
Create the document in
.kiro/steering/with:- Clear, focused content (2-3 minute read)
- Practical examples
- Consistent formatting with other steering files
-
Document the inclusion mode by adding a comment at the top:
<!-- Inclusion Mode: Always | Conditional: "pattern" | Manual --> -
Validate that the document:
- Doesn't duplicate existing steering content
- Provides unique value for the specified context
- Follows markdown best practices
Remember: Custom steering documents should supplement, not replace, the foundational three files. They provide specialized context for specific aspects of your project. ultrathink
