PR and branching

PR and branching

Goal

Ship changes with clear intent, early visibility (draft PRs), and a verification-first bar suited to vibe-coding: you judge outcomes and environments, not every line of generated code.

When to use

• Any change that goes through GitHub (solo or future teammates).
• Features that touch more than one repository: coordinate with linked PRs and a short narrative in each description.

Branch naming

Use a consistent prefix so history stays scannable:

• feat/<short-topic> — new behavior
• fix/<short-topic> — bugfixes
• chore/<short-topic> — tooling, deps policy (where allowed), formatting
• docs/<short-topic> — documentation-only (including sylva-docs)

Use lowercase and hyphens; keep <short-topic> under ~50 characters.

Multi-repo features (default)

1. One branch per repository you modify—do not mix unrelated repos on one branch name across clones.
2. Open draft PRs as soon as the branch is pushed so intent is visible.
3. In each PR description, link sibling PRs (other repos in the same feature) and, when relevant, the roadmap or doc page that defines “done”.
4. Merge order: merge dependencies first (e.g. shared models before the app that consumes them)—note that order in the PRs.

Pull request description (minimum)

• Why (one paragraph or bullet list)
• What you verified (smoke path, env, CI)—not a code dump
• Links: sibling PRs, issue/doc superseded, rollout notes if any

Human responsibilities (vibe-coding)

Do	Don’t (as default gate)
Run through critical user paths affected by the change	Block on exhaustive line-by-line review of AI-generated diff
Confirm dev/staging behavior when applicable	Require narrative “style” review for every file
Trust CI / lint where it exists	Treat GitHub as the place where planning lives

If something feels risky (auth, billing, data loss), narrow the change or add a targeted check—not a generic code-review theater.

Cursor skill

Use the sylva-pr-workflow skill so the agent follows this page’s habits automatically.