Skills are located in .agents/skills/.
If the change touches an area with a corresponding skill, read
that skill before the first Edit / Write of the turn and
report which skills you read in your reply, on one line, e.g.
Skills read: aiseed-conventions, flet-declarative, flet-component-basics.
Skipping this has produced real bugs in this repo — Flet API
mismatches (Dropdown.on_change vs on_select, FilePicker.on_result
that doesn't exist in 0.85), storing ft.Control instances in
use_ref, holding form inputs in Control.value instead of
use_state, etc. Every one of these was preventable by reading
the skill first.
"Read" means a Read / cat tool call that actually loads the
skill text into context for the current turn — not "I remember
this skill from a previous turn". Long sessions push earlier
context out of attention, so re-read each turn when the task
touches the relevant domain.
The selection table below tells you which skills apply to which kind of change.
aiseed-conventions— Project-wide rules and audience model (always first)flet-declarative— How to write Flet UI in this projectflet-component-basics— Flet 0.85+ entry point + @ft.component + hooksuser-action-fetch— When and how data is fetched (always relevant for views)first-run-setup— Setup screen and data source selection rulesecmwf-data-access— ECMWF Open Data + ERA5 (the data core)climatology-analysis— ERA5 climatology, anomalies, percentiles (the differentiator)jma-data-access— JMA radar + AMeDAS (Japan nowcast)weather-rendering— Synoptic-quality map renderingchart-base-design— Layered chart design (base / data / isoline / pill); pairs with weather-rendering for the visual-structure sidefigure-export— Publication-ready exports with provenanceopen-meteo-access— Supporting point-forecast feature (lower priority)
| Task | Read |
|---|---|
| Config loading / data source selection | conventions, first-run-setup |
| Map view rendering (ECMWF) | conventions, flet-declarative, flet-component-basics, user-action-fetch, ecmwf-data-access, weather-rendering, chart-base-design |
| Anomaly / climatology feature | conventions, flet-declarative, user-action-fetch, ecmwf-data-access, climatology-analysis, weather-rendering, chart-base-design |
| Radar / AMeDAS view | conventions, flet-declarative, user-action-fetch, jma-data-access, weather-rendering |
| Export to PNG/PDF | conventions, weather-rendering, figure-export |
| Point forecast view (Open-Meteo) | conventions, flet-declarative, flet-component-basics, user-action-fetch, open-meteo-access, chart-base-design |
| Pure UI layout with mocked data | conventions, flet-declarative, flet-component-basics |
| Backend service work | conventions + relevant data-access skill |
| New Flet app / new component file | flet-component-basics first, then flet-declarative |
Always read aiseed-conventions and flet-declarative.
Any task involving a view that displays data must also read user-action-fetch.
Any task that touches components/ or constructs Flet controls must read flet-declarative and (for new components) flet-component-basics.
The order matters for prioritization:
- The user picks data sources by editing
~/.config/aiseed-weather/config.tomlfor ECMWF/ERA5/Open-Meteo; JMA is per-feature (no config key) - Data fetches only on user actions (open view, press Refresh, change param)
- ECMWF + ERA5 + rendering + export is the product
- JMA radar + AMeDAS is the "Japan, right now" layer
- Open-Meteo is convenience, implement after the core works
- Climatology is what makes the tool unique — treat it as central, not as an add-on
Read the skill. The two-or-three minute cost is far less than the cost of implementing something against this project's conventions, or worse, shipping a figure without proper attribution.