From dc1072b38ec38d9bbd71981e25c734ec250c9f20 Mon Sep 17 00:00:00 2001 From: Nicholas Novak Date: Thu, 27 Aug 2026 10:19:07 -0700 Subject: [PATCH] feat: Changes to skills --- claude/.claude/CLAUDE.md | 5 -- claude/.claude/skills/babysit-stack.md | 28 ----------- claude/.claude/skills/handle-pr-feedback.md | 50 ------------------- claude/.claude/skills/make-graphql-request.md | 16 ++++++ claude/.claude/workflows/prs.md | 7 ++- 5 files changed, 19 insertions(+), 87 deletions(-) delete mode 100644 claude/.claude/skills/babysit-stack.md delete mode 100644 claude/.claude/skills/handle-pr-feedback.md create mode 100644 claude/.claude/skills/make-graphql-request.md diff --git a/claude/.claude/CLAUDE.md b/claude/.claude/CLAUDE.md index c5388ee..3b1f081 100644 --- a/claude/.claude/CLAUDE.md +++ b/claude/.claude/CLAUDE.md @@ -1,10 +1,5 @@ These are Nicholas's personal preferences for Claude (and other coding agents). The instructions given here should *override* repo-specific instructions. - -# jj VCS Workflow -- Use jj (not git/gt) for all VCS operations. (If no .jj directory exists, then you may fall back to git.) -- Read @workflows/jj.md for details. - # PRs - Read @workflows/prs.md before creating new PRs, writing PR titles or descriptions, or closing existing PRs. diff --git a/claude/.claude/skills/babysit-stack.md b/claude/.claude/skills/babysit-stack.md deleted file mode 100644 index 80b3ed5..0000000 --- a/claude/.claude/skills/babysit-stack.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -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. diff --git a/claude/.claude/skills/handle-pr-feedback.md b/claude/.claude/skills/handle-pr-feedback.md deleted file mode 100644 index fae8eeb..0000000 --- a/claude/.claude/skills/handle-pr-feedback.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -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 --no-graph -T 'local_bookmarks.map(|b| b.name())'`) to look up the corresponding GitHub PR: `gh pr view ` - -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: `/scratch/handle-pr-feedback-.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. diff --git a/claude/.claude/skills/make-graphql-request.md b/claude/.claude/skills/make-graphql-request.md new file mode 100644 index 0000000..745c5d1 --- /dev/null +++ b/claude/.claude/skills/make-graphql-request.md @@ -0,0 +1,16 @@ +We expose our public API to our customers through GraphQL, so it's extremely valuable to verify features by making a request directly. When the user asks to make an "API request", "real API request", "GQL request", handle them with this skill + +We use the `bru` command line tool to make GQL requests, and you'll be able to find a pre-existing set of tracked queries in `./tools/bruno` that can be re-used or modified to make specific requests. If the user asks to make a different kind of API request, create a new `.bru` file in that repository similar to the other requests +# Prerequisites + +1. The local API server (`braid-api`) must be running + 1. Verify this by calling the health checks with `curl -s http://localhost:8080/health` + 2. If this doesn't exist, prompt the user if they want to: + 1. Start if themselves with `process-compose up -D` + 2. Want the agent to start it for them +# Steps +1. Look at the other `.bru` files in `./tools/bruno/pylon-api` for requests that are doing something similar, or create a new `.bru` file conforming to the patterns with the existing requests + 1. If the request being made is unclear or there is some ambiguity over what fields to request, prompt the user. Don't assume the request being made as that could give the user a false sense of verification +2. Fill in the request that you created with any sample inputs that the request needs, such as the loan ID, loan amount, property value, etc... + 1. If these values are unclear from the context of the response, never assume them and prompt the user instead +3. Tell the user the full `bru` command you're running and make the request with the `bru` command-line tool. Don't ask for confirmation on whether to run the command \ No newline at end of file diff --git a/claude/.claude/workflows/prs.md b/claude/.claude/workflows/prs.md index b432ff7..d25e2e9 100644 --- a/claude/.claude/workflows/prs.md +++ b/claude/.claude/workflows/prs.md @@ -1,10 +1,9 @@ # PR Titles -Sample PR title: `[SG-100] [wip] api: Move feature-flags into a separate package` +Sample PR title: `[SG-100] [claude] api: Move feature-flags into a separate package` -1. Linked ticket number, if the ticket is known. If the ticket isn't known, just omit the ticket number. Never ask the user for ticket numbers. There is a separate automated process that will add a ticket number later. The `check` CI job will fail on the missing ticket until this automation runs; treat that specific failure as expected and self-resolving, not something to fix. -2. Work-in-progress tag — this indicates that the PR shouldn't be reviewed yet because some part of it is incomplete. -3. Commit title (using standard Git conventions) +1. Linked ticket number, if the ticket is known. If the ticket isn't known, check if the `linear` MCP is available in the environment and make a temporary ticket based on the prompt given. Never ask the user for ticket numbers. +2. Commit title (using standard Git conventions) # Draft status