Service Delivery Checklist

A checklist that nobody uses is worse than no checklist — it generates compliance theatre and false confidence. The skill forces the discipline that makes checklists actually run: binary items only ("all images exported at 2x" not "check image quality"), explicit owners per item, and gates that block the next stage when the current one is incomplete. If "ensure quality" appears in a checklist, the skill rewrites it into something a junior can either tick or not tick.

The DRAFT framework maps the service into five stages. Discovery and intake — the information and access required before any production starts, with a go/no-go criterion. Research and preparation — the upstream work that makes production possible. Active production — the core delivery, with peer review and technical checks baked in. Final review and QC — the pre-delivery pass with stakeholder sign-off. Transfer and follow-up — the delivery itself plus the feedback loop and post-delivery monitoring. Gates are explicit at the transitions, because that's where cascading errors start.

The checklist captures the expert's unconscious process. The senior practitioner has dozens of micro-checks they run without naming — "I always look at X before signing off" — and that's the source material. The skill's first question is "what do you check without thinking about it?" because that's the IP being captured. The output isn't a list of best practices from the internet; it's a documented version of how this specific agency actually delivers when it delivers well.

You get the stage-gated checklist with explicit gates at the transitions, role assignments on every item, the common failure points called out so the team knows which checks exist because of which historical mistake, and a version number so the checklist can evolve as the team learns. Total length stays under forty items — beyond that, teams skip it, and the skill enforces the cap by pushing back on items that aren't catching real failures. Solo practitioners get adapted gates — "peer review" becomes "self-review with a cooling-off period," typically next-day rather than same-day. New services start with a skeleton of ten to fifteen items and a note to iterate after the first three deliveries, rather than over-engineering a checklist for a service you haven't run enough times to know where it breaks.