Like a lot of you, I routinely paste logs, stack traces and .env snippets into AI tools. Every so often a real key slips through, so I built LeakGoblin.

It's a small TypeScript CLI that works on stdin or a directory:

bash

npx leakgoblin scan --stdin < prompt.txt
cat prompt.txt | leakgoblin sanitize --stdin > safe.txt
leakgoblin scan . --format json

What it does:

• Format-specific signatures (AWS, GitHub, Stripe, Slack, Google, OpenAI-style keys, private key blocks, JWTs, connection strings) plus a clearly labeled low-confidence entropy heuristic
• Output is always masked, and JSON output strips raw values
• Runs fully offline, with no telemetry
• CI-friendly exit codes (0 clean / 1 found / 2 error)
• Config file for custom patterns, thresholds and an allowlist

It is a best-effort filter, not a guarantee. It will miss unusual formats, so review the output before sharing.

npm: https://www.npmjs.com/package/leakgoblin GitHub: https://github.com/lovixcloud/leakgoblin

I'd love feedback on false positives and missed formats in particular. Send me a synthetic example and I'll add a rule.

f your Go debugging loop is: send the request in Postman, switch to the IDE, hope the breakpoint hits, open pprof in a third window, tail logs in a fourth — adOmnia puts that loop in one app.

Recognized HTTP routes link to their handlers. "Debug Request" attaches Delve, pauses in the handler, and shows frames, variables and goroutines next to the API response. With capture on, the SQL and Kafka messages the request produced come along for the ride.

Go side: gopls, test explorer + coverage, Delve (conditional breakpoints, goroutine inspection), pprof, execution traces, architecture/impact views. Around it: an API client (REST/gRPC/SOAP/WebSocket), database tools (Postgres/MySQL/Mongo/Redis/SQLite), broker and log viewers.

Local-first, no account, no telemetry, MIT, built with Go + Wails. Runs on Windows/macOS/Linux.

Releases: https://github.com/Andrea-Cavallo/adOmnia/releases/latest

hi, i built a video editor called kimo — it's free and open-source (MIT), about 15 MB, CPU-only, single Rust binary that runs on a 2 GB box. there's no GUI: an AI agent drives it over MCP and does cut / trim / titles / captions / colour grade / export as tool calls, and can render a frame to check its work before committing.

built by me, a college student, so there are rough edges. please try it and tell me what breaks.

https://getkimo.tech https://github.com/naman-sharma12345/kimo

It's crawler that finds interesting projects in github based on how much stars they get and how fast so projects that are getting popular fast are the easier to find, there are different durations here like a day, a week or a month

I manage two engineering teams, 12 engineers in total. Over the past few months, complaints about PR reviews have been coming up more and more. Too many PRs, reviews taking too long, and people getting blocked waiting for someone to take a look.

It's become one of our biggest bottlenecks to shipping.

We also recently had a regression where an improvement to one of our core features ended up breaking three other important functionalities. We spent the next two weeks fixing regressions.

That got me thinking quite a bit about how we review code. We need to review faster, but clearly we can't afford to be less thorough either.

I've been building an open source tool called Alden to try to help with this, and I've used Claude Code quite extensively to build it.

Claude helped me design the UI, built most of the website, wrote the documentation and helped implement the deterministic pipeline that runs the checks. I also used it for QA, which was probably one of the more interesting parts of the process. I had Claude draft test cases from my acceptance criteria, then open a browser and test the same scenarios I was testing manually, in parallel. Basically a second pair of hands doing QA alongside me.

I recently added a Claude Code plugin so I could use Alden directly in the same environment I'd been building it with.

The idea is fairly simple. Rather than having Claude review a diff and dump a bunch of comments, Alden gives it more context about the change and helps you figure out where to spend your attention.

For example:

• /alden:queue shows the PRs waiting for your review and ranks them.
• /alden:review 2 prepares a brief on the second PR in your queue, including potential issues and callers of changed functions outside the diff. Claude can then investigate further.
• /alden:remember "Money is in cents, never floats" saves context that gets included in future reviews of that repo.

You can also ask Claude to review a specific PR or tell you what's waiting on you.

One design decision I made was to keep submitting reviews separate from the agent. Claude can draft comments in Alden, but the plugin doesn't give it a tool to publish them. You review and submit them yourself.

To be clear, this isn't a security boundary. Claude Code may have access to other tools or credentials that could let it interact with GitHub. I'm just deliberately not making publishing part of the plugin's workflow.

There's also a feedback loop where you can tell Alden which findings were useful so it can adjust what it prioritises over time.

The plugin uses Claude Code's existing model, so you don't need a separate model API key for it.

It's open source and free.

GitHub: https://github.com/getalden/claude-plugin

Docs: https://getalden.dev/docs/claude-code

I'm curious how others are dealing with this. Have PR reviews become a bottleneck for your teams too? And has AI actually helped you review faster without compromising quality?

**Setup**

- React Native 0.87.1

- Xcode 27.1

- iOS Simulator (iPhone 18 Pro, iOS 27.0)

I've hit this a lot: the app dies on iOS, the JS console is quiet, and it's not obvious where to start. Most of the time the answer is on the native side, so here's the process I use. I call it RIFT.

**R – Reproduce**

Run the app from Xcode (not just from the terminal) and trigger the crash. Add a breakpoint near where you think it happens so you can pause instead of watching the app die.

**I – Investigate**

When it stops or crashes, look at the exception message and the backtrace in the left panel. In my example, a native module method called from JS threw an uncaught NSException, and the console printed the reason. Then in LLDB:

- `bt` – print the backtrace

- `frame select <n>` – jump to a specific frame

- `po` / `p` / `expression` – inspect values at that point

**F – Fix**

Change the actual cause in the native code (in my case, the method wasn't validating its input), not just the symptom.

**T – Test**

Re-run the exact same steps and confirm the crash is gone. Skipping this step is how "fixed" bugs come back.

I recorded a ~22 min live walkthrough of this on a real crash if it's useful to anyone: https://youtu.be/oGq0yZ3z9ks

Happy to answer questions. What's your usual first step when a crash shows no JS error?

Built this to solve a specific annoyance: when something crashes in production, the log is the last place anyone wants to be at 3am. Watcher runs in the background, tails your logs, and when it sees a crash, explains the root cause using a small LLM running locally through Ollama, no cloud calls, nothing leaves the machine.

What it does:

• Watches a file, stdin, or a Docker container's logs
• Deduplicates repeated crashes into one incident instead of alerting per occurrence — a crash loop produces one incident with a live count, not a flood
• Reports a structured explanation (likely cause, suggested fix, confidence) to the terminal, as JSON, or over a webhook
• Flags its own confidence as low when the evidence it cited doesn't actually hold up in the excerpt it was given, rather than guessing with false certainty

Two real examples from testing: killed a database connection, and it named the cause correctly with full confidence, because the evidence actually held up. Separately, pulled a required env var, it still named the right cause, but flagged its own confidence as low because part of what it cited wasn't in the excerpt. That second one is the part I actually care about with a model this small — it'll be wrong sometimes, the real question is whether it knows when to hedge.

Known rough edges: onboarding and the TUI (watcher attach) both work but need polish, Docker Compose packaging and in-repo evaluation scoring aren't done, and I'm still chasing down why inference latency is higher than it should be on constrained hardware (~2 min per explanation right now on a 2 vCPU / 4GB box with a 1.5B model).

MIT licensed. Feedback, issues, and PRs genuinely welcome; a few issues are tagged for first-time contributors if you want somewhere to start.

I built a VS Code extension for people who want to manage their GitHub docs without leaving the current workspace.

GitHub README lets you browse your repositories, open any README, edit it, preview the rendered Markdown, and push the changes back to GitHub all without leaving the current workspace.

Basically:
VS Code → pick a repo → edit README → preview → commit → done.

No jumping between GitHub, cloning repos, or switching windows just to change a README

#- https://marketplace.visualstudio.com/items?itemName=itshakemd.github-readme

1-

2-

3-

The github default pr dashboard not very useful or user friendly, however, now I coding work are mostly done by agent with high volume of prs. I really need a powerful pr dashboard to monitor/manager prs from agent. So I build this tool with codex and claude designer. It supports almost all actions at pr level, detailed code review is not the goal for this tool. Please try it and leave feedback.

Installation: `gh extension shiqicao/gh-pull`.

Source code, https://github.com/shiqicao/gh-pull

One feature in my app turned out to be more fun than expected. An agent running in Lattice can open helper agents, each in its own window with its own git worktree so they never edit the same files. The main agent can wait for them, read what's on their screens and send them instructions, and I can watch the whole thing happen and step in whenever I want.

Each helper still asks me for approvals in its own window, so nothing runs behind my back. It's been great for splitting up bigger tasks like "fix these three bugs" into parallel work.

Lattice is a free Mac app in public beta. Curious whether anyone else has tried this kind of setup and how it went for you.

All i want is some honest feedback, what to improve and what to add, download it here: uselattice.site

Hey everyone!

I've been working on Boiler, a command-line tool that helps developers create, manage, and reuse project templates. I just released its first beta version, `v0.0.1-beta`.

The idea is simple: instead of repeatedly setting up the same project structure, you can save it as a template and reuse it whenever you start a new project.

What Boiler can do:

* Create and manage project templates.

* Add files and directories to existing templates.

* Set a current template for easier access.

* Initialize new projects from saved templates.

* Manage everything through a CLI.

I've also packaged it as a Windows executable with an installer.

This is my first beta release, so I'd appreciate honest feedback! I'd especially like to hear what features you'd find useful and what could be improved.

GitHub: https://github.com/MrPsyghost/Boiler

Download: https://github.com/MrPsyghost/Boiler/releases

Thanks for checking it out!

Sharing SessionSift, a tool I vibe-coded and then tested and used myself to review AI coding sessions. I wanted to compare long conversations with separate sessions, inspect prompt patterns, and improve how I direct coding agents.

It's a free, local-first way to inspect historical Codex and Claude Code conversations. Features include session browsing, token and tool activity, comparisons between sessions, explicit imports of ChatGPT/Claude exports, and 10 read-only local MCP tools.

No account or cloud backend is required to run the dashboard. Connected MCP clients may still send tool output to their model providers. Screenshots and installation instructions are in the repo.

Current release: native macOS Intel and Linux AMD64, with source/Docker options. macOS binaries are unsigned and unnotarized. License: PolyForm Noncommercial 1.0.0 (source-available, not OSI open source; commercial use isn't licensed).

https://github.com/LanceSandino/sessionsift

Would welcome technical feedback on what makes session-history tools useful versus just another log viewer.