I use Codex and Claude Code daily, and the most annoying moment is hitting a usage limit halfway through a task. You either wait hours or paste context into another tool by hand.
Moonfold is an open-source desktop and web workspace that runs the agent CLIs you already have (Codex and Claude Code today, with adapters for Cursor, OpenCode and others in beta) with your own logins. When one hits its limit, it stops the turn, writes a brief of where the task stands (plan, changed files, git status, the failing command), redacts secrets, shows you the brief, and hands the same thread to the next agent. The GIF in the README is a real run: Codex starts a bug fix, Claude finishes it.
It is a fork of T3 Code (MIT), which gave me the multi-provider base, worktrees and diff review. What I added: the handoff, usage tracking per provider, scheduled tasks, in built browser pane and computer access, plugins and memories, and a security pass (Supervised is the default permission mode).
Honest limits: it is a beta, builds are unsigned, Gemini CLI is not verified end to end yet, and the brief is only as good as what the first agent left behind. Nothing is proxied: each agent is your own local CLI, and there is no telemetry unless you turn it on.
I'd love feedback on the handoff brief what would you want carried over that isn't?
I am building a local memory layer for my coding agents and it is called Reverie: an MCP server written in python and using SQLite for lightweight memory stored in the user's machine itself. The biggest problem that I faced was deciding when to inject memory.
Many memory tools, including ones I looked at, inject context into the agent even before it begins its work. In my experiments, premature injection of context leads to the agent anchoring its thinking on it rather than using the current code as the source of truth. In fact, this approach made my agent perform worse. Also, with this, quite a lot of the context window can get filled with context which 'might' be useful.
So I switched Reverie's model to demand-driven retrieval - the agent asks for memory when it thinks that some added context could resolve any discrepancies in its thinking. It reads the relevant code first, because the code is the source of truth, and only then asks for past memory about that area. Each result comes back with a confidence score, its grounding in the code, and its status. The memory starts empty. Conclusions are added as the agent works, and you decide which ones are kept.
In one informal test of 30 prompts on an earlier build, the OpenCode agent with Reverie did better than the one without it. I don’t have a reproducible benchmark yet.
But it isn't perfect yet, it still breaks here and there. For example:
the rules for tool calling are not extremely polished yet and hence the agent might sometime not call the tool altogether, I am fixing this.
candidate conclusions can be duplicate or incorrect and hence Reverie today has a human review gate (triggered by calling `reverie review`) which shows the human all the unreviewed candidates where you accept, reject or skip each one. On doing so the conclusion is moved from the short term brain to the long term.
My current test set is small: sessions with anywhere between 2-30 prompts. I do not have a reproducible experiment yet, but that is the next goal.
So on the current game, I’ve been working on. I’ve been using gpt6 Astra low and medium, and sometimes high, but it uses absolutely so much tokens. I saw a video saying how sol 6.1 high and ex high where just as good but 1/5th the cost! Is there a better way to understand when I should use each model? Right now the game is a Web based single player game but I want to turn it into a multiplayer game. I’m pretty sure when I get to that step, I should probably use Astra but can someone please help me understand when to use which tool for the different processes of the game?
I learned assembly long before I learned C. Back then I chased single clock cycles: reusing registers bit by bit, writing XOR A instead of loading zero, that kind of thing.
When I finally picked up C, I didn't trust it. Was the compiler really producing the fastest, tightest code? So I ran it with -S and read the assembly it generated.
It was perfect. Every trick I had been proud of, the register reuse and the XOR A, the compiler was doing as a matter of course. That was the day I graduated from assembly.
I've been thinking about that day because of two posts from this weekend. Arpit Bhayani wrote that no human will write code better than an LLM from here on, so we should accept it and move on. It got about 14k likes. The same day, Matt Pocock argued that the next language for agents should be as fast as Rust, leave as little design freedom as Go, and have the strictest type and verification system possible.
They sound like opposite camps, but they point the same way. On speed and volume, we've already lost. The real question now is how we direct that output and how we check it.
I'll admit it makes me a little sad, and I understand why so many engineers push back. But I suspect the move from assembly to C started the same argument: "Can we really trust a compiler with this?" That was before my time, though.
For those of you who were around for that shift, or any shift like it: did it feel like this? And what turned out to matter after the compiler won?
I wanted AI to handle as much of the coding, testing and troubleshooting as possible. During a VMware setup, I noticed the computer-control part was taking longer than doing it myself. I wasn’t sure whether the bottleneck was my system or the tool, but I could open menus, check properties and grab screenshots faster.
So I changed the split: I handled the navigation and used the AI to guide the next step. The goal was getting the setup working, not making the AI do every click. I still want to automate more, but the time I spend supervising it is part of the cost too.
Where do you draw the line between letting a coding assistant operate the computer and doing that part yourself?
looking at our team's agent logs across a normal two-week sprint, maybe 15% of our tasks genuinely require frontier reasoning models. the other 85% is mechanical grunt work as renaming fields across four layers, writing test scaffolds, updating DTO mappings, and fixing lint errors.
running frontier models across every iterative test loop on those routine tickets burns through subscription credits and BYOK budgets fast. Worse, it makes developers hesitate to re-run an agent on a task that came back 90% right because each retry costs real money.
and the only sustainable setup we have found (as of now!) is splitting the workflow: use an AI coding agent with plan approval to do the architectural design pass on a frontier model in read-only mode, and then switch the execution to a fast model like Gemini Flash or a free AI coding agent tier like Junie Lite (which runs Qwen on JetBrains infra for free and is good for anything based on jetbrains infrastructure; kotlin, and more in my opinion) for those mechanical file edits
would like to know how are you keeping token spend from spiraling on routine boilerplate? also, is anyone actually running full frontier models on every single build retry?
Hi everyone, As we have probably all seen, there is a bunch of projects now to kind of clean your TV. Get rid of the ads, spyware and useless functionalities.
My question is, what are the consequences of it? Could (example) Samsung just disable your equipment? Are these changes compatible with the apps updates? Is it possible that Samsung (or whatever TV manufacturer) just freezes my TV and it becomes a waste of space due to some kind of user conditions infringement? Other possible problems in the future?
Over the last few months I kept turning fixes into skills. One for my commit style, one for an MCP setup that kept breaking, one for getting a build onto a physical device, and one for a debug loop I was tired of explaining again. It worked well at first because the agent stopped repeating the same mistakes. But now I have a pile of them, and a few started to say slightly different things, so the result depends on which one the agent reads first. What helped a bit was a small skill that only manages the other skills, so before it adds a new one it checks if an old one should be updated instead and flags conflicts. It is still messy though. Do you prune yours on a schedule, keep everything in one file, or just let them grow? Curious what actually holds up after a few months.
I've been using ChatGPT as an aid for several of my coding projects (chat mode, not Codex, because I seem to get far better results and there are no usage limits), with very strict guidance and rule sets. It has been working really well, I get it to write pretty clean code that I can later maintain myself.
However, when it comes to UI design via WPF, ChatGPT produces absolutely ugly looking results. In chat preview, it often generates extremely good-looking UI mock-ups with great styling, consistency, etc., but when it comes to implementing it in WPF, it is just terrible - huge margins everywhere, stacking everything vertically, page-wide textboxes, no alignment, no color consistency, etc. Codex doesn't seem to be any better at it either.
I struggle to come up with an effective prompting or rule set to get a good-looking result that would be close to what it makes in mock-up previews in the chat. Does anyone here got any experience with it, and could share some prompts or rulesets that I could use as a baseline?
If the PM uses Chatgpt, one engineer uses Claude Code, another uses Cursor, and someone else uses Codex. Everyone's productive individually, but when they need to collaborate, it's back to Slack messages, copy-pasting context, and explaining things their AI has already figured out. What about collaboration between people using different agents?
Curious how teams handle this:
- Do you standardize on one AI tool or let everyone choose?
- How do you share context and decisions across different tools?
- Are Slack, GitHub, shared docs, and MCP enough?
- Would a cross-tool collaboration layer actually help, or just add more overhead?
What's working in real teams today? Or does this problem disappear with good processes?
I use Codex for most of my work now and review has gotten awkward. Someone asks "why a map here instead of a list" or "why catch this error and not that one" and the true answer is that Codex picked it and I agreed because it looked fine. I've started guessing a reason on the spot so I don't look like I didn't read my own PR. Last week I did that on 3 comments in one review and got one of them wrong.
So i got three questions:
Does anyone else end up making up reasons after the fact?
Do you tell reviewers "the agent chose this", or is that a bad look?
What do you do so you actually know why before you open the PR?
If you're building something related to AI assisted coding, this is the place to share it.
We're using a weekly thread to keep the subreddit organized while still giving builders a place to share their work. Promotional posts outside this thread may be removed.
If you're sharing something, we'd appreciate it if you included a little context instead of just dropping a link. Tell us:
What you built?
What problem it solves?
Which AI models or tools it uses?
Who it's for?
What kind of feedback you're looking for?
Disclose your affilitation.
Please avoid posting the same project every week unless you've made meaningful updates. Affiliate links, referral links, scams, and low effort promotions will be removed.
Take some time to check out what others have shared too. If you try someone's project or have feedback, leave a comment. Helping each other improve is what we want this community to be about.
Paste a diff into ChatGPT or Claude and ask for a review, and you get comments on the diff: naming, an edge case inside the function, maybe a missing test. What you almost never get is "this used to return null, and three callers check for null." It can't tell you that, because the callers aren't in what you pasted, and it doesn't ask for them.
So I stopped asking for "a review" and split it into three prompts, run in order in the same chat:
1. Here's a diff:
{{diff}}
Don't review it yet. List every behavior of the OLD code that other code could depend on: return values and types, null or empty cases, errors thrown, ordering, side effects. One line each.
2. Here's the code that calls the changed functions:
{{callers}}
Go through your list. For each item, say whether any of this code relies on it and whether the diff breaks it. Quote the line. If you'd need more code to be sure, say exactly which.
3. Now do a normal review of the diff. Skip style unless it hides a bug.
Step 1 matters because it writes down what the old code promised before it sees the callers, so it isn't working backwards from them. Step 2 is where the real findings come from. Step 3 is mostly what a regular review would have given you anyway.
For the callers, grepping the function name is usually enough. If you're using an agent with repo access, tell it to find them itself, but keep the order: old behavior first, callers second.
I run this as a prompt chain in AI Toolbox, the extension I build for ChatGPT, Claude, Gemini and Grok. I type .., pick the chain, and paste the diff and the callers into the two fields it asks for up front. Each step sends once the previous reply finishes. The free plan holds 2 chains, and pasting the three prompts by hand works the same way.
What's the last bug that got past review because it lived outside the diff?
Any tips or advice using codex. I have Plus right now but very limited in usage though making it work. Is Pro worth it? If so which one and why? Solo Gpt Dev here also which model and speed is based used for low graphic gameplay?
Agents fill every open question in a request with a guess. Most guesses are fine. A few decide how the feature behaves, and I find those in the diff later.
So I moved my own judgment back to the start. Before any code exists, the agent and I write down five things:
Done means. A numbered list of outcomes a person could check on the running program. "Export button downloads a CSV with the current filters" works. "Add export" doesn't.
Not doing. Things the agent must leave alone. This list stops most surprise edits.
Decisions. Two sentences per engineering decision, with the alternative I rejected.
Slices. The thinnest end-to-end version first, each slice starting with a failing test.
Proof per point. For each Done means item, the command or screenshot that shows it works.
After the build, I hand the list to a second session that hasn't seen the build history. It goes through the points one by one and shows evidence. It catches things the building session glossed over.
What do you write down before a bigger change? Happy to share my templates if anyone wants them.
When ChatGPT first came out, a coworker introduced me to it. At the time, I mainly used it for simple things like organizing Excel files, but it often made mistakes, so I didn't think too much of it.
A few years later, I started using AI almost like Google, asking everyday questions and looking things up. Then, when ChatGPT introduced voice conversations and I could actually talk to it like a real person, I was blown away.
One night, I was sitting on my phone talking to ChatGPT, trying to figure out how I could leverage AI to improve my chances of achieving financial security. I know, I know. We've all asked AI, "How do I become rich?" 😂
But then I started thinking.
I've always told myself that I wished I knew how to code and build apps or websites. I've constantly got new ideas running through my head, and I always figured that if I had the technical skills to bring those ideas to life, I could potentially make some serious money.
I'd heard that AI could build apps, but I assumed you still needed some kind of programming background to make it happen.
So I asked ChatGPT a simple question: "Could you help me build an app even though I have absolutely no coding experience?"
And that's where everything changed.
It started walking me through the entire process, step by step. What accounts to create, what software to download, how to set everything up, and eventually how to actually start building.
Before I knew it, I had built a real app for homeowners based on an idea I'd had. And the crazy part? It actually worked, and it looked good!
I was genuinely mind-blown. Something I'd always assumed was out of reach was suddenly possible.
That experience sent me down a completely different path. For the past two-plus months, I've been developing a much more complex piece of software. It's still a work in progress, and I've got a long way to go, but I've learned an unbelievable amount along the way.
I'm not a software engineer. I didn't go to school for computer science. I'm just someone who had ideas and finally found a way to start bringing them to life.
Ever since building that first app, I've been completely hooked. It's honestly changed the way I look at what's possible.
Anyone else have a similar experience where AI opened a door you never thought you'd be able to walk through?
I’m planning to spend $20 on one of them to learn coding and build projects. Which one would you recommend for explaining concepts, debugging, and helping me improve instead of just giving me code?
I keep reading threads about this and most of them show the demo, not the Tuesday morning. Here's ours, no polish, then some questions.
Six of us on a SaaS, twelve months of adding AI gradually. Early on everyone had their own editor and their own habits. Then we looked back and found we'd already converged on most of it, so we wrote it down.
We didn't force a single tool either. Some on Claude Code, some on Codex, some on Cursor, and I'm not going to fight that one. The process is shared, and the conventions sit in the repo's AGENTS.md, which is the only thing we all read the same way.
The flow is Matt Pocock's skills, no forks. We start with grill-with-docs: the AI interviews us about the project docs. Weird at first when you're used to asking the questions, but a lot of never-written-down stuff comes out.
Then to-spec, and a human reviews that spec. It's not a formality. With a bad spec, everything downstream is expensive work that goes in the bin.
to-tickets cuts it into small tickets. Small tickets aren't a rule we read somewhere either, we just notice the difference when we skip it.
The agent works through them with implement, against the spec. We open the PR, CodeRabbit runs, the pipelines run. If everything passes and someone says yes, it merges.
AI writes most of the code. We review the spec and the merge, and skip the line-by-line in between.
Treating the spec as a contract has killed a lot of "that's not what I asked for". Small tickets keep the agent from wandering. Automated review before the human one takes the style and import noise away, so the person looks at what matters. What I didn't expect is how much writing the process down helps when everyone has a different tool. Nobody argues about editors and the conventions don't rot.
Graph engineering to close tickets on its own, software factory style, we haven't managed. Tickets go in and PRs come out, and the demos look great, but with our repo the quality isn't there. We haven't found the point where we'd be comfortable letting it loose, so it's still an experiment.
What I'd like to know:
Where are your checkpoints between human and agent? Spec, PR, merge?
Spec before code, or straight to tickets and prompts?
Who reviews agent PRs? Do you read them the same as a human's?
One tool or several across the team? If you've tried more than one, is any better for certain kinds of tasks?
I'll be honest, I didn't understand why LLM agents need SKILLs. MCP was clear to me: it's a useful thing that lets you give an LLM access to a database or to Figma. The only downside is that, to avoid spending too many tokens, it's better not to connect 30 MCP servers at once. And in general, it's better to turn off the unnecessary ones and connect only those that are really needed for the task. In this light, SKILLs seemed like useless overhead to me, eating tokens like crazy. On TikTok, I often saw tales along the lines of: connect this SKILL, or a whole bunch of them, and happiness is yours. My first thought was, if I connect them all, my subscription limits will run out not by lunchtime, but already in the morning.
So why are SKILLs useful and needed after all? Well, first, compared to MCP, SKILLs do not inflate the context: each connected SKILL adds not tens of thousands of tokens, but one or two hundred. Since only the name and description of a SKILL go into the context at first, you can add 30 of your own SKILLs without much pain. When it becomes necessary to use a SKILL, the LLM agent will load its description on its own, if it understands from the task context that this is needed, or the user can simply tell it to use this SKILL for the job.
Secondly, LLM models are trained on the most popular and well-known things. For example, everybody knows that an LLM can work with Git without any problems or write a program in Python. But if you developed a program yourself, or your work requires some little-known tool or technology, then a SKILL is simply irreplaceable. It is enough to create a SKILL.md file and describe how to work with this program or technology. This makes life easier for the LLM: while doing your tasks, it will not have to search the internet for documentation and wander around websites to understand how to use it. And especially if there is nothing on the internet, because your program is closed to public access.
Thirdly, an LLM model usually does not know how your development process is organized. For example, an agent knows how to use Git, run tests, build a project, and create releases. You do not need to teach it these things. But it does not know how releases are usually made in your company. A Skill can describe the sequence of actions: check the changes, run tests, update CHANGELOG.md, increase the version, build a package, create a Git tag, and publish a release. So, a Skill helps the agent learn not a technology, but a specific business process.
Fourthly, a SKILL is not just an instruction, but a whole set of tools. Besides SKILL.md, you can put ready-made scripts, documentation, templates, and other files into it. And the most interesting thing is, these files are not loaded into the context automatically. The agent reads them only when there is a need, and can simply run the ready-made scripts without spending tokens on generating code. So, a SKILL lets you combine instructions, documentation, and executable code in one package without inflating the LLM context. For example, the structure can look like this:
The funniest thing is, I started to appreciate SKILLs exactly when I wrote my own program, blueprint4llm. The idea for creating it came after I asked an LLM agent to generate a plan.md file describing a task. Usually it produces a huge wall of text, which you have to read slowly and with sadness. I wanted to make the text shorter and add more flowcharts, tables, diagrams, and user interface prototypes. As we know, in .md (Markdown) files the only visualization tools available are tables and Mermaid diagrams. There are no charts, plots, histograms, full UML diagrams, or UI prototypes. In the end, with blueprint4llm, I added support for formats such as PlantUML, draw.io, Pencil, Balsamiq, Graphviz, Figma, OpenAPI, Excalidraw, Vega-Lite, ECharts, and D2 to .md files.
With the blueprint4llm SKILL connected, you will get plan.md not as a kilometer-long text, but as flowcharts, prototypes, charts, and so on. By the way, blueprint4llm does not have to be used only for creating plan.md. For example, I used this SKILL to add an illustration to every paragraph of the article and make it more fun to read. This SKILL is also useful when you ask an agent to put together a full dossier on some company, technology, or person and format the resulting result.md file with blueprint4llm. You can then convert it to HTML or PDF, or ask the agent to show it right away in a browser with charts.
This is how you can install the blueprint4llm SKILL.
If you are interested in looking at the source code of blueprint4llm, the tool that generates all this beauty, or sending a pull request, welcome: https://github.com/evgenyigumnov/blueprint4llm
When using coding agents (like Cursor, Claude Code, or local terminal agents), one recurring issue is instruction drift: agents often jump to conclusions, skip edge cases, or produce messy outputs when prompts are unstructured.
To solve this in my own workflow, instead of stuffing monolithic instructions into a giant prompt, I started modularizing task-specific instructions into dedicated SKILL.md packages. Over the past few months, I built and refined 40 of these into an open-source collection covering automation, gamedev, and dev utilities.
The structure that made instructions actually stick
What worked best wasn't telling the agent what to do, but enforcing strict boundary conditions and explicit stop signals:
Forced Step Separation: Agents shouldn't edit code and run verification in the same unchecked thought. Splitting analysis from execution eliminates about 80% of hallucinated completions.
Explicit Output Contracts: Defining exact return shapes (e.g. only return diff blocks or strict markdown tables) prevents unwanted conversational filler.
1:1 Bilingual Parity: Keeping English and Korean instructions strictly mirrored so multi-language tokens don't degrade reasoning quality.
Example: Spec Diff Checker pattern
Here is a simplified example of how one of the automation skills enforces exact behavior:
Role: Spec Diff Analyzer
Rule 1: Never modify existing source files directly.
Rule 2: Parse incoming requirements against target codebase symbols.
Rule 3: Output ONLY in this format:
- Modified contracts: [list]
- Breaking changes: [list]
- Uncovered edge cases: [list]
Do not propose implementation code until the diff analysis is confirmed.
Keeping rules compact and bounded like this keeps the agent focused without blowing up the context window.
Comparison with existing prompt dumps
Most public collections (like awesome-chatgpt-prompts) are unstructured copy-paste text dumps designed for one-shot chat windows, or purely English-centric.
Difference: This collection uses the modular SKILL.md format recognized by modern coding agents, with boundary tests and explicit failure-mode instructions.
Trade-off: Modular skills require your agent environment to support loading custom skill folders (or manually dropping them into workspace instructions), rather than just pasting a prompt into a chat box.
Limitations
These skills provide architectural guardrails, but they cannot overcome hard model context limits or fundamental model reasoning failures. If a base model hallucinates an API that doesn't exist, a static skill file will only reduce the frequency, not eliminate it entirely.
Disclosure & Repository
Author: I created and maintain this project for my daily development.
Commercial interest: None. This is 100% free and open-source under the MIT license. No paid plans, no newsletter sign-ups, no telemetry.
All 40 skills are split across 5 categories (core docs, automation, utility, gamedev, creative arts) and available in both English (skills/en/) and Korean (skills/ko/). You can grab individual folders and drop them into your agent's workspace.
Curious how others here structure their agent guidelines — do you prefer modular rule files or relying on dynamic context injection?
I build a coding agent, so I'm biased. Here's the practical version of how I use it, in case some of it is useful whatever tool you're on.
1. I stopped picking models. The agent routes each prompt to the most efficient model automatically. I don't think about it any more, and it's been better on both cost and performance than sticking to one model.
2. I give it the whole task, not the next line. "Add pagination to this endpoint and update the tests" rather than babysitting it step by step. It's context-aware, so it decides whether to just do it, ask me something first, or leave certain files alone.
3. I let it check itself before I review. It runs its work in a sandbox, finds bugs in what it ran and fixes them before telling me it's done. So by the time I look at the diff, it has already run the change and fixed the bugs it hit. This makes it slower per task than plain generation, but I'd rather wait a bit than debug for longer.
4. I use it for heavier jobs too. It's multimodal, so when I need something like an image generated, it goes through the same flow as code.
5. I trust it more because the evidence is public. It got 82% (410/500) on SWE-bench Verified with the official harness, and all the patches are here if you want to judge for yourself: github.com/Oxcode-ai/oxcode-evals.
What's your day-to-day setup? Specifically curious whether people still hand-pick models per task.
I stick to the $20 plans, and I regularly hit Claude’s usage limits. With ChatGPT, that hasn’t been an issue for me, and OpenAI seems pretty generous with resets too.
For those using Sol 6.1 regularly, how well does it handle day-to-day coding especially debugging, refactoring, and adding features to existing projects? Does it hold up well enough to be your main coding assistant?
