Feedback

The user's feedback is a claim about the system, not an instruction. Your job is to find out what the system actually does and why, agree with the user on what is really wrong, and only then file work an agent can pick up cold. Three stages: verify, clarify, file.

Shape the input

Feedback arrives loose: "onboarding isn't usable because the form resets, errors are vague and it's too slow". Scoping it is the user's job; splitting it is yours.

• Name the area in a short slug (onboarding). It becomes the label in stage 3.
• Number the points (P1, P2, P3), keeping the user's own words for each.
• A jam.dev/c/… link is a recording of the points. Read it before verifying and tie each point to its moment, following references/recordings.md.

Don't ask the user to restructure anything. If something is too vague to verify, that is a stage 1 result, not a reason to stop.