reframe

When to Use

The user is deciding what to build, or the request names a solution before it names the job. The frame playbook loads this skill.

What to do

Do not write code. Do not open a plan file. There is no separate spec skill. If they want a written plan after the frame is settled, load shape, which calls /plan.

Push until three things are named in the user's words:

1. The job. What changes for whom when this is done.
2. The user. Who hits the problem, and what they do today.
3. The smallest version. The least change that solves that job.

Disagree in the open. If the request solves a different job than the one they described, say so. If the evidence says the requested change is the wrong change, stop. Do not keep that change on the list as the recommendation.

Use clarify when a preference would change the design. Do not ask about facts you can read from the repo with read_file or search_files.

When the three names are stable, stop. The output is one short restatement. Do not expand it into a spec.

Load principles only when a design rule is what the disagreement is about. Apply the rule that changes the decision. Do not recite the list.