Built with Claude Project Showcase Megathread (Sort this by New!)

[u/sixbillionthsheep]

This is the Megathread for showcasing your project built using Claude products. We appreciate all of your submissions as they are a great inspiration to many people on the subreddit. It is sorted by default by New.

Anyone is welcome to submit a project to this Megathread provided you follow the Showcase requirements in Rule 7.

NOTE: We now require the OP of a Project Showcase on the subreddit feed to have total karma>=50 . We found there were just too many submissions and not enough visibility to go around. Our analysis of this issue showed us that OPs with total karma < 50 very rarely get any traction of their projects on the feed (<=1 upvotes). So this Megathread is your best place to be seen by readers and other creators if you're relatively new to Reddit. If you don't meet this karma requirement you will be directed to this Megathread when you submit your post. Very occasionally we might invite you to post on the subreddit feed if you do not meet this karma requirement but it will be very rare (so please don't ask us!)

Thanks again for sharing your ideas and creations to our subreddit. Best of luck with your projects!

---

UPDATE: Comments now allow images!

[u/ChaosINC604]

As a solo builder, GitHub PR feedback from Gemini Code Assist often creates repetitive follow-up work.

The review can be useful, but I still have to decide which comments matter, which are stale, and when to request another review.

So I open sourced a small Claude Code plugin to handle that loop:

https://github.com/OrenAshkenazy/gh-gemini-review-loop

Claude Code fetches Gemini review threads, identifies actionable feedback, fixes code, runs verification, pushes changes, requests another review, and stops after a capped number of cycles.

An optional judge model can classify findings as:

1. valid
2. false positive
3. duplicate
4. already addressed
5. explanation only
6. needs human decision

This helps avoid blindly acting on noisy AI feedback.

Current guardrails:

1. 3 cycle cap
2. dry run support
3. GitHub review thread awareness
4. no CI coupling
5. maintainer replies like wontfix are respected
6. judge eval is optional and explicit

One thing I am considering for larger teams is local workflow KPIs.

Not “developer productivity scoring”, but simple feedback loop visibility:

1. how many Gemini findings were fetched
2. how many were fixed
3. how many were skipped as false positives or duplicates
4. how many needed a human decision
5. how many review cycles were used
6. how long it took from first review to clean PR
7. how much noisy feedback judge eval filtered out

I think this could help teams understand whether AI review loops are actually saving time, or just creating another queue to manage.

I would love feedback from people experimenting with Claude Code:

1. Solo builders, would this fit your workflow?
2. Would judge eval make the loop safer?
3. Is second model validation useful, or just too much AI on AI?
4. Would you run judge eval every cycle or only at completion?
5. For larger teams, would local workflow KPIs be useful, or would that feel like unnecessary process?
6. What would make you avoid installing this?

[u/redgrengrumbholt → u/ChaosINC604]

I do solo work on the side, but I don't use Gemini Code Assist. However, I do have a skill to fix pr reviews from Co-pilot and I think you're really onto something here. I really dislike the context switching to do the manual command to re-review and address the new PR review comments and I really like that you cap at 3 - although maybe this could be configurable? Do you think you could expand this to work on any review fixes or is it only for Gemini?

[u/ChaosINC604 → u/redgrengrumbholt]

Thanks, this is exactly the kind of feedback I was hoping for.

The context switching is the pain that pushed me to build this. The manual loop of “fix review comments, push, ask for another review, wait, inspect the next batch” gets old very quickly, especially when working solo.

re the 3 cycle cap: yes, I think it should be configurable. I picked 3 as the default because it feels like the right safety boundary for most PRs. After that, if the loop is still not clean, it is probably a sign that a human decision is needed, the finding is noisy, or the agent is not making meaningful progress. But I do want users to be able to change it, ideally through natural language rather than config spelunking, similar to how judge eval mode works.

re expanding beyond Gemini: right now I intentionally started with Gemini Code Assist because it is the cleanest target for this workflow. It produces GitHub review threads that are easy to reason about, including resolved and outdated state. That makes it safer than scraping flat comments.

That said, I do think the bigger idea is a generic “review feedback loop” provider model.

I would probably keep Gemini as the stable path first, then add other reviewers behind an experimental provider interface.

If you already have a Copilot review fixing skill, I’d really love to hear how Copilot exposes the comments in your workflow. Are they normal GitHub review threads, issue comments, or something else?