Experimenting with PocketFlow and Gemini CLI

https://github.com/The-Pocket/PocketFlow

I came across an interesting framework called PocketFlow for building flows or graphs that play well with LLMs. The design pattern is quite generic though, so there is no need to use LLMs with it.

https://github.com/argenkiwi/pocketflow-m3u-downloader

I actually wanted to improve a script I had so it could perform downloads in parallel. This morning I fired up Gemini CLI inside a fresh clone of the PocketFlow repository and within a couple of hours I got it running. I was hoping Gemini CLI would be able to do more by having access to the framework's code and examples, but I had to nudge it in the right direction quite a few times. In any case, I think I can keep building on top of this and make myself a library of nodes and flows I can use to automate some of my everydays tasks. I hope someone else in the true Geminiverse finds this interesting.

Posted in: s/AI

🗿 argenkiwi

2025-07-15 · 10 months ago

1 Comment

🛞 MaAkThRsYoOySrHtKaAm · Nov 24 at 16:16:

It looks interesting. Thanks for sharing.

The best results I have had with this kind of thing is when I provide any code/documentation/examples available and first direct an LLM to write its own documentation for the use case. Having it write the overall implementation strategy is also helpful. The nice thing about this is you can break larger documentation down into chunks of relevant info that can be digested later when it is directed to execute whatever you intend to build. I do this all in a local git project so I can commit and roll back as needed.

I pretty much break it into two sessions:

Session I

Parse the source and write concise documentation and strategy.

Session II

Execute and record what was done, what to do next.

The time spent on preparation in the first session has proven to be well worth it in reducing the instances of having to go back and tell it what it's doing wrong or going on a wild goose chase in the completely wrong direction because it wants to fall back to its own training and assumes some old documentation is correct. All you're really doing here is spending the time to refine your prompts to be as clear and concise as possible to provide all necessary info as efficiently as can be so more tokens can be put toward the actual task.

I believe Claude and GPT are now offering some persistent memory across chats, but I haven't relied on that because I direct it to record a file which describes what was done in the current session and what should be done in the subsequent session. Between this and having custom documentation it does well to serve as some sort of transitory if not persistent memory.

Now everything I have described above is without using something like Pocket Flow. Which looks like it aims to address just what you are expecting it to.

My personal journey with frameworks like LangChain taught me that the more complex the framework, the harder it is for AI to help. Pocket Flow was born from this realization — designed specifically to create the perfect division of labor between human designers and AI implementers.

— Agentic Coding: Let Agents Build Agents for you!

I haven't used the projects feature on either of these but they recommend for brainstorming and prototyping:

Create a ChatGPT Project or a Claude Project, and upload the docs for reference.

— https://github.com/The-Pocket/PocketFlow/tree/main/docs

It looks like Gemini is currently working on implementing their own version of the "projects" feature.

Why use a project?

From what I gather, this is a way of keeping separate but related chats under one umbrella as a sort of persistent memory. It may be useful. Some level of persistent memory is a must for working within a large framework. Then there are times when things go off the rails and starting fresh with a new chat is only way to get back on track.

They seem to really lean into uploading files to a "project".

— For One-time Tasks: Brainstorm and Prototype

If you don't have access to a "projects" feature yet then the next best thing may be doing as I described above. Just make a directory with the sources for code and documentation, direct it to find what you specifically need for your use case, tell it to write its own documentation and strategy to develop what you need.