Files
Eric BellavanceandClaude Opus 5.5 1e895858d0 docs(kiro): use always inclusion for always-on steering files
Kiro only loads steering files automatically in every conversation when
they use `inclusion: always`; `auto` loads them only when the request
matches the description. Switch the always-on steering files to
`always` and update README, install.sh and docs accordingly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 13:23:13 -04:00

1.5 KiB

inclusion, name, description
inclusion name description
always coding-style Core coding style rules including immutability, file organization, error handling, and code quality standards.

Coding Style

Immutability (CRITICAL)

ALWAYS create new objects, NEVER mutate existing ones:

// Pseudocode
WRONG:  modify(original, field, value) → changes original in-place
CORRECT: update(original, field, value) → returns new copy with change

Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.

File Organization

MANY SMALL FILES > FEW LARGE FILES:

  • High cohesion, low coupling
  • 200-400 lines typical, 800 max
  • Extract utilities from large modules
  • Organize by feature/domain, not by type

Error Handling

ALWAYS handle errors comprehensively:

  • Handle errors explicitly at every level
  • Provide user-friendly error messages in UI-facing code
  • Log detailed error context on the server side
  • Never silently swallow errors

Input Validation

ALWAYS validate at system boundaries:

  • Validate all user input before processing
  • Use schema-based validation where available
  • Fail fast with clear error messages
  • Never trust external data (API responses, user input, file content)

Code Quality Checklist

Before marking work complete:

  • Code is readable and well-named
  • Functions are small (<50 lines)
  • Files are focused (<800 lines)
  • No deep nesting (>4 levels)
  • Proper error handling
  • No hardcoded values (use constants or config)
  • No mutation (immutable patterns used)