feat: Changes to skills
This commit is contained in:
Nicholas Novak
@@ -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.
|
||||
@@ -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 <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.
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user