From 126de5131826a032f56b52b9c2883637f0c6211b Mon Sep 17 00:00:00 2001 From: George Tsiolis Date: Wed, 22 Jul 2026 14:12:24 +0300 Subject: [PATCH 1/3] Update commit attribution and PR review instructions Co-Authored-By: Claude --- .claude/skills/create-pr/SKILL.md | 2 +- CLAUDE.md | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/.claude/skills/create-pr/SKILL.md b/.claude/skills/create-pr/SKILL.md index 72d87b51..116ef08f 100644 --- a/.claude/skills/create-pr/SKILL.md +++ b/.claude/skills/create-pr/SKILL.md @@ -87,7 +87,7 @@ This applies to automated PRs too (dependency and toolchain upgrades), which are ## Step 6: Commit and push -If there are uncommitted changes, commit them with a concise message. Do NOT add `Co-Authored-By: Claude` unless the user explicitly asks for it. +If there are uncommitted changes, commit them with a concise message and a `Co-Authored-By: Claude ` trailer. Then push and create the PR with the chosen labels: diff --git a/CLAUDE.md b/CLAUDE.md index d9d9b4cd..5790b660 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -75,11 +75,12 @@ Commands are registered in `cmd/root.go` in two Cobra groups: the `commands` gro # Commits, PRs, and Linear -- Commit messages: a single concise line. Never add `Co-Authored-By: Claude`, "Generated with Claude Code", or any other AI attribution to commits or PR bodies. +- Commit messages: a single concise line. Add a `Co-Authored-By: Claude ` trailer to commits and PR bodies. - Never commit or push unless explicitly asked. - PRs are squash-merged; titles start with an action verb and stay under ~70 characters. - Every PR needs exactly one `semver:` label (`patch`/`minor`/`major`) and one `docs:` label (`skip`/`needed`) — enforced by `check-release-label.yml`. Use `/create-pr` to scaffold title, body, and labels. - Issues and tickets live in Linear, not GitHub Issues. Typical flow: Linear issue → branch named from the issue (e.g. `devx-123-...`) → PR body ends with `Closes DEVX-123` (or `Towards DEVX-123` if partial). Ask which Linear team if unclear (e.g. PRO = product, DEVX = developer experience). +- Small PRs and straightforward bug fixes may merge without a human approval when the author is confident; bigger features/PRs still need review and an approval, as usual. This shifts weight onto self-review rather than lowering the bar — before treating any PR-sized change as done, run `/review-pr` against it, confirm tests pass, and add integration tests per the Testing section below. If unsure whether a change counts as "small," default to waiting for review. # Release Process From 36c60ffb77c6b3ede4a057f495086117acec8820 Mon Sep 17 00:00:00 2001 From: George Tsiolis Date: Wed, 22 Jul 2026 14:20:29 +0300 Subject: [PATCH 2/3] Add review-status label to surface self-merge vs. needs-approval Co-Authored-By: Claude --- .claude/skills/create-pr/SKILL.md | 7 +++++-- .claude/skills/review-pr/SKILL.md | 10 ++++++++++ CLAUDE.md | 2 +- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/.claude/skills/create-pr/SKILL.md b/.claude/skills/create-pr/SKILL.md index 116ef08f..c7e17aea 100644 --- a/.claude/skills/create-pr/SKILL.md +++ b/.claude/skills/create-pr/SKILL.md @@ -82,8 +82,11 @@ Always apply two labels, based on the size and nature of the change: 2. A docs label reflecting whether documentation needs updating: - `docs: skip` — no user-facing documentation change is required (most dependency/toolchain upgrades, internal refactors). - `docs: needed` — the change adds or alters user-facing behavior that requires documentation updates. +3. A review label surfacing whether this PR needs a human approval or is a self-merge candidate under the review pilot — run `/review-pr`'s "Review scope" checklist (or apply it inline if that skill wasn't run) to decide: + - `review: self-merged` — straightforward bug fix or internal refactor, no new user-facing behavior, small self-contained diff. + - `review: needs-approval` — new/changed user-facing behavior, undiscussed or speculative work, or any doubt. -This applies to automated PRs too (dependency and toolchain upgrades), which are almost always `semver: patch` + `docs: skip`. +This applies to automated PRs too (dependency and toolchain upgrades), which are almost always `semver: patch` + `docs: skip` + `review: self-merged`. ## Step 6: Commit and push @@ -93,7 +96,7 @@ Then push and create the PR with the chosen labels: ``` git push -u origin HEAD -gh pr create --draft --title "" --body "<body>" --base <base-branch> --label "<semver-label>" --label "<docs-label>" +gh pr create --draft --title "<title>" --body "<body>" --base <base-branch> --label "<semver-label>" --label "<docs-label>" --label "<review-label>" ``` Return the PR URL when done. diff --git a/.claude/skills/review-pr/SKILL.md b/.claude/skills/review-pr/SKILL.md index a319bfcb..912b9a00 100644 --- a/.claude/skills/review-pr/SKILL.md +++ b/.claude/skills/review-pr/SKILL.md @@ -69,11 +69,21 @@ Go through each changed file and check for violations. Flag only actual problems - [ ] CLAUDE.md updated if architecture changed - [ ] No unnecessary comments on self-explanatory code +### Review scope (self-merge vs. human review) + +lstk pilots merging small PRs/bug fixes without a human approval; this checklist decides which bucket a PR falls into. + +- [ ] New or changed user-facing behavior (new command, flag, output, or documented behavior) → needs human review +- [ ] Wasn't discussed beforehand (no prior Slack/Linear/design conversation), or is speculative/"nice to have" → needs human review, regardless of size +- [ ] Straightforward bug fix or internal refactor, no new user-facing behavior, small and self-contained diff → self-merge candidate +- [ ] Any doubt after the above → needs human review (default to the safer bucket) + ## Step 3: Output Provide a summary with: 1. **Verdict**: Approve / Request changes / Comment 2. **Issues found**: List each with file path, line, and why it's a problem 3. **Suggestions**: Optional improvements (clearly marked as non-blocking) +4. **Review recommendation**: `review: self-merged` or `review: needs-approval`, with a one-line reason based on the Review scope checklist above Keep feedback actionable and specific. Don't flag things that aren't problems. diff --git a/CLAUDE.md b/CLAUDE.md index 5790b660..85e3de67 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -80,7 +80,7 @@ Commands are registered in `cmd/root.go` in two Cobra groups: the `commands` gro - PRs are squash-merged; titles start with an action verb and stay under ~70 characters. - Every PR needs exactly one `semver:` label (`patch`/`minor`/`major`) and one `docs:` label (`skip`/`needed`) — enforced by `check-release-label.yml`. Use `/create-pr` to scaffold title, body, and labels. - Issues and tickets live in Linear, not GitHub Issues. Typical flow: Linear issue → branch named from the issue (e.g. `devx-123-...`) → PR body ends with `Closes DEVX-123` (or `Towards DEVX-123` if partial). Ask which Linear team if unclear (e.g. PRO = product, DEVX = developer experience). -- Small PRs and straightforward bug fixes may merge without a human approval when the author is confident; bigger features/PRs still need review and an approval, as usual. This shifts weight onto self-review rather than lowering the bar — before treating any PR-sized change as done, run `/review-pr` against it, confirm tests pass, and add integration tests per the Testing section below. If unsure whether a change counts as "small," default to waiting for review. +- Small PRs and straightforward bug fixes may merge without a human approval when the author is confident; bigger features/PRs still need review and an approval, as usual. This shifts weight onto self-review rather than lowering the bar — before treating any PR-sized change as done, run `/review-pr` against it, confirm tests pass, and add integration tests per the Testing section below. Every PR also gets a `review: self-merged` or `review: needs-approval` label (via `/create-pr`, informed by `/review-pr`'s "Review scope" checklist) so which bucket it's in is visible without reading the description. If unsure whether a change counts as "small," default to `review: needs-approval`. # Release Process From 7b0fe3851328991b316928cdcafb1f4ca47b081a Mon Sep 17 00:00:00 2001 From: George Tsiolis <tsiolis.g@gmail.com> Date: Wed, 22 Jul 2026 14:23:20 +0300 Subject: [PATCH 3/3] Drop review-status label in favor of a PR description line Co-Authored-By: Claude <noreply@anthropic.com> --- .claude/skills/create-pr/SKILL.md | 12 +++++++----- .claude/skills/review-pr/SKILL.md | 2 +- CLAUDE.md | 2 +- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/.claude/skills/create-pr/SKILL.md b/.claude/skills/create-pr/SKILL.md index c7e17aea..c9d86c00 100644 --- a/.claude/skills/create-pr/SKILL.md +++ b/.claude/skills/create-pr/SKILL.md @@ -52,6 +52,10 @@ Use this structure: - Bullet point per meaningful change - Group related changes together +## Review + +<Self-merge candidate — one-line reason. Or: Human review advised — one-line reason.> + ## Tests <How this was tested — new tests added, manual verification, etc.> @@ -68,6 +72,7 @@ Rules: - Use `Closes TICKET-ID` if the PR fully resolves the issue - Use `Towards TICKET-ID` if it's a partial contribution - Keep bullet points concise — what changed, not how every line was modified +- The Review line reflects lstk's review pilot (small PRs/bug fixes may self-merge; bigger or undiscussed work needs a human). Decide it using `/review-pr`'s "Review scope" checklist (run that skill, or apply the checklist inline if it wasn't run), and say so out loud in the session before creating the PR — don't just silently decide. - Omit Todo section if there are no follow-up items - Don't over-explain; the diff speaks for itself @@ -82,11 +87,8 @@ Always apply two labels, based on the size and nature of the change: 2. A docs label reflecting whether documentation needs updating: - `docs: skip` — no user-facing documentation change is required (most dependency/toolchain upgrades, internal refactors). - `docs: needed` — the change adds or alters user-facing behavior that requires documentation updates. -3. A review label surfacing whether this PR needs a human approval or is a self-merge candidate under the review pilot — run `/review-pr`'s "Review scope" checklist (or apply it inline if that skill wasn't run) to decide: - - `review: self-merged` — straightforward bug fix or internal refactor, no new user-facing behavior, small self-contained diff. - - `review: needs-approval` — new/changed user-facing behavior, undiscussed or speculative work, or any doubt. -This applies to automated PRs too (dependency and toolchain upgrades), which are almost always `semver: patch` + `docs: skip` + `review: self-merged`. +This applies to automated PRs too (dependency and toolchain upgrades), which are almost always `semver: patch` + `docs: skip`. ## Step 6: Commit and push @@ -96,7 +98,7 @@ Then push and create the PR with the chosen labels: ``` git push -u origin HEAD -gh pr create --draft --title "<title>" --body "<body>" --base <base-branch> --label "<semver-label>" --label "<docs-label>" --label "<review-label>" +gh pr create --draft --title "<title>" --body "<body>" --base <base-branch> --label "<semver-label>" --label "<docs-label>" ``` Return the PR URL when done. diff --git a/.claude/skills/review-pr/SKILL.md b/.claude/skills/review-pr/SKILL.md index 912b9a00..d5aa0bc6 100644 --- a/.claude/skills/review-pr/SKILL.md +++ b/.claude/skills/review-pr/SKILL.md @@ -84,6 +84,6 @@ Provide a summary with: 1. **Verdict**: Approve / Request changes / Comment 2. **Issues found**: List each with file path, line, and why it's a problem 3. **Suggestions**: Optional improvements (clearly marked as non-blocking) -4. **Review recommendation**: `review: self-merged` or `review: needs-approval`, with a one-line reason based on the Review scope checklist above +4. **Review recommendation**: whether a human review is advised or this looks like a self-merge candidate, with a one-line reason based on the Review scope checklist above Keep feedback actionable and specific. Don't flag things that aren't problems. diff --git a/CLAUDE.md b/CLAUDE.md index 85e3de67..626e09d4 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -80,7 +80,7 @@ Commands are registered in `cmd/root.go` in two Cobra groups: the `commands` gro - PRs are squash-merged; titles start with an action verb and stay under ~70 characters. - Every PR needs exactly one `semver:` label (`patch`/`minor`/`major`) and one `docs:` label (`skip`/`needed`) — enforced by `check-release-label.yml`. Use `/create-pr` to scaffold title, body, and labels. - Issues and tickets live in Linear, not GitHub Issues. Typical flow: Linear issue → branch named from the issue (e.g. `devx-123-...`) → PR body ends with `Closes DEVX-123` (or `Towards DEVX-123` if partial). Ask which Linear team if unclear (e.g. PRO = product, DEVX = developer experience). -- Small PRs and straightforward bug fixes may merge without a human approval when the author is confident; bigger features/PRs still need review and an approval, as usual. This shifts weight onto self-review rather than lowering the bar — before treating any PR-sized change as done, run `/review-pr` against it, confirm tests pass, and add integration tests per the Testing section below. Every PR also gets a `review: self-merged` or `review: needs-approval` label (via `/create-pr`, informed by `/review-pr`'s "Review scope" checklist) so which bucket it's in is visible without reading the description. If unsure whether a change counts as "small," default to `review: needs-approval`. +- Small PRs and straightforward bug fixes may merge without a human approval when the author is confident; bigger features/PRs still need review and an approval, as usual. This shifts weight onto self-review rather than lowering the bar — before treating any PR-sized change as done, run `/review-pr` against it, confirm tests pass, and add integration tests per the Testing section below. Before creating a PR, say in the session whether a human review looks advisable and why, and add a short "Review" line in the PR description itself (new/changed user-facing behavior, undiscussed or speculative work → advise review; straightforward, small, already-discussed → self-merge candidate) so the assessment is visible to both the author and anyone reading the PR, not just implied. If unsure, advise review. # Release Process