Proposal: Unify "Done" Gating Standard for Skills

[renjianguojinqianfan]

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.

[jonocodes]

Strong +1 on a unified gate. One rung seems missing from the discussion so far: some "done" cant be checked by any command.

The gate as described (run tests + typecheck + code-review) assumes done-ness is machine-verifiable if we just pin the commands. But some correctness only manifests on real hardware or a live session — synthetic input actually landing, focus/active-window behaviour on a real desktop, audio/display output. No pytest/npm test covers it.

So a complete standard needs two kinds of gate, not one:

1. Automated — the pinned commands youre proposing.
2. Un-automatable — an explicit terminal state meaning "code merged, but a human must confirm on real hardware," where merging is not closing: the issue stays open until a human signs off.

Ive been modelling (2) as a single human-verification-required label on a separate axis from the triage roles (which are all pre-implementation and end at ready-for-human/wontfix). Its the same shape teams get from an "In QA" Projects column, just expressed as a label for issue-only trackers. Happy to share the exact wording if useful.