📝 Document process (standardize pre-tag, changelog)

@tasks/changelog.md

@@ -0,0 +1,34 @@
+Instructions for the changelog:
+
+Generate two lists; one containing "What's New" (additions) and one "What's Changed" (bug fixes, modifications). 
+
+Also briefly describe the release in general, e.g. "PHP Monitor X.X is a minor update containing mostly bugfixes." or "PHP Monitor X.X contains a bunch of new features, including X, Y and Z."
+
+Make sure the changelog does not contain too many references to internal code structure unless necessary, make it understandable to the end user of the application.
+
+The changelog should be formatted using Markdown like the example, and should be copied to the clipboard.
+
+---
+
+Structure:
+
+```
+**PHP Monitor X.X** comes with features X, Y, X (brief blurb).
+
+## What's New in vX.X
+
+- List item, descriptive.
+- List item, descriptive.
+
+## What's Changed
+
+- List item, descriptive.
+- List item, descriptive.
+
+```
+
+---
+
+- [ ] Determine latest tag
+- [ ] Identify diff between latest tag and HEAD
+- [ ] Go through commits to generate changelog

@tasks/pretag.md

@@ -0,0 +1,29 @@
+Before a release is tagged, you want to make sure that the latest known stable release is known.
+
+First, identify what has changed between this tagged version and the current HEAD of the branch you wish to merge into `main` as the stable build.
+
+Tagged releases follow the `vX.Y.Z` naming system, where X is the year, Y is the month version and Z is the patch (usually unspecified unless a patch was released).
+
+Look for the latest tag on the `main` branch first.
+
+Make sure all unit tests and UI tests pass prior to finalizing a build. The developer will need to manually check this and report if the tests pass or fail.
+
+Once this has been confirmed and test pass, a sanity check needs to be done by checking if all of the changes made in the commits since the last release are:
+
+- Bugfixes for a given issue, without any potential side effects
+- New features which should have new associated tests
+- Quality of life improvements that do not require new tests
+
+If any changes seem incomplete or there's a chance that some functionality may still break despite tests passing (due to some oversight), then no release should be made and those issues should be listed first.
+
+(These sanity checks can be done manually or assisted by an LLM.)
+
+---
+
+- [ ] Do all tests pass? Ask.
+- [ ] Determine latest tag
+- [ ] Identify diff between latest tag and HEAD
+- [ ] Go through commits and sanity check based on instructions
+- [ ] Determine if ready for a new release
+- [ ] If ready, generate a short changelog (instructions in ./@changelog.md)
+