| name | dx-frame |
| description | Interview to settle the problem framing and alternatives for a change or effort before planning — writes frame.md. |
| disable-model-invocation | true |
| argument-hint | ["change-id or effort-id"] |
dx-frame
Settle the WHAT before the HOW. Run a deep interview on problem framing and alternatives for a change or effort, then write frame.md in its folder. The interview is the cure for misalignment — a perfect plan on the wrong problem loses the day. This makes the framing half explicit and skippable, so dx-plan can jump straight to solution design.
Guard. Resolve <id> under context/changes/ or context/efforts/. If it is missing, tell the user to run /dx-new first. If the path is under context/archive/, refuse — an archived container is done.
1 — Gather settled context
Read change.md (or effort.md) — note type. Read every existing research/<topic>.md, and diagnosis.md and brainstorm.md if present, as settled context; don't re-ask what research already answered. A brainstorm.md already chose the route and priced the do-nothing — deepen its ## Conclusion & route into a full framing rather than reopening it, and treat its ## Not doing as out of scope already decided. Read foundation/glossary.md for naming (a one-line habit — no section). Each artifact is a decision already made.
If the interview below surfaces a term that clashes with the glossary, is vague/overloaded, or finally gets pinned down, invoke dx-domain right then — don't just note it and keep talking.
2 — Interview (invoke dx-references with interview)
One question at a time, each offering a few concrete options with one recommended, walking the decision tree until the framing resolves. If the codebase or a research doc can answer a question, explore instead of asking. Scale the count down by whatever upstream already settled. Stay on the WHAT — the real problem and the alternatives — never solution design; that is dx-plan's job. Don't manufacture a reframe: "the initial framing was right" is a valid outcome.
If change.md's type is refactor (or this is a refactor effort), also invoke dx-references with module-design and frame in its vocabulary — deep vs shallow modules, seams, the deletion test.
3 — Write frame.md
Write it in the container's folder (context/changes/<id>/frame.md or context/efforts/<id>/frame.md), capturing:
- The real problem — one sentence, root not surface.
- Who / what it affects — the users, systems, or code touched.
- Alternatives considered — the framings weighed, and why the chosen one wins.
- Out of scope — what this explicitly does not address.
Keep it tight and scannable. No solution phases, no file changes — that is planning.
Done when
frame.md exists with those four sections; the container's updated: <today> is set. Then print and stop:
Frame written: context/{changes|efforts}/<id>/frame.md
Next: /dx-plan <id> (for a change)
or: /dx-roadmap <id> (for an effort)
Stop. Do not chain into another skill.
