Section 09 · Monitoring & Health
Development Workflow
PR processes, commit conventions, and merge strategies
This guide walks you through auditing a project's development workflow, including PR processes, commit conventions, and merge strategies.
The Goal: Clean, Traceable History
Every change flows through a predictable pipeline. History tells the story of why things changed.
- Reviewed — PRs require meaningful descriptions and code review before merge
- Tested — changes deployed to dev/preview environment before reaching protected branches
- Conventional — commit messages follow documented conventions for changelog generation
- Preserved — merge strategy maintains commit history rather than squashing it away
- Documented — branch flow (feature → dev → staging → production) is explicit and followed
Before You Start
- Confirm you're in the target repository's root directory
- Have
ghCLI authenticated with access to the repo - Know the repository owner/name for API calls
PR Process
PRs come from feature branches with meaningful descriptions
“Anyone pushing straight to main lately?”
AI review tooling configured alongside human reviewers
“Who caught the last bug before it hit production?”
Feature branches deploy to dev for testing before merge
“How often do merges break staging?”
Commit Conventions
Documented and enforced commit message format
“Can you tell what changed last week from the git log?”
Merge Strategy
Regular merges used, no squash/rebase that loses history
“Could you trace exactly what changed in your last release?”
Feature → dev → staging → production flow documented
“Does your team agree on what promotes to staging?”