I'm not a native English speaker, so the content below was summarized and translated with the help of AI — there may be some ambiguity or inaccuracies.

When using skills like /tdd, /implement, and /code-review, I've noticed a recurring issue: the definition of "done" lacks a unified, checkable gating standard.

Current State

/implement comes closest to having a "hard gate" – it requires running tests, type checks, and code review. However, the specifics remain ambiguous:

• What command does "run tests" refer to? pytest, npm test, cargo test, or something else?
• What is the threshold for passing tests? Is there a coverage requirement?

These details are left to the AI's subjective judgment or the user's ad-hoc instructions, rather than being defined by the project itself.

Related discussions (e.g., #492) have also highlighted that a vague "done" definition can lead to the AI prematurely concluding tasks.

Proposal

Explore a lightweight convention for "done" gating that skills can detect and follow:

1. Define a unified verification entry point – for example, make verify or ./scripts/verify.sh – that bundles linting, testing, type checking, and coverage into a single command. Skills would check for the existence of such an entry point and treat its successful run as a hard prerequisite for "done."

2. Maintain backward compatibility – projects without such a convention remain unaffected; skills behave as they do today.

3. Follow the "checkable" principle – the completion criteria must be verifiable conditions, not vague descriptions.

Open Questions

1. Does this direction add value?
2. If the community were to define a set of "skill-detectable done signals," what should they include?
3. Are there better ways to achieve this?

Looking forward to your feedback.