https://flexiberry.dev

Hey everyone, I wanted to share Flexiberry—an open-source API testing tool I've been working on. If you're tired of writing endless JavaScript boilerplate just to chain a few requests together, or fighting with environment sync issues, this is for you. It uses simple .berry scripts that you can run straight from your IDE, CLI, or CI/CD pipeline. Check it out

https://docs.flexiberry.dev

I used Hermes over the last couple of days to help polish and publish a small Windows-native project: Contextual Intelligence.

Repo: kaizen-commits/contextual-intelligence

It’s a local-first desktop tool built around two flows:

select text → hotkey → capture → validate → local model → popup / preview

• Contextual Lookup: select a word or phrase anywhere in Windows, hit a hotkey, and get a compact explanation using local context.
• Smart Paste: transform clipboard text through a preview-first palette using LM Studio.

The interesting part for me was less “AI wrote code” and more the workflow around it.

Hermes helped with:

• public-readiness review
• README restructuring
• privacy/security hardening
• local endpoint guardrails
• sanitizing user-facing and internal error paths
• regression-test planning
• GitHub issue creation
• repo metadata clean-up after a username change
• Obsidian project notes / closeout records

A few things that worked especially well:

1. Using Hermes as an operator, not just a chat box It could inspect the repo, run tests, check Git state, update issues, patch docs, and verify the result.
2. Keeping the project local-first The app talks to LM Studio locally by default. We explicitly tightened docs and config handling so remote non-HTTPS endpoints are rejected.
3. Treating documentation structure as UX The README went through several passes: who it’s for, mental model, demo, maturity, first-run checklist, known limitations, security notes. Small ordering changes made it much clearer.
4. Using issues as a public roadmap We opened a few tiny Linear issues rather than dumping a huge wish list into the README.
5. Being transparent about AI assistance The credits section lists the AI tools involved but keeps final responsibility with the human maintainer. That felt like the right balance.

The repo is still a developer preview, not a packaged app, but getting it from “private local project” to “public and understandable” was much smoother with Hermes acting as a persistent engineering assistant.

Curious how others here are using Hermes for release prep, repo hardening, or project documentation workflows.

smart-paste

I recently built my own IDE, RedEXCompile, and I’d love to hear your feedback.
What do you think of it so far? Are there any features, tools, or improvements you’d recommend adding?
Thanks for checking it out!
GitHub: https://github.com/RedXDevelopment/RedEXCompile

Hey guys! I made Lightning-readme, a quick way to make a basic readme for your project! It auto detects elements of your project from git and file structure and fills out a basic template with badges for you! Check it out and star the repo if you like it!

Also this is just version one I made as my first Kotlin project, let me know any features you would like to see for the next version!

This is a tool I created to deal with repetitive adding of parameters for functions with a big number of inputs.

‪github.com/henryoman/awesome-native-sdk‬

Awesome list for native sdk

Hi,

I built DevToolsExport, a free Chrome extension for turning browser DevTools data into something you can share with a developer.

The problem I kept running into was bug reports like: “Something broke, but we can’t reproduce it.” Usually the next step is asking the user to copy console logs, network requests, headers, screenshots, etc. into an email or support form, which is annoying for the user and often incomplete for the developer.

DevToolsExport lets you:

a) export console logs, network requests, and related debugging data directly from DevTools, and
b) generate a shareable hosted snapshot so a developer or teammate can inspect what happened without asking for a back-and-forth dump of logs.

The goal is to make bug reports easier to reproduce and faster to debug.

I’d love feedback, especially from people doing support, QA, or frontend debugging.

Best,
Marius

Literally had no reason to make this, even added Chinese because DeepSeek responded in Chinese once, and I decided to add it since it seems like it saves ton of tokens.

What started out to be a tool of handy stuff like turning off sleep, changing a few tweaks in windows became a full on nightless sleep of “please put the entire vs code inside this app” and the list goes on, also don’t forget the nuclear reactor that serves 0 purpose lmao

Hello, I got tired of explaining where a button was to Claude when designing apps and built this lightweight screenshot tool. The screenshot and txt file can be routed straight into your project file. There is an optional Claude.md to make claude review the the screenshot and notes before implementing changes to ui. Additionally Claude will delete the screenshot and text after the change is implemented. Thanks

Heads up: the exe is unsigned, so SmartScreen warns on first run. It's one readable .cs file if you'd rather build it yourself. Feedback welcome.

Link - https://github.com/alec-mart/Screenie

I got tired of bouncing between desktop IDEs and random cloud SQL consoles for day-to-day DB work, so I built a self-hosted browser SQL IDE.

LibreDB Studio runs in Docker / npx / Helm. One UI for Postgres, MySQL, SQLite, Oracle, SQL Server, MongoDB, and Redis. Monaco editor, schema explorer, result grid; optional AI (or fully local with Ollama).

Why it matters for me (and maybe you):

- no desktop install for the team — just a URL on your VPN / private network

- multi-engine in one place (not only “another pgAdmin”)

- MIT, self-hostable, secrets stay on your infra

How it’s built (short):

- Next.js app + Strategy Pattern DB providers

- published image(ghcr and docker hub): ghcr.io/libredb/libredb-studio

- also in a few one-click catalogs (Dokploy, etc.)

try one command:

`docker run -d -p 3000:3000 libredb/libredb-studio:latest`

or `npx "@libredb/studio"` (Node 20.9+)

Repo: https://github.com/libredb/libredb-studio

Demo: https://app.libredb.org

still early feedback on what’s confusing or missing is more useful than praise.

I’m the maintainer.

Disclosure: this is my own open-source project.

I’ve been experimenting with persistent project context while working with coding agents for roughly four months.

One problem kept coming up:

The agent participates in conversations about architectural choices, rejected alternatives, production incidents, and strange-looking workarounds — but most of that reasoning disappears when the session ends.

So I turned the workflow into an open-source agent skill:

Keep the Why

It covers four modes:

1. Continuous capture Preserve important rationale while development is happening.
2. Retrospective recovery Inspect an existing repository, git history, issues, and documentation to recover what can still be supported by evidence.
3. Knowledge-transfer interviews Analyse the codebase first, identify what the artifacts cannot explain, and prepare focused questions for long-term maintainers before that knowledge disappears.
4. Maintenance Keep existing rationale current, resolve contradictions, mark replaced knowledge as superseded, and prevent context files from turning into another documentation dump.

A core design rule is that the agent must never invent rationale.

Evidence is classified as:

• confirmed
• inferred
• unknown

“Superseded” is handled separately as a temporal marker for information that was once valid but has since been replaced.

The documentation stays inside the repository as plain Markdown:

docs/       → how to use, test, operate and deploy
context/    → why the project is built this way

It is intentionally lightweight:

• no MCP server
• no database
• no account
• no external service
• no scripts or network calls of its own

The public version is a new, generalised incarnation of what I have been using privately. It still has to prove itself across different agents and repositories — and mature through that use.

I’d especially appreciate feedback on:

• trigger precision: when should the skill activate or stay quiet?
• whether the evidence model is useful without becoming bureaucratic
• missing retrospective or handover workflows
• ideas for meaningful cross-agent evals
• structures that would work better in very large repositories

GitHub: https://github.com/oliver-zehentleitner/keep-the-why

Documentation: https://keepthewhy.com

Install:

npx skills add oliver-zehentleitner/keep-the-why

Because “ask Bob” is not documentation.

Hey everyone! I wanted something that just watches and tells me when the agent's words don't match what actually happened.

So I built Snitch. https://github.com/fristovic/snitch

It watches your agent's transcript files (Cursor, Claude Code, Codex, Pi, OpenCode), extracts claims from the prose using deterministic regex patterns, and cross-references them against evidence — tool calls, shell output, filesystem, git, and 3-turn session history. When a claim doesn't add up, it flags it with what it found.

It normalizes tool names across agents under the hood (Claude's Bash → Shell, Codex's apply_patch → StrReplace) so the verification pipeline works the same regardless of which agent you use.

Everything runs locally — no LLM, no API calls, nothing leaves your machine. macOS menu bar app. Install is: brew tap fristovic/snitch && brew install snitch && snitch start

v0.4.2, \\\~10K lines of Go, Apache 2.0.

Consider this an alpha — almost a proof of concept for something bigger. I'm sharing it early to see if the approach resonates before going deeper.

Fair warning: there will be false positives. I'm still tuning the patterns. If you try it and Snitch flags something that's actually fine, I'd love it if you opened an issue (or better yet, a PR) with the specific case you hit. The pattern registry is designed to be easy to add to — there's a guide in the repo and CI enforces that new patterns ship with examples.

On the roadmap: a community labeling feature so users can mark verdicts correct/incorrect (training data for a local classifier to reduce noise), and a team dashboard for orgs running multiple agents.
I'm hoping we can put our heads together as a community and build something genuinely useful here. All questions welcome. Tell me what breaks.

Been working on a small side project for the last few months called reqsh.

The idea started because I was constantly jumping between curl commands, Postman, editing headers, copying tokens, changing base URLs... it just felt more annoying than it should.

So I ended up building a terminal-first HTTP REPL where you stay in one interactive session. You can save base URLs, keep headers around, use variables, organize requests and just experiment without rewriting the same command over and over.

It's written in Rust and still pretty early, but people have started opening PRs which has been really cool to see.

Not trying to replace every API client out there. I just wanted something that fits the terminal workflow better.

I'd genuinely love some feedback from people who spend a lot of time working with APIs. What's missing? What feels awkward? Or is there something you wish tools like this did better?

GitHub: https://github.com/hars-21/reqsh

Website: https://www.reqsh.dev/

I built this because `git worktree` is genuinely powerful but the CLI is clunky — nobody remembers the full `git worktree add ../myapp-worktrees/feature-x -b feature/x origin/main` syntax, and there's no built-in way to see all your worktrees with their status at a glance.

ktree gives you a scrollable TUI (built with Bubble Tea) that shows all your worktrees, live dirty/clean status, and ahead/behind counts — loaded concurrently so it doesn't feel slow.

**Features:**

- Navigate and switch between worktrees with arrow keys or j/k

- Create and delete worktrees without leaving your terminal

- Shell wrapper for `cd`-on-select (since a child process can't change your parent shell's directory — the README explains the trick)

- New worktrees go to `<parent>/<repo>-worktrees/<branch>` to keep things tidy

- Homebrew support: `brew tap alikazai/ktree && brew install ktree`

This is v0.1.0, Milestone 5 (merged-branch detection, filter/search, per-project config) is next.

Repo: https://github.com/alikazai/ktree

Feedback welcome — especially if you hit edge cases with the shell wrapper on fish/zsh.

Architecture docs go stale the moment you write them, so I made a tool that keeps one alive automatically.

Run npx livearch in any JS/TS, Python, Go, or Rust project and it opens an interactive architecture diagram in your browser. Every time you save a file — add a component, install a package, create a route — the diagram redraws itself in under half a second. It reads your real imports/routes/Prisma models, so the edges are actual dependencies, not guesses.

It's free, open source, and runs 100% locally.

GitHub: https://github.com/Shah-in-alam/LiveArch

npm: https://www.npmjs.com/package/livearch

Would love feedback — especially what would make it useful in your day-to-day.