How to write a skill spec for egocentric data collection

A skill spec turns "collect egocentric data" into something you can measure cell by cell. It has five parts: the named skill, the geometry that must be visible, the condition budget in hours, the reject rule, and a single acceptance test. Everything else is commentary.

skill_id: kitchen/knife_dice
one_line: Dice an onion into ~8 mm cubes with a chef's knife.

must_contain:
  - both hands visible at grasp and at first cut
  - the board and the onion in frame for the whole episode
  - the completed pile in frame at episode end

conditions:
  daylight:      120 h
  low_light:      40 h        # evening kitchen, single overhead
  cluttered:      60 h        # counter left as found
  failure_cases:  20 h        # slips, roll-aways, recoveries

reject_if:
  - the cut is off-frame for more than 2 s
  - a second person's hands enter the manipulation region
  - depth invalid over 35 % of the board region

accept_metric: >
  A held-out reviewer can name the verb and noun from the
  first 15 frames without reading the label.

The reject rule is the part teams skip and the part that matters most. It is what lets a reviewer accept or reject a batch without a meeting.

A policy fails on the conditions it never saw, not on the ones it saw a lot of. Budgeting by condition cell — daylight, low light, cluttered, failure cases — means the coverage report tells you where the data is thin before training does. A single hour count hides exactly the gap that will hurt you.

Firsthand designs the first draft of the spec with you on a call, hands it back as a file for your repository, and reports fill rates against it per batch. Both sides look at the same document when a batch is accepted.