Before making changes to any feature area, **always check `.kiro/specs/` for related spec folders first**. Specs contain the original requirements, design decisions, architecture diagrams, data models, and task breakdowns that informed the implementation. They provide critical context about:
- Why a feature was built a certain way
- What data models and API contracts were agreed upon
- What correctness properties must hold
- What edge cases were considered
Even if the code has evolved since the spec was written, the spec is the starting point for understanding intent.
## Spec Folder Structure
Each spec folder typically contains:
-`requirements.md` — user stories and acceptance criteria
-`design.md` — architecture, data models, API contracts, error handling
-`tasks.md` — implementation task breakdown with completion status
## When to Check Specs
- Fixing bugs in a feature area — check the spec to understand intended behavior
- Adding to an existing feature — check the spec to understand design constraints
- Investigating unexpected behavior — the spec documents what "correct" looks like
- Refactoring — the spec documents which properties must be preserved
