medunes

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.

more insghts please? would be thankful

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.

done, MIT.

Hi and thanks so much for the feedback here

If I got it right, the summary is as such:

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.