Check Readiness

Goal

Decide whether the original issue scope is satisfied in the current project state, without adding new scope. Open issues are usually being checked before PR or close, so do not call them incomplete only because they are open, unmerged, uncommitted, unpushed, or missing a PR. Treat those as lifecycle notes.

Use lightweight BDD completion scenarios when they exist in the issue body, active plan, PR body, or relevant comments. Treat these Given/When/Then scenarios as readable completion contracts and verify their evidence mapping. Do not require Cucumber, .feature files, or a separate BDD framework unless the repository already uses one or the active plan explicitly requires it.

When NOT: exploring “what should we build?”, inventing new scope, or coaching a lost user → recon / idk-now / issues create. This skill gates evidence against existing scope.

Input

Accept an explicit issue number, task number, or GitHub issue URL. If none is provided, infer one from the strongest local or GitHub evidence: current branch, recent commits, staged/unstaged changes, PR metadata, linked issue references, recent issue activity, or local notes. Ask only when no single issue is clearly supported.

If the immediately preceding assistant response used this skill and ended with a Follow-Up Prompt, treat the user's next response as the answer to that prompt. Interpret y, Y, yes, Yes, YES, yeah, yep, ok, okay, sure, go, continue, proceed, do it, a blank/enter-style continuation when the client sends one, and affirmative UI choices as approval. Continue with the prompted next lifecycle action immediately when the answer is affirmative, unless the user adds a conflicting instruction. Do not answer with a confirmation-only message.