I think there are umbrella issues as well as better scoped issues. I didn’t forget about the format. That’s just the point though: if they’re not

ready-for-dev

people shouldn’t, normally, start implementing them, otherwise they risk their PR becoming obsolete or exposed to changes.

pass the

ready-for-dev

check when opened

When opened? Is this intended, @limited-student-10747 ? Why?

Sorry, I thought the recent issues you opened were automated, if not my bad. I just noticed that there were many opened and they were not yet well specified. Ideally we can work thorough and specify them before opening but I don't think it's a hard requirement

Yes, they were from prompts. 🤔 But I think this is an interesting situation and worth discussing, because I’d like to clarify: these are not “bugs” in normal sense, or that wasn’t my intention - though the agent seems to have found some actual bugs too. My intention is to audit code design across the main repos. I’m trying prompts like “_find materially useful simplifications in its data structures, state representation, control flow, algorithms, and ownership_”, across the codebase(s). I expect some issues are invalid: the LLM might exaggerate, it might suggest directions that aren’t good. I welcome help as anywhere else; but I wouldn’t recommend to interested contributors to just point their agent at it and expect a PR. Not sure about that... It’s more like brainstorming. They’re not validated yet, and they’re not intended as “bugs” or “features”. ——— To take a step back… My point is that I believe we need to refactor, simplify, or straighten out the control/data flows that got too much complexity or may have become messy. Because the LLM loves unnecessary complexity, but then, the next runs on unnecessary complexity are prone to do the same or worse. So that’s what I’m doing. 😅 I expect that some of this work is refactoring, some is workflows/automations to constrain the agent, some is prompts/skills tweaks to nudge it. (and, apparently, some is actual bugs uncovered when focusing its attention on code design) Once this is done, I’d hope the results will be: • agents will be able to write better implementations on regular bugs/features • we have clearer code design, clearer division of responsibilities between modules/classes/components • better guardrails for future runs (this is actually my main desire) • maybe we will know better what can be automated even from this kind of work 🤔 Back to this question… What if we had a label saying

not-validated

?

Thanks, I think these are good points. One thing I kinda felt from this discussion is maybe we should have a place other than issues for things that are mostly brainstorming. At the company we use Notion for this, but we don’t have a public one. Github discussions might be a good place but i’m a little worried that they might become spammy? I’ll think a little bit about it. And my goal is that “ready-for-dev” means “validated” in some sense, and absence of ready-for-dev means “not validated”. I totally think it’s OK to have lots of not ready-for-dev ones, but I guess the reason I got caught up on your issues is because they were a bit higher-level and it was hard to come up with a good definition of done

Right, that’s exactly why maybe they shouldn’t be ready-for-dev since, well, they are not validated yet

SG. Maybe we could also post them as gists at first, and then once they’re well-enough formed to be implementable issues we could create issues?

I would actually like to propose that more of us try ways to make design intelligible to other humans, and come up with a more standard documentation of a PR than, well, LLM walls of text 😅

I’d be interested in that. I’m struggling with gpt-5.6-sol, which is an extremely smart model but very bad at explaining things

Just for fun, I see people use this lately: “_what the hell do you mean? Use ASD-STE100 Simplified Technical English (STE)_” 😅 But yes, I think maybe a minimal thing could be like: before/after design doc for non-trivial PRs. Sometimes, GitHub asks open source maintainers for feedback, and I’ve been suggesting to incorporate a visualization of the changes in the data flow 🤔