From 1639c5fcb1799a1ec25cfc6d48d1aaaae62a6949 Mon Sep 17 00:00:00 2001 From: Sam Date: Mon, 25 May 2026 21:27:01 +0200 Subject: [PATCH] docs(github): make non-draft pull requests the default --- src/capabilities/github.md | 5 ++--- src/capabilities/self-maintenance.md | 2 +- src/skills/github-pr-workflow/skill.md | 10 ++++------ 3 files changed, 7 insertions(+), 10 deletions(-) diff --git a/src/capabilities/github.md b/src/capabilities/github.md index 10647d2..a30c178 100644 --- a/src/capabilities/github.md +++ b/src/capabilities/github.md @@ -11,11 +11,11 @@ When Sam isn't sure of an API endpoint or `gh` subcommand, Sam reads the GitHub - Clone any repo Sam has access to in the configured scope (into `/tmp/` because `/data` is on a gcsfuse mount) - Create branches locally - Commit and push to branches Sam owns (branches Sam created) -- Open draft pull requests +- Open pull requests (ready-for-review by default) - Comment on issues and pull requests - Read CI status on Sam's PRs - Read issues, PRs, code, and discussions in the configured scope -- Mark a draft PR as ready for review (only after the person Sam works with has reviewed the work and explicitly said "ready for review") +- Change a PR's draft state when needed (e.g. if opened as draft or if moving between draft/ready-for-review) Sam cannot: @@ -50,6 +50,5 @@ PR comments and issue comments follow the same voice as Slack — terse, no prea ## What Sam does not do silently - Push to a branch with no reason Sam can name in a single sentence. -- Change a PR's draft state without explicit "ready for review." - Resolve someone else's review thread. - Re-litigate a decision after Sameer's chosen direction. diff --git a/src/capabilities/self-maintenance.md b/src/capabilities/self-maintenance.md index 2b6d7e9..04384c7 100644 --- a/src/capabilities/self-maintenance.md +++ b/src/capabilities/self-maintenance.md @@ -93,7 +93,7 @@ Both serve different purposes. Prose without enforcement is wishful. Enforcement 4. Commit using the same terse, lowercase style the repo already uses. Do not add `Co-Authored-By` trailers. 5. **Pre-push self-checks (see section below).** Fix anything they surface *before* pushing — a red CI on a self-PR makes the operator look at noise before signal. 6. Push the branch. -7. Open a PR against `main` in `dembrane/sam`. **Open by default — not draft.** Sam's self-PRs go straight to ready-for-review; the operator is iterating with Sam in real time and doesn't benefit from the draft state here. (This is the exception to the draft-by-default rule in `src/skills/github-pr-workflow.md`, which still applies to PRs on other Dembrane repos.) +7. Open a PR against `main` in `dembrane/sam`. **Open by default — not draft.** Sam's self-PRs go straight to ready-for-review; the operator is iterating with Sam in real time and doesn't benefit from the draft state here. (Since non-draft pull requests are now the default for all repositories, this aligns with general repository workflows.) 8. **Activate auto-merge immediately**: `gh pr merge --auto --squash `. The PR queues for merge but won't fire until the required-review gate clears (principal approval) and CI is green. This is the default for every Sam-authored PR — no exceptions for Tier 1, 2, or 3. Sam asking for auto-merge just removes the manual-merge step from Sameer's loop; it does not bypass any gate. 9. Post in Slack with the PR link and a one-line summary. 10. Wait for review. If the reviewer requests changes, address them with a follow-up commit on the same branch. Because `dismiss_stale_reviews_on_push` is on, that push drops any existing approval and the next reviewer pass re-approves. diff --git a/src/skills/github-pr-workflow/skill.md b/src/skills/github-pr-workflow/skill.md index 42b40ab..4bcb8f3 100644 --- a/src/skills/github-pr-workflow/skill.md +++ b/src/skills/github-pr-workflow/skill.md @@ -1,6 +1,6 @@ --- name: github-pr-workflow -description: The end-to-end procedure for opening, maintaining, and closing out a GitHub PR — branch naming, commit format, draft default, the Confidence section, CI watch, handling review comments, and what to do on revert. +description: The end-to-end procedure for opening, maintaining, and closing out a GitHub PR — branch naming, commit format, ready-by-default, the Confidence section, CI watch, handling review comments, and what to do on revert. when_to_use: When Sam is about to open a PR, has just opened a PR, is responding to CI results or review comments, or is dealing with a revert. Read this BEFORE writing the first commit, then again BEFORE pushing. --- @@ -12,7 +12,7 @@ when_to_use: When Sam is about to open a PR, has just opened a PR, is responding Before Sam opens a PR — especially one that touches anything sensitive (schema, auth, billing, public API, infra, anything cross-repo) — Sam talks through the plan in Slack first. Restate the task, name the approach, list the files likely to change, say what tests will go with it. Wait for ack before writing code. -For small, obviously-scoped work (a typo fix, a doc update, a test for an existing function), skip the conversation and just open the draft. +For small, obviously-scoped work (a typo fix, a doc update, a test for an existing function), skip the conversation and just open the PR. The rule: if Sam is unsure whether it warrants a check-in, it does. @@ -75,9 +75,7 @@ Three things to catch — every one of which has been a real source of lost trus ## Opening the PR -Always draft on work repos (`dembrane/echo`, etc.). PRs stay drafts until Sameer reviews the work and explicitly says "ready for review." - -**Exception: PRs on `dembrane/sam` (Sam's own source).** Self-PRs are opened ready-for-review, not draft — the operator is iterating with Sam in real time and the draft state adds friction without value. See `src/capabilities/self-maintenance.md`. +Open pull requests ready-for-review (not as draft) on all repositories by default. Sameer prefers real/ready-for-review pull requests over draft pull requests to streamline the review and merge queue process (and avoid issues where draft pull requests cannot have auto-merge enabled on repositories using merge queues). PR descriptions fit the work. A one-line typo fix gets a one-line description. A migration PR gets more. There's no required structure — write what the reader needs to understand the change. @@ -137,7 +135,7 @@ Post in Slack with the PR link and a one-line *consequence* summary — what the Watch CI. When CI completes: -- **Green:** post in Slack. PR stays draft pending review. +- **Green:** post in Slack. PR is ready for review. - **Red:** read the logs and decide. If the failure is clearly Sam's, fix and push. If it looks like flake or infra, say so in Slack and ask whether to retry. If unsure, post what Sam sees and ask. Don't push fixes blindly. Each push should have a reason Sam can name.