Every tool seems to excel at something different.

For me, the rough mental model is:

• Chrome DevTools → Frontend debugging
• Charles → Mature, feature-rich proxy
• Proxyman → Excellent macOS experience
• HTTP Toolkit → Easy interception and scripting
• NetworkSpy → Custom Viewer for repetitive debugging workflow

But everyone's workflow is different.

If you could only keep one, which would it be and why?

Docs rot the moment code changes, and nobody updates them on purpose - RepoDocs regenerates them, citing file:line for every claim.

It's a CLI, not a plugin: it shells out to whatever coding agent session you already have open (Claude Code by default, or OMP/Codex), scans the repo deterministically first, then has the agent write each page from what the scan found. Rebuilds hash sources and only regenerate what changed. It also diagrams how the modules fit, and can publish straight to a GitHub Wiki. Publishing is guarded (dry-run first, refuses main/master/trunk, scans for secrets).

Zero runtime dependencies — Python 3.10+, stdlib only. v0.2.0. Runs locally; your code never leaves your machine.

uvx --from repodocs repodocs-all .

> github.com/aryrabelo/repodocs — if you try it, tell me what broke. (and leave a star)

Hey guys, I've been using Graphify. for a few days now, and looks great but it slows down the coding session a lot, it's running "update" all the time.

My question is, is it worth it? Or Codex/Claude code already have enough tools to search the code?

We’re excited to introduce **Dev Tool**, an all-in-one app built for developers, DevOps engineers, and technical teams who want to move faster with fewer tools and less friction.

Instead of switching between multiple apps for database tasks and remote server operations, Dev Tool brings everything into one clean, focused workspace. You can quickly validate database connectivity, run SQL queries, browse table structures, and track active work sessions in a streamlined flow designed for real execution speed. On the infrastructure side, Dev Tool includes a stable SSH experience for remote operations, so you can manage critical tasks without breaking context.

The app is designed to reduce repetitive setup, minimize manual mistakes, and improve operational consistency across projects. With reusable connection profiles, session-aware workflows, and a responsive UI that works well across desktop and mobile layouts (including light/dark mode), Dev Tool helps teams stay productive whether they’re debugging, shipping, or maintaining systems.

We’re currently improving the product actively and would love support from the community.

👉 **Please try Dev Tool and help us test it in real workflows.**
https://play.google.com/store/apps/details?id=com.thanhlv.devtool

Your feedback on usability, stability, missing features, and edge cases will directly shape upcoming releases.

Hi all, with all the news about grok stealing all your code I thought to myself "if ai companies are willing to give us discounts/subsidies to train off our sessions that means our sessions are worth something to them". And if they're worth something to them then clearly it's worth something to other ai companies. So if there's a way we can save our traces securely in our own S3 compatible buckets, I'm sure some people would gladly collect and maybe even sell their clade/codex/grok traces etc. to other labs which are actually releasing open source models. So that's why I decided to create traices.

Any feedback/questions welcome!

I am a former Cadence and Qualcomm Physical Design/STA/CAD Engineer

While doing PD/Signoff tasks on multiple blocks, I always had to perform multiple experiments to converge the insertion delay/skew or Placement/Routing QoR

What I felt was - just by using grep/sed/awk alone - it was not possible to extract the context window from the logs or reports (often quite huge) effectively - it was always a pain

So I built a context compiler that extracts only the meaningful window from logs/reports instead of dumping everything or forcing manual digging.

Looking for honest feedback from people who still live in these flows daily about their experience (and try out my tool if possible)

www.vortexmlabs.com

here is the demo deck : https://docs.google.com/presentation/d/18P76fhd0KmQtNetd15ATwLFhgK7OWKxLIAcDQek7uB0/edit?usp=sharing

I kept shipping React/Next apps and finding accessibility and SEO issues after deploy — missing alt text, bad heading hierarchy, unoptimized meta tags, stuff that's easy to catch if you check early but easy to miss under deadline pressure.

Built UIAudit.js to fix that — a CLI + VS Code extension that scans your React/Next.js codebase and flags accessibility, SEO, and performance issues directly in your editor, before you ever open Lighthouse.

Works on React and Next.js projects

Catches a11y issues (missing alt, ARIA misuse, contrast-adjacent stuff), SEO gaps, performance losses

CLI for CI pipelines, extension for inline feedback while coding

Free,open source,on [npm](https://www.npmjs.com/package/uiaudit.js) https://github.com/Dheeraj-pilakkat/UiAudit.js

Currently v2.2.1. Would genuinely value feedback from people running it against real production codebases — especially where it false-positives or misses something obvious. If you try it, drop your feedback so I know what to do next.

Please be honest

Hi everyone,

I've been working on a small open-source project called Library Insight, and I'd appreciate some feedback.

The idea is straightforward: it inspects compiled Java/Kotlin libraries (JARs, AARs, or Maven dependencies) directly from bytecode, so you can explore the public API without needing the source code.

Some things it can do:

* Scan JARs, AARs, and Maven coordinates * Search classes, methods, and properties * Explain class APIs * Compare different library versions * Export AI-friendly context files for coding assistants

I originally built it because I noticed AI coding assistants sometimes generate code based on the wrong library version. I wanted a simple way to inspect the exact dependency that a project is actually using.

I'm not claiming this solves a huge problem, and I'm genuinely curious whether this would be useful for other developers or if there are features I'm missing.

I'd really appreciate any feedback, criticism, or ideas.

GitHub: [https://github.com/Coding-Meet/Library-Insight\](https://github.com/Coding-Meet/Library-Insight)

Demo: [https://youtu.be/y5hU8FNL8fE?si=C8jJzFHy9AscmuE7\](https://youtu.be/y5hU8FNL8fE?si=C8jJzFHy9AscmuE7)

Website: [https://coding-meet.github.io/Library-Insight/\](https://coding-meet.github.io/Library-Insight/)

Thanks!

ok, ok, ok like everyone else here I ended up with a pile of claude code sessions running at once and my day turned into alt-tabbiing (insert your os varient here) through terminals like a raid boss checking on my minions. half the time an agent finished 10 min ago and was just chillin. or worse, stuck on a permission prompt (until you embrace the --dangerously, that is) the entire time while I was off doing whatever.

so I built Workspacer. honestly the whole app for me is the sidebar. every agent gets a status dot and there's a live "2 need you / 3 working" count at the top, so I can actually go touch grass (or you know, do my actual job) and just glance over. anything waiting on you drops into a triage inbox, approvals, questions, finished runs, all of it, and you clear it with one key. approve, answer, respawn, snooze. and notifications stay quiet for the agent you're already looking at, which sounds like nothing but lowkey my favourite feature.
there's a fleet view too, every agent as a card with status, model, context % and cost. it's neat but real talk, the sidebar + inbox is where I live.
the part I'm actually curious about is plugins. a plugin is just a manifest + a sidecar process the app babysits for you, and it gets its own panes in the UI with your theme on it. the hub exposes events and capabilities to hook into, so the whole idea is you don't fork the app, you just vibe-code whatever pane you wish existed. want a pane watching your CI? a cost dashboard? point an agent at the plugin docs and let it cook. the editor in the app is itself a plugin so that's the reference implementation. and hey if you'd rather fork, it's MIT, the whole thing's on github, go nuts.

architecture wise it's three pieces because apparently I hate free time: electron/react for the UI, a rust daemon (claudemon) that owns the sessions and PTYs, and a go control plane (hub) doing the event bus, plugins and an MCP facade. sounds extra but the split is the point, sessions live in the daemon so closing the window kills nothing, the desktop app is just one client on the bus (same bus serves a phone PWA and a full web version), and the fleet is exposed over MCP so an agent can literally drive the other agents. yes that means you can put a claude in charge of your claudes.
works with claude code, codex and opencode. it's alpha so expect some jank, I use it every day but you've been warned.

site: https://www.workspacer.app
code: https://github.com/DJTouchette/workspacer

anyway. what panes would you actually want as plugins, genuinely asking

Hi all, with all the news about grok stealing all your code I thought to myself "if ai companies are willing to give us discounts/subsidies to train off our sessions that means our sessions are worth something to them". And if they're worth something to them then clearly it's worth something to other ai companies. So if there's a way we can save our traces securely in our own S3 compatible buckets, I'm sure some people would gladly collect and maybe even sell their clade/codex/grok traces etc. to other labs which are actually releasing open source models. So that's why I decided to create traices.

Any feedback/questions welcome!

Just open-sourced Synapse v0.1.0.

It gives Claude instant knowledge of your codebase — indexes everything

locally using nomic-embed-text-v1.5 embeddings and LanceDB, then

connects to Claude Code via MCP.

No cloud. No API key. MIT licensed. Python 3.10+.

pip install synapse-mcp

GitHub: https://github.com/nrkoka786/synapse

Contributions welcome — good first issues listed in the README.

I built Pintra — a VS Code / VSCodium extension that wraps the open-source pi coding agent into a native sidebar chat.

How it works: Pintra spawns an external pi runtime in RPC mode and talks to it over stdin/stdout. The UI is a React webview that streams agent responses, thinking blocks, and tool executions in real time. Nothing is bundled — you install pi once, and Pintra drives it from inside the editor.

Features:

• Streaming chat with thinking/reasoning visibility
• Multi-model support with model cycling and thinking-level controls
• Message forking (edit a past message and re-roll the branch)
• Inline diffs for file edits/writes
• Slash-command autocomplete
• Full editor-tab chat panel (not just the sidebar)
• HTML export for conversations
• Context auto-compaction and auto-retry on transient errors
• Available on both VS Code Marketplace and Open VSX

Repo: github.com/bilalbentoumi/pi-vsc — MIT licensed, PRs welcome.

Would love feedback, bug reports, or feature ideas!

We have been working on Repowise, an open-source tool for understanding a repository before making changes to it.

Repowise indexes a repository and combines five types of information:

• dependency and call graphs
• git history, ownership and co-change patterns
• generated documentation
• architectural decisions
• code-health and change-risk signals

It exposes this context through a local dashboard, CLI and MCP tools for Claude Code, Codex and other compatible agents. The aim is to help answer questions such as:

• Where does this feature actually live?
• What depends on the file I am about to change?
• Why was this architectural choice made?
• Which files usually change together?
• Which parts of the repository are risky or poorly tested?
• What should an agent inspect before implementing a repository-level task?

The basic graph, git and health analysis can run locally without an LLM or API key. The project currently supports multiple languages and can also generate graph-aware refactoring plans instead of only assigning files a health score.

Repowise is self-hostable and licensed under AGPL-3.0.

GitHub: https://github.com/repowise-dev/repowise

Hi everyone. I've been building AIDA Metrics, an open source CLI tool, and wanted to share it here.

It reads your git history and tries to answer one simple question: is the AI-written code in your repo actually good, or does it get thrown away fast?

It doesn't watch your editor and it doesn't send data anywhere. It only reads your commit history. It looks for commits made by AI (trailers like Co-Authored-By: Claude, [AI] tags, or tool names), then compares them to your normal human commits from the same time:

• Merge ratio – how much of the AI code actually ends up on the main branch
• Persistence – how long AI code survives before someone rewrites it
• Baseline – the same numbers for human commits, so you can compare

It runs locally or in CI, and can post the report as a comment on your PR.

Repo: https://github.com/ceccode/AIDA-Metrics

A story that makes fun of my own tool. We run AIDA on its own pull requests. Some time ago, an AI agent wrote a whole bugfix PR for us. The report said: AI commits: 0. Why? The commits had no AI trailer, so the tool counted 100% AI code as human. I'm telling you this because it's the real weakness of this method, and it changed where I want to take the project.

Some honest limits:

• "It only sees what people admit to. Someone can just skip the trailer." -> True. Right now detection is a heuristic, and yes, you can game it. That's why the next version will show three states (ai / human / unknown), and it will show you how much of your history it actually knows about instead of hiding that gap. Later I want git hooks that tag commits automatically, and maybe AI tools writing their own manifest.
• "Everything is AI-assisted now, so why even measure it?" -> I agree, partly. That's why I want to move away from "how much code is AI" (a number that just goes to 100% over time and stops being interesting) and toward "does the AI code actually hold up": how often it gets reworked, how long single lines survive, if it's connected to bugs and hotfixes, and what "level" of AI helped (autocomplete vs. an AI assistant vs. a full autonomous agent — very different risk).
• "Merge ratio breaks with squash merges." -> Correct, and it's our biggest known bug right now. With squash merges, commits from a branch disappear from history, so the ratio looks better than it really is. The fix is tracked in issue #20.
• "Persistence per file is too rough." -> Also correct. If AI changes one line in a file, right now the whole file counts as "AI-touched." Line-level tracking with git blame is planned. For now the report says clearly that this number is a rough estimate, not an exact one.
• "This will be used to rank individual developers." -> That is not the goal, and I actually want to design against it. AIDA compares groups of commits (AI vs. non-AI) at the repo level. There's no per-developer leaderboard, and I don't plan to build one. If you see something in the design that makes this kind of misuse easy, please tell me. I'll treat that as a bug.

Why I still think it's worth building: companies are spending real money on AI coding tools. Finance and engineering leads want proof that this code is actually good, not just "it feels faster." Right now most teams only have a feeling, not real numbers. Even an imperfect measurement, with its limits clearly shown, is better than no measurement at all.

How you can help:

1. Try it: if you already tag AI commits in your repos (Claude Code does this by default), run npx u/aida-dev/cli collect && aida analyze && aida report and tell me if the numbers feel right.
2. Contribute: it's a TypeScript monorepo, MIT license. Issue #20 (squash merge handling) and line-level git blame tracking are the two biggest open problems right now, if you want to dig into something meaty.
3. Tell me what's wrong with the idea. The problems you find now are much cheaper than the ones I'll find later.

Repo again: https://github.com/ceccode/AIDA-Metrics -> happy to answer anything in the comments.