We've been running a lightweight FinOps script review process for months, but it was manual: someone had to remember to run a Claude Code review on pull requests for our AWS cost anomaly detection scripts. I wanted to bake it directly into our GitHub Actions workflow to make it consistent and automatic.
The goal was to trigger a Claude Code review on every PR that modifies scripts in our `finops-scripts/` directory. I didn't want a generic "review all code" setup—just targeted analysis on our cost tooling. Here's the core workflow file I landed on after some trial and error.
```yaml
name: FinOps Script Review
on:
pull_request:
paths:
- 'finops-scripts/**'
jobs:
claude-code-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Claude Code Review
uses: Anthropic-Devs/claude-code-review-action@v1
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
review_instruction: |
Please review this FinOps script with a focus on:
* Cost optimization logic (e.g., Reserved Instance calculations, spot interruption handling)
* Error handling for AWS/Azure API calls
* Potential billing data misinterpretations
* Suggestions for improving runtime efficiency (these scripts run hourly)
```
A few key configuration points I found necessary:
* The `paths:` filter is crucial to avoid running reviews on every PR, which keeps costs predictable.
* The custom `review_instruction` steers Claude toward our specific FinOps concerns, not just general code quality.
* Storing the `ANTHROPIC_API_KEY` as a repository secret is straightforward, but remember to monitor its usage in your Anthropic account.
The main benefit has been catching subtle bugs early—like an off-by-one error in a monthly cost projection script that Claude flagged. The reviews are posted directly as PR comments, which keeps the feedback in the development loop.
Has anyone else integrated Claude Code into their CI/CD for specific domains like this? I'm particularly curious about:
* How you're handling the cost of the API calls in a high-volume repo.
* Whether you've set up different review instructions for different script types (e.g., budget alerts vs. resource cleanup).
I see you're using the Anthropic-provided action, which is a solid starting point. One thing I'd add to your `review_instruction` is explicit guidance on cloud service API usage patterns. Many FinOps scripts inadvertently create cost leaks through pagination issues or missed rate limiting.
For example, your anomaly detection scripts probably call the Cost Explorer API. Claude should flag if you're not implementing exponential backoff on `ThrottlingException` errors - those retries can inflate Lambda execution time and costs. Also, watch for scripts that pull full datasets when incremental queries would suffice; I've seen scripts that pull 90 days of data daily when only yesterday's delta matters.
Consider adding these specific checks to your instruction:
* Verify API calls use appropriate time ranges and granularity
* Check for unnecessary data transformations that could be pushed down to the query
* Ensure error handling doesn't create infinite retry loops on billing data
Have you considered setting up a cost threshold for the review action itself? The Anthropic API calls add up, especially if you have frequent PRs.
Every dollar counts.
Great point about API usage patterns! I've definitely seen our own scripts pull full Cost Explorer datasets when a simple daily delta would work - it's an easy oversight when you're just trying to get the data flowing. Adding those specific checks to the review instructions is smart.
The cost threshold idea is crucial too. We started with unlimited reviews and got a bit of a shock our first month with dozens of PRs. We now use a simple check at the start of the action to skip if it's not a core contributor or if the PR is draft. Still exploring better ways to gate it though - maybe only on files above a certain complexity score?
Have you found a good way to catch those pagination issues automatically? Sometimes Claude misses them unless you're super explicit in the prompt.
Happy testing!
The complexity score gating is an interesting angle, but I'd worry it adds another layer of tooling to maintain. We've had better luck with a more direct cost-based gate: we only trigger the review if the changed files contain specific high-cost service calls.
For pagination, yes, you have to be explicit. We instruct Claude to literally trace the logic flow for any `boto3` client method call and flag if the return doesn't handle `NextToken` or a paginator. Example prompt addition:
```
Specifically, for any AWS service client method call (e.g., `get_cost_and_usage`, `describe_instances`):
1. Identify if the operation is paginated.
2. Verify the code either uses the paginator interface or manually checks for and consumes `NextToken`/`NextMarker`.
3. Flag as a high-severity finding if pagination is not handled.
```
Without that exact wording, it tends to offer generic advice rather than a concrete check. Have you quantified the cost delta between a full dataset pull and an incremental one in your environment? I find putting actual dollar figures in the review instructions sharpens the focus.
CostCutter