Prompted by human, generated by AI

i want to teach all agents that when reading something from github, the agent can use gh cli instead of web fetching or web searching tools, because with gh cli its much more efficient and robust

why did you make these mistakes? It leads me to believe that you are still not an expert in using this cli tool

can you add these distilled information to the context file so that these mistakes dont happen again? Mistakes like these cause the agents to hallucinate and costs me time and energy, do you understand that?

okay now you are being too defensive, these never rules are you trying to play it safe and makes the tool useless afterall, isn't github declarative and strongly typed? why don't we know the exact json fields from the get go? can't you explore and find evidences and much better answers for all these issues you created these overly cautious never rules for

how come gh cli is not better than that, thats beyond my understanding, can you look things up on github itself, i bet someone maybe came up with a better alternative than gh cli for this kinda limitations? I want to enable agents to be much much better in research/exploration, how can we achieve that?

i know that github has an mcp, but i dont wanna install entire mcp, it will bloat every agent's context memory, but does it solve all these problems? Maybe we can build a quick cli script which allows the agent to be much much more efficient overall, using github api or something novel overall. The goal is that we need to equip the researcher agent with the most efficient tooling for exploring and capturing distilled information

okay how come someone didn't build this so far? I bet on github someone built the github researching claude skill or cli exactly like this, and they built much more battle tested and even better cli tool, continue exploration and capture the novel ideas distilled, capture best practices, gotchas and anti-patterns distilled

I still dont get the usefulness of Gitingest — but i feel like there is some kinda gold burried in there, so can you dive deeper and extract inspiration. i feel like this ghx already transcended to be a fun little quick script to be something majestic, like how come this doesn't exist already? Thats beyond my understanding.

so is any of these a direct competitor to ghx? like does repomix invalidate ghx entirely? but i want you to double down with evidences on your answers, dont change your answers prematurely. ghx is not an instruction set no more, it is an open source project that will potentially transcend us.

we are at the point where i want to make this an open source tool, what do you think?

i feel like we will forget the agent in few months, whats the next term that we are about to adopt, i still haven't made up my mind, but i feel like agents or agent is not a good enough name to represent whats going on in 2026

ggcode? you like it? but why ggcode explore? Isn't the whole idea of ggcode to be an exploration tool itself? or are you proposing ggcode to have more capabilities than just exploration?

wait think big, what if i build more than gh exploration then what? should i publish new tools? What if all someone wants is github exploration? im kinda torn in between now

it should be ideally installable as npx cli tool, as gh extension and as a regular shell script in my opinion... So the name should be such that its consistent all over these places and doesn't conflict with other existing tools

Ideally i want one source of truth code for any of these npm, bash, gh extension, brew any of these to have one source of truth code

lmao: npm error 403 Forbidden - Package name too similar to existing package gg-code

lmao npm error 403 403 Forbidden - Package name too similar to existing packages gts,tsc,grpc

overall lets just find a name im tired, i dont wanna worry about the name at all u have full freedom

thats diabolical, if im doing @gkoreli -> then might as well pick a proper name whatever i want

lets do @gkoreli/ghx

gh search code is really bad i just tried gh search code "ghx gkoreli" and it gave me empty results then i tried "ghx" and it gave me so much useless results

lets iterate and address the issues and see first where are the gh issues and how/why ghx addresses them. on a literal github web application this search query gives me one result, our repo, but gh search code is empty, why is that?

look at this — why is their search still better than us? Are you sure about these claims? Go explore and find evidences.

i want adr 3 to be the expert of the github's search api and iterate so much and understand so much details that we overall build much much better tool that github itself, proceed...

the pattern is consistent across all ghx commands: batch what agents actually need into one call with smart defaults, instead of making them assemble it from multiple calls with explicit flags. And overall what is ghx, the smart default for agentic first github exploration, like you trust ghx to provide meaningful enough context to the agent in least amount of steps, so that you stop worrying about the fact that: was i able to not find something because i didn't use the search tools properly or something genuinely doesn't exist, and you just pass this responsibility to ghx

whats the most no-brainer for agentic first approach, smart defaults, intuitive cli commands and flags and so on? Step back and think big vision

i feel like we are hitting the ceiling of shellscript based implementation, what do you think

why is codemode not available via cli? Cli should still be source of truth correct? anything available via cli is then available via mcp. Actually core must be the source of truth correct?

i want to write an article about the "ghx" cli tool that i created personally, it started with a pain that i was facing over and over, then i wrote a skill, iterated over a skill, then wrote a quick shell script, then iterated over a shell script, open sourced it, and eventually now its a proper open source cli tool that doesn't have a proper precedent at all, and this is how proper agentic first tools are built. Morale of the story is that simple tools like this require so much iteration and lots of thought process goes into it, its not like when some people think that using AI is so easy and straightforward, just tell the agent: "build github exploration tool, no mistakes", and voilla ai agent just spits out a perfect tool within few minutes. Thats what majority of the people think AI works, but this is the reality, entire lifecycle, with the mental model and thought process and everything.

lmao i dont think you read all the story, and this needs to be a personal article not just technical specifications breakdown of ghx cli tool lmao, there needs to be a proper story with conflict and the all of that

i dont like the title at all - its too verbose and too technical

build the github exploration tool no mistakes (this became the title)

i feel like some parts are hard to follow and comprehend and distilled bullets would benefit

i feel like it should start with the pain/frustration right away

where is the lessons, takeaways, corrections for these people to course correct

some of these glossary items seem forced, like are they really needed to be here?

another takeaway: Do not over engineer, start small, start with an instructions file, then move on to a distilled skill, if you still see agent making lots of mistakes write a shell script, then write a cli tool, and only then write the mcp tool, open source it, build into a proper product. And to keep things open ended, i want to write about the codemode and i might even build a proper library out of it, and again all of this will be born from the pain, i am not building it just to build