Guidelines for API design PRs (#24796)

Add details about how to make an API design PR

handbook/product-design/README.md

@@ -56,7 +56,12 @@ At Fleet, like [GitLab](https://about.gitlab.com/handbook/product-development-fl
 
 3. Add page names (e.g. "Host details" page) to the user story's title and/or description to help contributors find Figma wireframes for the area of the UI you're making changes to.
 
-4. If the story requires API or YAML file changes, open a pull request to the reference docs release branch (e.g. `docs-v4.58.0`) with the proposed design. Mark the PR "Ready for review" as soon as it's ready for feedback from the [API design DRI](https://fleetdm.com/handbook/company/communications#directly-responsible-individuals-dris).
+4. If the story requires API or YAML file changes, open a pull request (PR) to the reference docs with the proposed design. Pay attention to existing conventions (URL structure, parameter names, response format) and aim to be consistent. Your PR should follow these guidelines:
+  - Make a PR against the docs release branch for the version you expect this feature to be in. Docs release branches are named using the format `docs-vX.X.X`, so if you're designing for Fleet 4.61.0, you would make a PR to `docs-v4.61.0`.
+  - Add a link to the issue in the PR description.
+  - Attach the `~api-or-yaml-design` label.
+  - Mark the PR ready for review. (Draft PRs do not auto-request reviews.)
+  - After your changes are approved by the API design DRI, they will merge your changes into the docs release branch.
 
 5. Add links to the user story as specified in the [issue template](https://github.com/fleetdm/fleet/issues/new?template=story.md).