Update commit attribution and PR review instructions

.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
 
@@ -87,7 +92,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 <noreply@anthropic.com>` trailer.
 
 Then push and create the PR with the chosen labels:
 

.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**: 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.

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 <noreply@anthropic.com>` 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. 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