Issue complexity
Read an issue and return one level, low, medium or high, with a short justification.
Nothing else: no labels applied, no plan, no implementation, no rewrite of the issue.
Complexity is the relative size of the work, the mix of volume (how much has to change),
uncertainty (what is still unknown) and risk (what breaks if it goes wrong). It is not
priority, severity or urgency, and it is not a time estimate. The full rubric, with sources,
is in references/rubric.md; read it before the first classification.
Steps
- Read the whole issue: title, body, acceptance criteria, reproduction steps and any
comments given. If a repository is at hand, a quick look at the files it names is fair
game to judge the blast radius; do not go further than that.
- Collect signals on each axis:
- Volume: how many components, layers or packages change.
- Uncertainty: is the solution stated or obvious, or does it need investigation; is a
bug reproducible.
- Risk: public API or breaking change, data or schema migration, auth or security,
concurrency, external systems or other teams, hard-to-reverse decisions.
- Match the signals to the level definitions in the rubric.
- Break ties with the rubric rules. In short: the strongest risk signal wins, uncertainty
alone lifts one level, volume alone stops at
medium, and between two levels pick the
higher one because underestimating costs more.
- Ignore what does not measure complexity: priority, severity, urgent tone, length of the
text and any estimate already written in the issue. A one-line change to auth or shared
config is not
low.
Output
Complexity: <low|medium|high>
Justification:
- <signal quoted or paraphrased from the issue> -> <what it means for complexity>
- <2 to 4 bullets in total>
Split note: <only for a high issue that is too big: where it naturally splits>
The scale has three levels on purpose: text alone cannot tell five levels apart reliably.
For a high issue that is too big to be one piece of work, add the split note following
the criteria in the rubric; leave the line out otherwise.
When the issue is too vague to judge (no scope, no reproduction, no acceptance criteria),
still give the most likely level and say in the justification that the text does not support
a confident classification and which missing detail would change it.
1---2name: mass-issue-complexity3description: Classifies the complexity of an issue or ticket as low, medium or high from its text and justifies the level with the signals found. Use when "how complex is this issue", "classify the complexity of this ticket" or "is this issue low, medium or high". Do NOT use for reviewing a diff or pull request (use mass-code-review), for deciding how urgent an issue is (use mass-issue-priority) or for writing a pull request description (use mass-pr-description).4license: CC-BY-4.05---67# Issue complexity89Read an issue and return one level, `low`, `medium` or `high`, with a short justification.10Nothing else: no labels applied, no plan, no implementation, no rewrite of the issue.1112Complexity is the relative size of the work, the mix of **volume** (how much has to change),13**uncertainty** (what is still unknown) and **risk** (what breaks if it goes wrong). It is not14priority, severity or urgency, and it is not a time estimate. The full rubric, with sources,15is in [references/rubric.md](references/rubric.md); read it before the first classification.1617## Steps18191. Read the whole issue: title, body, acceptance criteria, reproduction steps and any20 comments given. If a repository is at hand, a quick look at the files it names is fair21 game to judge the blast radius; do not go further than that.222. Collect signals on each axis:23 - **Volume**: how many components, layers or packages change.24 - **Uncertainty**: is the solution stated or obvious, or does it need investigation; is a25 bug reproducible.26 - **Risk**: public API or breaking change, data or schema migration, auth or security,27 concurrency, external systems or other teams, hard-to-reverse decisions.283. Match the signals to the level definitions in the rubric.294. Break ties with the rubric rules. In short: the strongest risk signal wins, uncertainty30 alone lifts one level, volume alone stops at `medium`, and between two levels pick the31 higher one because underestimating costs more.325. Ignore what does not measure complexity: priority, severity, urgent tone, length of the33 text and any estimate already written in the issue. A one-line change to auth or shared34 config is not `low`.3536## Output3738```39Complexity: <low|medium|high>4041Justification:42- <signal quoted or paraphrased from the issue> -> <what it means for complexity>43- <2 to 4 bullets in total>4445Split note: <only for a high issue that is too big: where it naturally splits>46```4748The scale has three levels on purpose: text alone cannot tell five levels apart reliably.49For a `high` issue that is too big to be one piece of work, add the split note following50the criteria in the rubric; leave the line out otherwise.5152When the issue is too vague to judge (no scope, no reproduction, no acceptance criteria),53still give the most likely level and say in the justification that the text does not support54a confident classification and which missing detail would change it.
maiconsouza89