Given a project description (or existing repo), produce four deliverables in this order:

1. Repository Tree — folder/file layout
2. Branch Policy — branch types, naming, protection rules
3. PR Flow — how changes move from branch to merge
4. Release Flow — how merged code becomes a release

Example invocation: "Set up governance for a Node.js monorepo with 3 microservices."

Progress:

• Step 1: Identify project type (monorepo/polyrepo, language, team size)
• Step 2: Define Repository Tree
• Step 3: Define Branch Policy
• Step 4: Define PR Flow
• Step 5: Define Release Flow
• Step 6: Add issue management conventions (labels, templates)

Step 1: Identify Project Context

Ask/infer: team size, deployment cadence, monorepo vs polyrepo, CI/CD maturity. Default assumption if unspecified: small-to-mid team, trunk-based development, weekly releases.

Step 2: Repository Tree

Standard baseline structure (adapt per stack):

repo-root/
├── .github/
│   ├── workflows/          # CI/CD pipelines
│   ├── ISSUE_TEMPLATE/
│   └── PULL_REQUEST_TEMPLATE.md
├── src/                    # application code
├── tests/
├── docs/
├── scripts/
├── .gitignore
├── CODEOWNERS
├── CONTRIBUTING.md
└── README.md

For monorepos, nest apps/ and packages/ instead of flat src/.

Step 3: Branch Policy

Default model: trunk-based with short-lived feature branches.

• main — always deployable, protected (require PR + passing checks + 1+ approval)
• develop — optional, only if release cadence needs staging integration
• feature/<ticket-id>-<short-desc>
• fix/<ticket-id>-<short-desc>
• hotfix/<short-desc> — branches off main, merges to main and back to develop
• release/<version> — only for scheduled multi-feature releases

Protection rules:

• No direct pushes to main
• Require status checks (lint, test, build) to pass
• Require linear history (squash or rebase merge only)
• Require CODEOWNERS review on protected paths

Step 4: PR Flow

1. Branch from main using naming convention
2. Commit using conventional commits (feat:, fix:, chore:, docs:)
3. Open PR with template (description, linked issue, screenshots if UI)
4. Automated checks run (CI: lint/test/build)
5. Request review from CODEOWNERS or assigned reviewer
6. Address review comments
7. Squash-merge on approval + green checks
8. Delete branch post-merge

Review policy defaults:

• Minimum 1 approval for standard changes, 2 for critical paths (auth, payments, infra)
• Reviewer response SLA: 24 hours
• PR size guideline: prefer < 400 lines diff; split larger changes

Step 5: Release Flow

1. Merge feature/fix PRs into main continuously
2. Tag release: vMAJOR.MINOR.PATCH (semver)
3. Auto-generate changelog from conventional commits
4. CI builds and publishes artifact/deploy
5. Create GitHub Release with changelog notes
6. Hotfix path: branch from tag → fix → PR → merge → new patch tag

Issue Management

• Labels: bug, feature, chore, priority:high/medium/low, status:blocked
• Templates: bug report (repro steps, expected/actual), feature request (motivation, proposal)
• Triage cadence: weekly, close stale issues after 30 days inactivity

Example 1: Input: "Small startup, single Node.js API repo, 4 developers, deploys daily."

Output:

Repository Tree:
repo-root/
├── .github/workflows/ci.yml
├── src/
├── tests/
├── CODEOWNERS
└── README.md

Branch Policy:
- main (protected, deploy-on-merge)
- feature/*, fix/* short-lived branches
- No develop branch (trunk-based, daily deploys)

PR Flow:
- PR from feature branch → CI checks → 1 approval → squash merge → auto-deploy

Release Flow:
- Continuous deployment on merge to main
- Tag vX.Y.Z automatically via CI on merge
- Changelog auto-generated from commit messages

Example 2: Input: "Enterprise monorepo, 5 microservices, quarterly release trains, compliance requirements."

Output:

Repository Tree:
repo-root/
├── apps/{service-a,service-b,...}
├── packages/shared-libs
├── .github/workflows/{ci,security-scan}.yml
├── CODEOWNERS (per-service ownership)
└── docs/

Branch Policy:
- main (protected, 2 approvals for compliance-tagged paths)
- develop (integration branch)
- release/2024-Q3 (release train branch)
- hotfix/* from main

PR Flow:
- feature → develop (1 approval + checks)
- develop → release branch (2 approvals, security scan required)
- release → main (release manager sign-off)

Release Flow:
- Quarterly release branch cut from develop
- Stabilization period with only fix/* PRs
- Tag + release notes + compliance audit log attached