| name | requirement-convergence |
| description | Separates the outcome a change must produce from the requirements proposed to reach it, records what the user excluded, and bands cost from structure. Use when a requirement enters a workflow, before design begins, or when "how far do we go/what's out of scope/is this worth it" is mentioned. |
Requirement Convergence
Purpose
Requirements arrive bloated, ambiguous, or aimed at the wrong outcome. A capable model reconciles all three into a coherent plan and builds it faithfully — delivering exactly what was asked for when what was asked for was wrong.
This skill converges what to build. How to build it, and which documents the change requires, are settled after the what is.
Convergence Fields
| Field | Pass condition |
|---|
outcome | One observable result. A requirement that does not serve it is excess. |
requirements[] | Every build-relevant item labeled current-state or desired-future. |
nonGoals[] | Authored by the user, or the user stated there are none. |
cost | A band with the structural evidence that places it, plus the unknowns that remain. |
cost is a rough band, not the effort estimate a work plan schedules against; requirements cannot support person-days. Its unknowns carry more decision weight than its size.
Keep request signals classified as evaluation requests, speculative ideas, or prescribed mechanisms in active convergence context as judgment-only candidates. requirements[] and durable documents receive a candidate only after explicit user confirmation.
Each field carries its own readiness label: , , or (weak, and the user agreed to leave it unresolved). Only the user sets . Requirements are converged when every applicable field is or .
