I wrote a small CLI tool in Go called Dewdrops to help with "context stuffing" (feeding codebases to Claude/GPT).
The Problem: Copy-pasting files manually is slow, and most existing scripts don't handle .gitignore logic correctly or include binary files that waste tokens.
The Solution:
Dewdrops walks your directory tree, strictly respects your .gitignore rules (using git index logic), skips binaries/images, and outputs a formatted Markdown file.
Key Features:
Tree-First: Prints a tree structure at the top so the LLM understands architecture before reading code.
Go-based: Compiles to a single static binary (no npm/pip deps).
Air-Gap Ready: Runs entirely locally.
It’s open source (MIT). I’d love to hear your feedback on the traversal logic or formatting.
I agree that for fully autonomous agents (or IDE extensions), tool-use/search is the superior architecture. dewdrops is specifically targeting the "Chat UI" workflow, where a developer just wants to drag/drop a feature branch into Claude/GPT/Gemini to ask a quick question without setting up a local RAG pipeline. It's a "dumb tool" for a specific constraint.
it also doesn't touch or generate AGENTS.md. It just respects .gitignore and dumps the raw source.
Like many of you, I struggled with automating Dependency-Track. Using curl was messy, and my dashboard was flooded with hundreds of "Active" versions from old CI builds, destroying my metrics.
I built a small CLI tool (Go) to solve this. It handles the full lifecycle in one command:
Uploads the SBOM.
Tags the new version as Latest.
Auto-archives old versions (sets active: false) so only the deployed version counts toward risk scores.
It’s open source and works as a single binary (or Docker image). Hope it saves you some bash-scripting headaches!
1- License: I'll add soon, forgot about it (literally)
2- Where is the solution: I hope you all read the contributing guide, I clearly mentioned solutions are not the MAIN point for this repository, it is rather giving problems which are intended to *guide* me/you through hands-on practical constraints on how to face those "go" weird scenarios. I also clearly stated I'm not that much top notch Go dev to provide you with solutions for now
3- No, this is neither chatgpt, nor claude code generated repo.
4- I'm till waiting until someone with enough experience that worked on these problems in real life can either suggest solutions or provide support
5- The project is a hands-on documentation, maybe on-going process. IMHO is better (for me at least) than a youtube video that I forgot about the next day. Struggling into the problem and implementing an okkeyish solution would force me ask and search for the foundational knowledge behind it, read books *with this goal in mind*, what videos *with that intention*, and so on. I'm very hands-on learning person.
6- Would be very nice to have these questions here in form of Github issues as well, then maybe seasoned devs can support both me and you better
7- I haven't expected it to escalate to ~ 1.7k stars in two weeks, with not much effort, and this is IMHO a proof many devs struggle with that exact gap I'm trying to tackle
I’ve been transitioning to Go after years in other ecosystems, and kept running into the same problem:
I could write correct Go code, but not idiomatic Go.
Most material focuses on syntax or algorithms. In practice, what caused friction were production mismatches: context cancellation and goroutine leaks, errgroup vs WaitGroup tradeoffs, HTTP client hygiene, error wrapping semantics, allocation control, embed/io/fs for dev–prod parity, etc.
I started collecting small, constraint-driven katas that isolate one such mismatch at a time. Each kata defines explicit pass/fail idiomatic constraints, rather than providing solutions. The goal is deliberate practice, not “best practices” or tutorials.
This repo is curated by someone transitioning to Go, for others doing the same. It’s not meant to be authoritative. If you’re experienced with Go and spot incorrect, unsafe, or misleading constraints, issues and PRs with rationale and references are explicitly encouraged.
I’m especially interested in feedback from people using Go in production on where these constraints are wrong, incomplete, or missing important edge cases.
I've just created #PHP Noise!, a starter-kit for your [opensource] PHP projects. It includes frequently needed boilerplate setups (badges, tests, #phpstan, #sonarqube, #psalm, #phpunit, #travisCi readme, license, contribution, logo etc..)
The Problem: Copy-pasting files manually is slow, and most existing scripts don't handle .gitignore logic correctly or include binary files that waste tokens.
The Solution: Dewdrops walks your directory tree, strictly respects your .gitignore rules (using git index logic), skips binaries/images, and outputs a formatted Markdown file.
Key Features:
Tree-First: Prints a tree structure at the top so the LLM understands architecture before reading code.
Go-based: Compiles to a single static binary (no npm/pip deps).
Air-Gap Ready: Runs entirely locally.
It’s open source (MIT). I’d love to hear your feedback on the traversal logic or formatting.