docs(contributing): make CONTRIBUTING.md SSOT for branching workflow

AGENTS.md

@@ -17,4 +17,4 @@ Components are Vue 3 composition-API + TypeScript; use PascalCase for component
 Vitest with the Happy DOM environment backs both unit and snapshot tests (`*.spec.ts` collocated with components, utility tests such as `src/utils/breadcrumbs.test.ts`). Name suites after the component under test and prefer factory helpers so specs stay deterministic. Always run `npm run test` (or at least `test:changed`) before opening a PR; coverage reports land in `coverage/` and are auto-cleaned by `posttest`. Add snapshots when altering markup, and update them intentionally with `vitest -u`.
 
 ## Commit & Pull Request Guidelines
-Create topic branches prefixed by intent (e.g., `feature/add-stepper`, `fix/Button-border`). Use `npm run _commit` (Commitizen) to craft Conventional Commits so semantic-release can version automatically; commits are linted via Husky hooks. Pull requests should describe the motivation, link any GitHub issues, and attach screenshots or screen recordings for visual tweaks. Confirm `lint`, `test`, and `build` all pass locally, and mention any docs updates (`npm run docs`) in the PR body. Tag reviewers on Discord if feedback is needed, and prefer small, focused changes to keep release automation predictable.
+See [CONTRIBUTING.md](./CONTRIBUTING.md) for the full workflow, including which base branch to use, commit conventions, and PR requirements.

CONTRIBUTING.md

@@ -29,7 +29,7 @@ Test your changes **locally first**, if possible. Include **screenshots with you
 3. `cd` into the project directory `cd design-system` and install dependencies `npm i`
 
 ### Workflow
-1. Create a branch prefixed with the appropriate action (e.g. `feature/add-dropdown-component`, `fix/button-border-styles`).
+1. Branch off `beta` for all feature work and non-trivial fixes. Branch off `main` only for urgent hotfixes or chores (e.g. dependency bumps) that don't need a beta release cycle. Name your branch with an appropriate prefix (e.g. `feature/add-dropdown-component`, `fix/button-border-styles`).
 2. Make your changes.
 3. Commit your changes, using `npm run _commit` (this calls `commitizen`, which guides you through creating a conventional commit).*
 

README.md

@@ -83,36 +83,7 @@ import `pdap-design-system/images`;
 
 ## Development Setup
 
-1. Clone the repo
-
-```
-gh repo clone Police-Data-Accessibility-Project/design-system
-```
-
-1. CD into the project directory and install dependencies
-
-```
-cd design-system
-npm i
-```
-
-1. Step 2 should result in the `build` script being run after packages are installed. Check the `dist` directory for changes. You then may want to take one or both of the following steps:
-
-2. If `build` wasn't called when you installed deps, build styles and images to the `dist` directory:
-
-```
-npm run build
-```
-
-- To watch for changes and update the build as you make changes:
-
-```
-npm run build:watch
-```
-
-1. If you use VS Code as your editor, you may want to install the [tailwind VS Code extension](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss), which helps with intellisense and the custom at-rules used by TailwindCSS.
-
-2. Read the [contributing guide](./CONTRIBUTING.md) for development requirements and tips.
+See the [contributing guide](./CONTRIBUTING.md) for setup, branching workflow, commit conventions, and testing requirements.
 
 ## Assets
 
@@ -144,5 +115,5 @@ _n.b. There are some other scripts defined in the `package.json` `"scripts"` fie
 
 ## Releasing
 
-Incremental updates can be added to `main` directly via a PR. For more significant updates, the `beta` branch can be used for releasing incremental beta releases to test the bigger feature without releasing to production.
+See [CONTRIBUTING.md § Workflow](./CONTRIBUTING.md#workflow) for the branching strategy (`beta` vs `main`) and release process.