Brad Simantel c5bbff721d feat(should-flag-change): prefer reusing an existing flag over proposing a new one (#148) ...

* feat(should-flag-change): prefer reusing an existing flag over proposing a new one

When a change adds a new surface to a feature already gated by an existing
(often not-yet-released) flag, the skill previously only checked ancestor
gates and would otherwise recommend a brand-new flag. Add a Step 2 "existing
flag to reuse" exploration step and a new `reuse-existing` verdict (plus a
`reuse_flag_key` field) so the skill can say "gate this behind the existing
key" instead of duplicating it.

- SKILL.md: new reuse-detection step (sibling hunks / adjacent feature code /
  flag defs), `reuse-existing` verdict + `reuse_flag_key`, verdict rules,
  edge case, and a guardrail; bump 0.3.0 -> 0.4.0-experimental.
- marketplace.json + skills.json: version bump.
- evals: extend the verdict-taxonomy contract to the 4th verdict and add an
  agentic regression fixture reconstructed from gonfalon PR #68384 (the case
  that motivated EMSR-1927).

EMSR-1927

* fix(should-flag-change): add reuse-existing to the recommend-flag tool schema

The recommend-flag tool schema (evals/tools/definitions.json) still enumerated
only suggested / already-flagged / not-suited and had no reuse_flag_key, so the
eval provider's Zod schema would have rejected the new contract the skill and
the EMSR-1927 fixture require. Add reuse-existing to the verdict enum and the
optional reuse_flag_key field; update the skill README's verdict list to match.

EMSR-1927

2026-08-07 14:21:50 -07:00

..

definitions.json

feat(should-flag-change): prefer reusing an existing flag over proposing a new one (#148)

2026-08-07 14:21:50 -07:00