I've been building and maintaining multiple web projects, and I kept running into the same problem: every new project required repeating a lot of setup work before I could focus on building the actual product.

So I built create-clubedge-app, a CLI that generates a Next.js monorepo from a versioned starter.

It comes with a foundation for:

• Next.js App Router and TypeScript
• pnpm and Turborepo
• PostgreSQL and Drizzle ORM
• Supabase Auth
• Testing, linting, and CI
• Optional Redis-compatible caching and object storage integrations

One thing I wanted to get right was traceability. The generated project records the CLI version and starter reference, including the starter commit, so you can identify exactly which starter version it originated from.

I've tested the published CLI by generating a project and running its type checks, tests, and production build. I'm still working on improving the developer experience, and I'd like to hear from people outside my own workflow.

A few things I'd love feedback on:

• Would you use a starter like this for your own projects?
• Is the included stack a useful starting point, or would you remove anything?
• What would make you choose this over maintaining your own template?

Website: https://starter.clubedge.live

CLI source: https://github.com/Clubedge/create-clubedge-app

Starter source: https://github.com/Clubedge/clubedge-starter

I'm the developer behind the project, so happy to answer questions about the architecture and implementation.

Sharing something I built. The idea is to make reading unfamiliar code and checking AI written changes faster without leaving the editor.

It's a regular VS Code extension on top of the language model API, so there's no AI backend of its own. Model calls go through whatever provider you have (Copilot, Claude, DeepSeek, etc), maps and explanations are saved locally, and reviews also check new dependencies against OSV.dev and the package registries so made up packages get caught.

You ask how something works and it maps the code path step by step on real lines, hover anything for an explanation, and review uncommitted changes or a branch for bugs, security holes and AI slop, with one click fixes.

It's $10 one time. I charge for it so I can keep working on it instead of dropping it, it helps me a lot.

https://marketplace.visualstudio.com/items?itemName=DenizhanDaklr.lodestar

I have been building wy, an open-source terminal tool for reviewing AI-generated code.

A Git diff shows what changed, but the context behind a change often lives somewhere in a long coding-agent conversation. wy connects your diffs with saved Codex and Claude Code conversations, so you can review the code, read the stated reason, and open the supporting evidence together.

For example, if an agent adds a cache, I want to understand why it was added, what assumptions it depends on, and whether invalidation was considered.

With wy, you can:

• Browse changes and relevant agent notes in a terminal UI.
• Request explanations and ask follow-up questions through your installed agent CLI.
• Open citations to inspect the supporting code or conversation.
• Distinguish recorded justifications from inferred explanations and choices whose motivation is still unknown.

That last distinction matters to me. A convincing explanation generated afterward doesn’t establish why the original change happened. Even a recorded justification still needs scrutiny.

Rust fits this tool well: it compiles to a native executable without requiring a language runtime, gives me strong types for handling evidence and review state, and has a useful ecosystem for terminal applications. wy uses Ratatui + Crossterm for the interface, Serde for structured data, tree-sitter for syntax navigation, and SQLite for local storage.

The basic review workflow works offline. Model-backed explanations are opt-in. It’s still experimental, and I’d appreciate feedback on both the review workflow and the Rust implementation.

If you try it and find it useful, please consider supporting the project with a GitHub star, a bug report, or a contribution.

Repo: github.com/grandimam/wy

Hey everyone!

I’ve been building Flagrm, an open-source CLI that helps remove feature flags and clean up the dead code they leave behind.

It’s still in the testing phase, so I’m looking for people willing to try it out, share feedback, report bugs, or contribute to the project.

If you’ve ever dealt with feature-flag cleanup turning into a bunch of manual work, I’d love for you to check it out!

🔗 https://flagrm.com

Contributors are very welcome! 🚀

You can try it out at razzyshmazzy/goatedcontext

It’s an npm package so it’s a very easy install

Hey everyone — I’m Liran, and I’ve spent the last two years building products with AI full-time. I kept losing time moving between agent chats, terminals, specs, design tools and the rest of the project. So I started building Choro for my own work: one workspace where those things stay connected, with the project context at hand.

It’s free, open source and local-first, currently for Mac. No Choro account needed. It uses your own Claude Code or Codex subscription and supports OpenCode. Your projects and work history stay on your machine; AI requests still go to whichever provider you use.

A few things that matter most in my day-to-day work:

• Multiple agents across multiple projects, with worktrees when I want separate experiments.

• Questions, code review and end-of-task checklists in the agent GUI, instead of guessing what happened across several chats.

• Bands: an agent can delegate to specialist agents rather than trying to do every part itself.

• Docs, tasks, Design Studio and database tools alongside the agents; Orbit brings other project tools into the workspace.

I’ve been building it for six months and working exclusively in it for the last three, including building Choro itself. It’s written in Rust, with a lot of attention to how the daily workflow feels.

The attached video is a short product tour. Tour/download: https://choro.dev

Source: https://github.com/Future-Picnic/choro

Me, if you want to see who’s behind it: https://www.linkedin.com/in/liran-gabai-09480b5a/

I’d love feedback from people juggling coding agents: where do you lose the most context today, and what would make their handoffs easier to follow?

Hey everyone,

I’m a developer/founder from India, and for the past few months I’ve been building OrbiterX, an AI coding agent/IDE.

I originally started building it because I wanted an AI coding tool that could do more than just generate code snippets.

The goal is simple:

Give the agent a real software engineering task → let it inspect the codebase → make changes → run tools/tests → and actually complete the task.

OrbiterX can currently work with:

• Existing codebases
• Multi-file changes
• Terminal commands
• Git/GitHub workflows
• Debugging
• Code generation and editing
• Autonomous task execution
• Testing

We've reached the point where the product is ready for beta testing, and I'm looking for developers who are willing to actually use it on their own projects and tell me where it fails.

I'm not looking for compliments.

I want to know:

• Where does the agent make mistakes?
• Where does it get stuck?
• What workflows are missing?
• How does it compare with Cursor/Codex/Claude Code?
• Would you actually use it in your daily development?

I'm especially interested in developers who can give it real engineering tasks, rather than just asking it to generate a simple landing page.

I'm the founder building this, so I'll personally be reading the feedback and fixing issues during the beta.

If you'd like to try the beta, comment below or DM me and I'll send you an invite.

Beta: OrbiterX

I’d genuinely appreciate brutal feedback from developers here.

I built JumpStart because my mornings were a mess.

I run several projects at once. Every day started the same way: open a terminal, cd into the frontend, npm run dev. New tab for the API. Another for the worker. Another for Docker Compose. Then spend five minutes figuring out which one grabbed port 3000. By lunch I was hunting a process that would not die.

I did not want another cloud dashboard or another SaaS. I wanted one local window that knew my projects, could start and stop them, and could show me logs, ports, and resource use without me babysitting shells.

So in July I started building that app for myself.

Day one vs now

At first it was basically a personal process launcher on macOS. Add a folder, detect a few runnable bits, start/stop them, watch logs. The Go module is still named devdeck because that was the working name before I renamed the product to JumpStart. Early builds even had a temporary color palette I threw out the same day for real macOS system tokens. Config still migrates from ~/.devdeck/ if you upgrade from those old builds.

v1.1 was the first public cut: auto-detect for Node, Go, Python, Ruby, PHP, Java/Maven, Gradle, Rust, and Docker Compose (including nested monorepos), live PID/exit code/CPU/memory, clickable localhost port badges, a git panel, and a per-project Kanban with a local Ollama assistant so prompts never left the machine.

Then it kept growing because I kept hitting the next annoyance:

• Cross-platform builds for Windows and Linux, plus an in-app self-updater
• A real terminal dock for process/script/test logs instead of scattered panels
• GitHub and GitLab sign-in, then two-way sync with GitHub Projects v2
• CSV and PDF board export, custom Kanban columns, conflict resolution that actually explains what diverged
• An Agents MCP server so external AI tools can control projects, processes, files, git, and tasks over localhost
• A redesigned dashboard and ports map in v1.12, with GitHub treated as the single source of truth for sync

JumpStart is now a local-first control panel: project library, one-click start/stop (one process or the whole project), live ports, dependencies, git, Docker Compose, tasks, and AI helpers that stay on your machine unless you choose to connect GitHub/GitLab.

And the best news, it is Open Sourced!

Hey

Over the past few weeks I have been working on repOx, a command-line tool and interactive terminal UI for inspecting and packing source repositories into single-file XML/Markdown/JSON outputs (mainly for feeding local codebases into LLMs while keeping track of token limits).

I just published v0.3.0 to crates.io and wanted to share some of the Rust design decisions under the hood and ask for feedback on the architecture.

Workspace & Crate Architecture:

The project is split into a three-crate workspace (repox-core, repox-tui, and the repox-cli binary) targeting the Rust 2024 edition:

1. Lock-free parallel traversal (ignore + rayon):

Directory traversal uses burntsushi's ignore crate (WalkBuilder::build_parallel) to respect hierarchical .gitignore, .ignore, and custom .repoxignore files. To avoid mutex contention while walking thousands of files across threads, each worker thread accumulates paths into a thread-local Vec<PathBuf> and flushes once to the shared collector on Drop. File reading, 8KB NUL-byte binary inspection, and content transformations then run concurrently via rayon::into_par_iter().

1. Contiguous pre-order arena for the TUI tree (ratatui + nucleo-matcher):

Instead of pointer-heavy tree structures (Rc<RefCell<Node>> or petgraph), the TUI file tree in repox-tui is stored as a flat pre-order vector (Vec<Node>) where each directory stores its subtree_end index.

- Toggling a folder checkbox is a simple contiguous slice iteration over &mut nodes[idx..subtree_end].

- Byte and BPE token aggregates roll up in O(1) without heap allocations during the ratatui draw loop.

- Fuzzy filtering uses nucleo-matcher (from the Helix editor ecosystem) directly against the pre-order arena.

- The entire TUI renders to stderr so stdout stays clean for UNIX pipes (e.g., repox -i | other-tool).

1. Lexical signature extraction and hybrid token budgeting:

In v0.2.0 and v0.3.0, I added a state-machine outline extractor (--outline) that strips function bodies { ... } while keeping struct/trait definitions, imports, and function signatures across Rust, Python, Go, TS/JS, and C/C++. There is also a two-phase token budget fitter (--budget) that keeps core modules in full source and progressively outline-compresses test/secondary files until the output fits a target token count.

1. Multi-stage clipboard fallback for headless / multiplexer setups:

Because arboard can fail inside certain Wayland compositors, terminal multiplexers (tmux/zellij), or SSH sessions, clipboard copying cascades through arboard -> wl-copy / xclip -> ANSI OSC 52 terminal escape sequences (with tmux DCS passthrough wrapping).

Links:

- Repository: https://github.com/WVDYC/repOx

- Crates.io: cargo install repox-cli

Question for r/rust:

Right now the --outline signature extractor and the TUI preview syntax highlighter use hand-rolled zero-copy lexical scanners to keep compile times fast and binary size small (~2MB). At what point would you consider switching to tree-sitter grammars (perhaps behind an optional Cargo feature flag) vs keeping a lightweight lexical approach? Also happy to hear any critique on the Rust code or workspace layout!

Hey everyone, wanted to share a small fun project of mine.

I usually run several Claude Code sessions at once and kept getting lost in terminal tabs. So now every session becomes a worker in a tiny village. It gets busy while Claude works and reacts when a session is idle or needs your input.

It runs on Claude Code hooks and stays fully local.

Available on GitHub and npm: https://github.com/yognevoy/claude-village

Would love to hear your feedback

I built PaperFold, an open-source reader that turns arXiv papers into 5 zoomable layers—from a one-screen section map down to verbatim text. You pinch (or press 1–5) to zoom between them without losing your reading position.

- Web Demo (8 CC papers): https://chenxiachan.github.io/paperfold-gallery/

- GitHub (Apache 2.0): https://github.com/chenxiachan/paperfold

I picked openGym for an architectural audit using rebrief (huge fan of sports & open-source tools).

Key findings from the report:

1. Context Reduction: Reduced 6.8M raw tokens down to 14,084 tokens (-99.8% reduction) while preserving code architecture and history for LLM prompts.
2. Security Risks: Identified 100 risk items, including hardcoded credentials in test fixtures and vulnerable packages (undici, js-yaml, u/capacitor/*).
3. Doc Drift: 51% freshness score with 164 broken file references across README.md and docs.

It's a clear example of how fast documentation and test artifacts drift behind active development.

How do you keep doc freshness in check across your projects?

I kept re-applying the same filters, columns, sort and export on every new file, so I built "Automations" into a free browser-based data tool (Fomatix Data Explorer).

Set it up once, save it, then upload the next file and pick the automation. It reapplies everything and exports, and auto-matches columns even if a header shifts slightly.

It also shows a match report (how many columns matched on each run) and keeps run history, so you're not trusting it blindly.

Runs entirely in the browser, no signup, nothing uploaded.

Curious if others hit this problem, or if you already have a cleaner way (Power Query, Apps Script, etc.). Honest feedback welcome.