28 lines
1.2 KiB
Markdown
28 lines
1.2 KiB
Markdown
|
# 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
|