feat: Add Colin's set of claude settings and my settings

2026-08-11 13:20:42 -07:00
parent 6076a4f3bf
commit d74358e366
11 changed files with 342 additions and 0 deletions
@@ -0,0 +1,28 @@
+---
+name: babysit-stack
+description: Watch a stack of PRs, addressing test failures and responding to comments, until the stack is fully green.
+---
+
+# Babysit Stack
+
+## Input
+
+- Accept input as a jj revset. If not given, use `stack`.
+
+## Workflow
+
+In a loop, do the following:
+
+1. Compare each local commit message with the corresponding PR's title & description. If any information has been added to the local commit message, determine whether it belongs in the PR description (following the PR description guidance) — if so, add it there. Then, reconcile the PR's title with the commit's summary line (following the PR title guidance). Finally, reduce the commit message to the summary line only (this makes it clear that the PR description is the source of truth) plus the PR number in parentheses "(#12345)".
+
+2. If any of the PRs have not already had Claude review requested, comment with "@claude review" to request it.
+
+3. Use the handle-pr-feedback skill to handle comments on the PRs in the stack.
+
+4. Check CI for each PR in the stack. Consider only the most recent run per check. If the `require-tests-pre-merge` job (`braid` repo only) has a failure, add the `pr/force-ci` label to the PR to resolve (and move to the next PR for now since adding the label will trigger tests to run, which will take a while). If a job is failing due to a missing ticket number in the PR title, leave it failing — there is a separate automated job which will eventually link a ticket.
+
+5. If there are legitimate failures, investigate and fix.
+
+6. If any changes were made in the earlier steps, push the changes using `jfd` (Graphite repos) or `jj git push -c stack` (non-Graphite repos).
+
+7. Exit when: no new unhandled review comments and CI jobs have succeeded on all the PRs.
@@ -0,0 +1,50 @@
+---
+name: handle-pr-feedback
+description: Address feedback from reviewers for a set of commits by fetching comments from GitHub, making changes, and writing a list of the changes made.
+---
+
+# Handle PR Feedback
+
+## Input
+
+- Accept input as a jj revset. If not given, use `stack`.
+
+## Workflow
+
+Starting at the root commit of the revset, do the following:
+
+1. Use the jj bookmark for the current commit (`jj log -r <id> --no-graph -T 'local_bookmarks.map(|b| b.name())'`) to look up the corresponding GitHub PR: `gh pr view <bookmark>`
+
+2. Build a comment ledger with: `change_id`, `branch`, `pr_number`, `comment_url`, `author`, `file_line`, `summary`, `action_type`, `status`, and `notes`. Give this a heading with the commit's change ID and branch name, and append it to the file: `<repo>/scratch/handle-pr-feedback-<session>.md`.
+
+3. Build context:
+- Read nearby code and comments.
+- Read surrounding commits in the stack and note where each concern is most logically fixed.
+- Group comments that describe the same root issue and resolve them together.
+
+3. Choose an action for each comment (and record it in the ledger):
+- `fix`: change code/tests/docs, summarize what was changed.
+- `comment`: leave a comment explaining why the review comment doesn't need to be addressed or pointing to a different commit where the issue is resolved.
+- `ignore`: do nothing (e.g. because the comment is stale or marked as resolved).
+
+4. Implement fixes holistically:
+- Apply fixes by concern area, not comment order, to avoid conflicting patches.
+- Keep changes minimal and local unless the comment requires broader refactor.
+- For stack-wide concerns, place the fix in the lowest PR where it logically belongs.
+- Summarize changes made in the ledger.
+
+5. Validate:
+- If code changes were made, use `$verify-changes` for tests, lint, typechecks, and build steps.
+- If no code changes are needed, validate by tracing the exact code path and checking current behavior against reviewer intent.
+
+6. Mark comments resolved:
+- For each comment that was resolved by making a code change, mark the comment resolved (no need to leave a reply).
+- For each comment that was resolved by replying to it, mark the comment resolved.
+
+7. Final pass:
+- Confirm every ledger row is `addressed`.
+- If code changes were made, confirm `$verify-changes` succeeded or clearly report any blocker.
+
+## Output
+
+- Return a concise summary of the actions taken and point to the ledger file for details.