Process for end-to-end development - weekly project checklist?

As per https://github.com/dwyl/hq/issues/434, we have processes spread across multiple different repositories, but one thing we _don't_ have is a checklist for things we're making sure we're doing throughout a **whole** project.

We have creating a repository #29 and the general process for working with issues and making changes (this whole repo, https://github.com/dwyl/labels) and we even have processes for agile scum mastering and ceremonies (https://github.com/dwyl/process-handbook though these are in need of a substantial update).

But we're missing a **clear and concise** checklist of **the markers of a good project in terms of development**, the concepts that **apply to a project *as a whole*** that make up 'the dwyl way'. This is somewhat linked to #28 but is wider than that.

My _suggestion_ is that we:
+ [ ] Have a 'living' checklist of ongoing things that need to be done for each project
+ [ ] Have a readme for each item on the project
+ [ ] An issue is opened in each project with this checklist _during setup_ and must be ***reviewed weekly*** to ensure we are keeping standards to where they need to be by having everything ticked

Note: This will not ensure code _quality_, we need another issue/readme on this (linked to #32)

For illustrative purposes, here is the kind of thing I would suggest be included in this checklist, which we don't _really_ have documented in a clear way as _must-dos_ (in typical @nelsonic fashion, we have detailed tutorials on most of these already), but are the hallmarks of a dwyl project:
+ Documentation - document-driven development, understanding what goes into the readme #69
+ [Testing](https://github.com/dwyl/learn-tdd)
+ Coverage expectations & usage of tools like [Codecov or Istanbul](https://github.com/dwyl/learn-istanbul)
+ [CI](https://github.com/dwyl/learn-travis)
+ Reusability of components rather than one-off code https://github.com/dwyl/technology-stack/issues/67
+ Markers of code maintainability
+ Benchmarking
+ Metrics driven requirements