What problem does it solve? Work items picked up before they are unambiguous force builders to make product or architecture decisions mid-build, causing interruptions, wrong assumptions, and costly rework. This Skill defines what "ready" means for a work item so intake catches ambiguity before a branch exists. ## Core Features & Use Cases - Project-conditional checklists: Shapes the readiness bar around the surfaces a project actually has (UI prototype, external API docs, acceptance criteria, estimate) instead of a universal checklist with unsatisfiable items. - Seam detection between issues: Names the flagship failure of overlapping behavior fragmented across separate issues, and prescribes reading related issues against each other before marking them ready. - Concrete loop bar: Documents this repo's own ready label semantics — invocable: declaration, sp:N estimate, acceptance criteria as observable artifacts — and honestly separates which criteria a hook checks, which an instruction checks, and which nobody checks. - Use Case: When running backlog intake or sizing a sprint, apply this Skill to decide whether each issue is genuinely buildable or still hides undecided scope at its edges. ## Quick Start Ask the agent to evaluate whether a given issue meets the definition of ready before assigning it to a builder.
