Requirement Convergence

SkillMedia

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.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Requirement Convergence skill

What this skill tells your AI

The instructions your AI receives, as published by shinpr/claude-code-workflows in skills/requirement-convergence/SKILL.md and read by ahel’s review.

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

FieldPass condition
outcomeOne 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.
costA 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 a readiness label: ready, weak, or weak-but-explicit (weak, and the user agreed to leave it unresolved). Only the user sets weak-but-explicit. Requirements are converged when every applicable field is ready or weak-but-explicit.

Judgment rules per field: references/criteria.md.

Hearing Protocol

Run the hearing after scope analysis has produced the facts needed to judge the convergence fields. The workflow using this skill owns the interaction method and routing; this skill defines the hearing content and pass conditions.

Register these steps before starting and record each step's evidence as it completes:

StepActionCompletion evidence
1State the scope facts the analysis produced, then separately what they imply for the requirementFacts listed with the analysis output they came from
2Ask about the fields below ready, at most two questions per messageOne question per field below ready
3Record each answer as that field's valueThe value uses wording the user supplied, not wording the hearing offered
4Re-ask once when a recorded value still fails its pass condition, then mark the field weak-but-explicit when the user agrees to leave the second answer as it standsTwo recorded answers, or the user's agreement to stop
5Hand the record to the step that judges the fieldsAn updated record returned from that step

Step 3's evidence is what keeps the hearing reviewable: a value restating the hearing's own candidates fails it, so the user's judgment survives however the question was put.

Storage Protocol

CarrierHoldsWritten by
The convergence record in the judging step's outputEvery field with its readiness labelThe judging step
PRD Success Criteria and Future / Out of Scopeoutcome; user-authored nonGoalsThe PRD production step
Design Doc Requirement ConvergenceThe same when no PRD exists, and the fields left weak-but-explicit in every caseThe Design Doc production step

A flow that produces neither document carries the record in its own context to the next step.

Reference Protocol (For Downstream Consumers)

  1. Read the convergence record from the prompt.
  2. Treat nonGoals as excluded from the current change and desired-future requirements as buildable scope. Evaluation requests, speculative ideas, and prescribed mechanisms that were not promoted create no downstream obligation; an accepted ADR may retain evaluated options as decision history.
  3. Treat a weak-but-explicit field as a recorded open question rather than a settled decision. When work depends on it, return the missing decision and its effect to the owning workflow.

Quality Checklist

  • Scope facts were presented before questions were asked
  • nonGoals came from the user, or the user stated there are none
  • Every applicable field is ready, or weak-but-explicit by the user's agreement

References

  • references/criteria.md — judgment rules per field, cost inputs, challenge intensity, solution-in-disguise test

Signals

GitHub stars
681
Forks
102
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
requirement-convergence-shinpr
Source
github.com/shinpr/claude-code-workflows