Define and Automate Your Definition of Done

This skill is expert in creating, implementing, and optimizing Definition of Done (DoD) criteria for agile software teams, covering how DoD differs from acceptance criteria, how it matures with team growth, and how to make it actionable across project types. It draws a clear line between the two: DoD is universal quality standards applied to ALL work items - "how we work" - while acceptance criteria are feature-specific functional requirements - "what we're building"; DoD creates team-wide consistency, acceptance criteria create feature specificity. Effective DoD criteria must be binary and measurable (clear pass/fail), actionable (team members know exactly what to do), realistic within sprint constraints, valuable to product quality or team efficiency, and a living document that evolves with team maturity. It provides a three-tier DoD structure (Development: coding standards, 80% unit test coverage, integration tests, clean SAST scan, performance benchmarks; Quality Assurance: QA-verified acceptance criteria, cross-browser testing, mobile responsiveness, WCAG 2.1 AA compliance, design review; Deployment: feature flags, monitoring/alerting, updated documentation, 2+ reviewer approval, successful staging deployment), plus ready templates for a startup/early-stage team (MVP-focused, lighter checklist) and an enterprise team (SonarQube quality gates, 85% coverage, OWASP security checklist, GDPR compliance, runbooks, rollback procedures).

Use this skill when establishing or evolving a team's DoD rather than reusing acceptance criteria as a stand-in for quality standards - it defines a four-level maturity progression (Basic: functionality and basic quality; Systematic: automated testing and code standards; Advanced: performance, security, observability; Optimized: continuous improvement and predictive quality) so DoD scope matches team capability rather than being copied wholesale from another team. It includes a quarterly DoD retrospective template with questions on effectiveness (which items caught the most problems, which felt like checkbox theater, what quality issues reached production), efficiency (which items took longer than expected, what can be automated), and evolution (what new quality issues emerged, what needs to change). It is not meant to be static - the skill's own warning against common pitfalls includes "set and forget" as a named failure mode alongside too many criteria (cap at 8-12), vague wording, and a one-size-fits-all DoD across different work types.

### GitHub Actions DoD Automation
name: Definition of Done Checks
on: [pull_request]

jobs:
  dod-validation:
    runs-on: ubuntu-latest
    steps:
      - name: Code Quality Gate
        run: |
          npm run lint
          npm run test:coverage -- --threshold=80
          
      - name: Security Scan
        uses: securecodewarrior/github-action-add-sarif@v1
        with:
          sarif-file: security-scan-results.sarif
          
      - name: Performance Budget
        run: lighthouse --budget-path=budget.json --chrome-flags="--headless"
        
      - name: DoD Checklist Validation
        uses: ./.github/actions/validate-dod
        with:
          checklist-file: .github/dod-checklist.yml

Given a team's maturity level and context, the skill produces a tiered DoD checklist (startup/MVP or enterprise template, or a custom three-level structure), a CI/CD pipeline like the one above that automates DoD validation, a DoDTracker class that records per-criterion completion with evidence and reviewer, computes a completion percentage, and generates a report of remaining and blocked criteria, plus a quarterly retrospective question set and a metrics list (DoD compliance rate per sprint, time spent on DoD activities versus development, defects caught by DoD versus escaped to production, team confidence in release quality, and DoD's impact on cycle time).

Agile team leads, Scrum Masters, and engineering managers defining or maturing a team's DoD who want concrete, tiered templates and a maturity model rather than starting from a blank checklist. It suits teams that want DoD automated into CI/CD and tracked with real metrics rather than treated as a static, forgotten checklist - and that want DoD woven into sprint planning and PR templates as a visible part of team culture, not an administrative burden.