| name | definition-of-done |
| description | Review whether a feature is genuinely "done" against the project Definition of Done — plan exists, correct branch, fmt/lint/check/architecture/tests all green, and security & legal compliance (ASVS/GDPR) cleared — running the root `make` gates (with per-service fallback) plus the security review, auto-fixing only formatting, and reporting every remaining gap. Use when the user asks to check, verify, or sign off that a feature/change is complete before opening a PR. |
Definition of Done — review skill
Run the project's full Definition of Done review for the current change and
report, honestly, whether it is complete. This is the executable form of
docs/process/05-definition-of-done-and-quality-gates.md.
It follows the spec-first pipeline in
docs/process/02-ways-of-working.md
and the honesty rule in .agents/rules/03-surfacing-gaps-and-incomplete-work.md.
Read AGENTS.md and the applicable .agents/rules/ first, as always.
Scope of this skill
- Review and report — run every gate and produce a verdict.
- Auto-fix only the trivially safe — apply formatting (
make fmt or the
per-service equivalent). Never fix logic, tests, architecture, commits, or the
branch automatically; those are reported for the engineer to resolve.
- A feature is done only when every gate is green. "Some tests" or "most gates"
is not done — report it as incomplete.
The gates — run in order, cheap to expensive
Stop-free: run all of them even if an early one fails, so the final report is
complete. Run every make command from the repository root.
| # | Gate (DoD criterion) | How to check |
|---|
| 1 | On a work branch, not main/dev | git branch --show-current; must be feat/, fix/, doc/, chore/, or refactor/ |
| 2 | Feature is planned | At least one related doc exists under docs/plans/; a multi-phase plan is fine |
| 3 | Request was specified, not a bare "implement" | If there is no plan/spec and the ask was vague (e.g. "implement", "create auth 2.0"), warn and mark incomplete |
| 4 | No format/lint warnings or errors | make fmt (auto-fix), then make fmt-check and make lint |
| 5 | Commits are well documented | Conventional Commits (type(scope): summary), imperative, no placeholders (wip, fix, asdf), no Co-Authored-By trailer |
| 6 | Architecture checks pass | make architecture-check |
| 7 | Compiles / type-checks | make check |
| 8 | All tests present and green | make test and make test-full — unit + integration + e2e; none missing |
| 9 | Working tree is coherent | No unintended files staged; no secrets, build outputs, .env |
| 10 | Security & legal compliance | See below — every feature must clear this |
Criterion order in the table matches the DoD doc, not the run order; run branch and
plan checks first (they are free), then the toolchain gates.
Gate 10 — security & legal compliance (mandatory per feature)
Not a single make target: this gate is part automated, part review. Every feature
must clear it before it is done. Check against .agents/rules/05-security.md and
.agents/rules/24-security-and-compliance.md (authoritative design in
docs/architecture/13-security-and-privacy.md).
- Automated part — run the
security-review skill on the current diff, and any
security/SAST/dependency-audit make targets that exist. Report failures like any
other gate.
- Review part — confirm, for what this change touches:
- Authorization is enforced server-side; no trust in client roles/headers; route
prefix is not a control.
- No new exposure of PII or secrets in logs, errors, responses, events, or MCP
payloads; production errors expose only a stable
reason.
- OWASP ASVS-informed for the surface touched (input validation, authn/session,
access control, error handling).
- GDPR / legal obligations where relevant: lawful data minimization, data
residency (region-pinned, fail-closed), retention & erasure, and audit of
privileged/data actions.
- Fail closed — when a security guarantee cannot be met, the code refuses rather
than silently degrades.
- If the change touches auth, data, crypto, secrets, or a cross-boundary contract,
an explicit security look is required, not optional — flag it in the report and
stop for the engineer if anything is weakened (
.agents/rules/05-security.md).
Before the PR — out of scope for this skill
This skill answers "is the feature done?", i.e. everything before opening the PR.
It does not open, review, or merge the PR, and it does not cover release. Once it
reports DONE, PR hygiene and release live elsewhere:
Step-by-step
- Discover available targets. Run
make help (or read the root Makefile) to
see which gate targets exist. The root Makefile is the single interface and is
expected to grow the house-pattern targets (fmt, fmt-check, lint, check,
architecture-check, test, test-full).
- Branch + plan first. Check the branch (gate 1) and look for a related plan in
docs/plans/ (gates 2–3). If either fails, record it and continue.
- Run each gate. For every gate with a root target, run
make <target>.
- Fall back per service when a target is absent. If a root target does not
exist yet ("No rule to make target"), run the equivalent inside each service and
mark that gate manual / per-service — never green-by-default. The gate is
still mandatory. Per-service tooling:
services/api (Go): make targets, e.g. fmt-check, lint, check, test.services/identity (Rust): make fmt-check lint check test test-full architecture-check.services/ai (Python): the service's make/uv targets (lint, typecheck, test).apps/web (Next.js): the workspace bun scripts (lint, typecheck, test).
- Auto-fix formatting only. If
make fmt changed files, note it in the report;
leave the changes in the working tree for the engineer to commit.
- Report (see below). Do not open a PR, commit, or merge — this skill reviews.
Output
Emit a single verdict table, one row per gate, with an explicit status:
- ✅ pass — ran and green.
- ❌ fail — ran and failed; include the failing command and the key output.
- ⚠️ manual / not run — no root target and checked per-service, or could not be
run; say which and why.
Distinguish failed from not run from assumed — they are acted on differently
(.agents/rules/03-surfacing-gaps-and-incomplete-work.md). End with a one-line
verdict:
- DONE — only if every gate is ✅.
- NOT DONE — otherwise, followed by the concise list of what remains and who/what
must resolve it.
Never soften a ❌ or ⚠️ into a done-sounding summary.
