The "Pre-Submission Checklist" Before Delivery: Eliminating Delivery Incidents in the Last Hour

**Specific Scenario**: It’s 4 PM on a Friday. You commit your feature, write the description, add screenshots, tag the release, and clock out. On Monday morning, the client replies: "A field is missing," "The color is wrong," or "Restart steps weren't included." Ninety percent of these incidents can be caught in the final hour using a pre-submission checklist.

What Is This Skill?

A Pre-commit Checklist is not a documentation writing technique; it is a **delivery quality gate**. Before you declare something "done," use a fixed list of questions to verify each item one by one. This exposes the information gap between "I think I’m finished" and "The client thinks I’m finished" on paper.

When to Use It

- Formal deliveries to clients (features, reports, design updates)

- Work dependent on others’ acceptance (PR reviews, outsourcing deliverables)

- Any asynchronous delivery where "the other party doesn’t see the process after you make changes"

- Cross-time-zone collaborations where time differences prevent immediate follow-up questions

When Not to Use It

- Internal rapid iterations or items you plan to continue modifying the same day—the checklist will slow down the pace; opt for verbal alignment instead.

- Review meetings with a "watch-and-chat" style—live demos are more efficient than checklists.

- When requirements are still changing drastically—the checklist locks in yesterday’s requirements.

How to Write the Checklist (5 Steps)

1. **Reverse-engineer from past incidents**: Look back at all the "please fix this" messages you received in the last three months, and turn each into a checklist item. This constitutes the most valuable 60% of your checklist.

2. **Sort by the "recipient’s perspective"**: What will the recipient check first when they open the deliverable? (Does it run? Is the documentation complete?) Put these items at the top.

3. **Each item must be binary (yes/no)**: Writing "documentation is complete" is useless. Instead, write "Installation steps in the README run successfully on the current branch."

4. **Keep it to 7±2 items**: If there are more than 10 items, people won’t execute them seriously.

5. **Embed it in your delivery template**: Add it to your Notion template, PR template, or Trello card. Don’t rely on memory.

Timing and Gotchas

- **Timing**: Execute the checklist during a 10-minute cool-down period *after* you feel you’re done, not in the 30 seconds before hitting the submit button.

- **Pitfall 1 – Checklist rigidity**: Delete items no one checks every quarter, and add new items based on recent incidents. A checklist is only useful if it stays alive.

- **Pitfall 2 – Using the checklist to prove you’re right**: If you check every box but the delivery is still rejected, suspect that the checklist is missing items rather than assuming "the client changed their requirements."

- **Pitfall 3 – Making decisions for the recipient**: The checklist only covers "standard deliverables." Project-specific agreements (e.g., submitting screenshots only, not videos) should be noted separately in business remarks.

Minimal Viable Starter Kit

A 5-item starter checklist you can use today:

- [ ] The deliverable runs successfully in a clean environment (new machine/clean branch)

- [ ] Version number/date/naming conventions match the recipient’s requirements

- [ ] Every step in the documentation has been manually executed with the latest code

- [ ] Screenshots/demos reflect the current version, not last week’s

- [ ] The reply clearly states "what’s included, what’s excluded, and what’s next"

Spending 10 minutes going through the checklist in the last hour is far cheaper than spending Monday afternoon patching holes.