# Workflow & Context Gathering

## Specs First

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