feat(release): implement conventional commits approach

- Add commitlint to enforce conventional commit format
- Replace changesets with semantic-release
- Set up GitHub Actions workflow for automated releases
- Update documentation with new release process
- Add commit message template

Closes #140

Author: bhouston

.changeset/README.md

@@ -0,0 +1,56 @@
+name: Release
+
+on:
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: write
+  issues: write
+  pull-requests: write
+  packages: write
+
+env:
+  pnpm-version: 10.2.1
+  node-version: 23
+
+jobs:
+  release:
+    name: Release
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Setup pnpm
+        uses: pnpm/action-setup@v2
+        with:
+          version: ${{ env.pnpm-version }}
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: ${{ env.node-version }}
+          cache: 'pnpm'
+
+      - name: Install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - name: Build
+        run: pnpm build
+
+      - name: Install browsers
+        run: cd packages/agent && pnpm exec playwright install --with-deps chromium
+
+      - name: Test
+        run: pnpm test
+
+      - name: Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: pnpm semantic-release

.changeset/config.json

@@ -0,0 +1,27 @@
+# <type>(<scope>): <subject>
+# |<---- Using a maximum of 50 characters ---->|
+
+# Explain why this change is being made
+# |<---- Try to limit each line to a maximum of 72 characters ---->|
+
+# Provide links or keys to any relevant tickets, articles or other resources
+# Example: Github issue #23
+
+# --- COMMIT END ---
+# Type can be
+#    feat     (new feature)
+#    fix      (bug fix)
+#    docs     (changes to documentation)
+#    style    (formatting, missing semi colons, etc; no code change)
+#    refactor (refactoring production code)
+#    test     (adding missing tests, refactoring tests; no production code change)
+#    chore    (updating grunt tasks etc; no production code change)
+# --------------------
+# Remember to
+#   - Capitalize the subject line
+#   - Use the imperative mood in the subject line
+#   - Do not end the subject line with a period
+#   - Separate subject from body with a blank line
+#   - Use the body to explain what and why vs. how
+#   - Can use multiple lines with "-" for bullet points in body
+# --------------------

.changeset/itchy-hounds-cross.md

@@ -0,0 +1,5 @@
+#!/usr/bin/env sh
+. "$(dirname -- "$0")/_/husky.sh"
+
+# Validate commit message with commitlint
+npx --no -- commitlint --edit $1

.changeset/new-nails-search.md

@@ -0,0 +1,14 @@
+{
+  "branches": ["main"],
+  "plugins": [
+    "@semantic-release/commit-analyzer",
+    "@semantic-release/release-notes-generator",
+    "@semantic-release/changelog",
+    "@semantic-release/npm",
+    ["@semantic-release/git", {
+      "assets": ["package.json", "CHANGELOG.md"],
+      "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
+    }],
+    "@semantic-release/github"
+  ]
+}

.github/workflows/release.yml

@@ -72,10 +72,41 @@ This project and everyone participating in it is governed by our Code of Conduct
 4. Commit your changes:
 
    ```bash
-   git commit -m "feat: add your feature description"
+   git commit
    ```
 
-   Follow [Conventional Commits](https://www.conventionalcommits.org/) specification.
+   We follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for our commit messages:
+
+   - **feat**: A new feature
+   - **fix**: A bug fix
+   - **docs**: Documentation only changes
+   - **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
+   - **refactor**: A code change that neither fixes a bug nor adds a feature
+   - **perf**: A code change that improves performance
+   - **test**: Adding missing tests or correcting existing tests
+   - **chore**: Changes to the build process or auxiliary tools and libraries
+
+   Each commit message should be structured as follows:
+   ```
+   <type>[optional scope]: <description>
+
+   [optional body]
+
+   [optional footer(s)]
+   ```
+
+   Example:
+   ```
+   feat(auth): implement JWT authentication
+
+   - Add JWT token generation
+   - Add token validation middleware
+   - Update user routes to use authentication
+
+   Closes #123
+   ```
+
+   We have set up a commit message template and commitlint to help you follow this convention.
 
 5. Push to your fork and create a Pull Request
 
@@ -161,9 +192,18 @@ This project and everyone participating in it is governed by our Code of Conduct
 
 ## Release Process
 
-1. Maintainers will handle releases
-2. Follow semantic versioning
-3. Update changelog entries
-4. Tag releases appropriately
+1. Releases are automated through our CI/CD pipeline
+2. When code is merged to the main branch, semantic-release:
+   - Determines the next version based on conventional commit messages
+   - Generates a changelog from commit messages
+   - Creates a GitHub Release with the changelog
+   - Tags the release
+   - Publishes to NPM
+3. No manual release steps are required
+4. Ensure your commit messages follow the conventional commits format to trigger appropriate version bumps:
+   - `feat:` commits trigger a minor version bump
+   - `fix:` commits trigger a patch version bump
+   - `perf:` commits trigger a patch version bump
+   - Commits with `BREAKING CHANGE:` in the footer trigger a major version bump
 
 Thank you for contributing to MyCoder! 👍

.gitmessage

@@ -38,6 +38,21 @@ pnpm build
 pnpm test
 ```
 
+## Release Process
+
+MyCoder follows the [Conventional Commits](https://www.conventionalcommits.org/) specification for commit messages. Our release process is fully automated:
+
+1. Commit your changes following the conventional commits format
+2. Create a PR and get it reviewed and approved
+3. When merged to main, our CI/CD pipeline will:
+   - Determine the next version based on commit messages
+   - Generate a changelog
+   - Create a GitHub Release
+   - Tag the release
+   - Publish to NPM
+
+For more details, see the [Contributing Guide](CONTRIBUTING.md).
+
 ## Contributing
 
 Please see [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute to this project.