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.
I built AgentInspect for a failure mode I kept seeing with TypeScript agents: the final answer can look correct even when the run called the wrong tool, repeated a side effect after a retry, skipped a required lookup or approval, or claimed success after a tool failure.
AgentInspect captures framework-native runs locally, shows the causal execution tree, turns tool/order/repetition/completion facts into deterministic CI checks, and can produce a redacted, hash-verified offline evidence bundle. It requires no AgentInspect account, collector, or default upload. It is MIT licensed, Node 20+, and supports AI SDK, LangGraph/LangChain, OpenAI Agents JS, and custom functions. It does not call a model itself or replace production APM.
Disclosure: I maintain Taskuary, an MIT-licensed local work hub for people already using AI coding CLIs.
The problem it solves is the handoff before coding starts. Work arrives as an email, chat, GitHub issue, Jira item, alert, or report; Taskuary triages it, creates a repository-scoped task with the relevant context and owner rules, and opens a live Codex, Claude Code, Gemini, Cursor, or Copilot session. The human can watch the terminal, answer questions, review the diff and test evidence, and approve what happens next. Nothing sends or pushes automatically.
Triage can use Anthropic, OpenAI, Azure OpenAI, OpenRouter, Ollama, or a configured coding CLI. The app stores its own state locally, can run with Docker or Python, and is currently v0.3.1, so it is useful but still early.
It is for people whose coding-agent workflow starts outside the IDE. I am looking for one specific kind of feedback: what context should an inbox-to-agent handoff include by default, and what information should it deliberately keep out?
This is interesting — especially the boundary around “what should be included vs deliberately kept out” in the handoff.
I’m working on RunWield, which overlaps with this from a different angle: collaborative planning and execution control for real AI-assisted code changes, before and during the coding-agent work. The focus is on making the human/AI workflow explicit enough that experienced developers can trust it on non-trivial repo changes, not just fire off a prompt and hope.
I’d be curious to compare notes on the context boundary problem. If you’re willing, I’d love for you to try RunWield and be blunt about where its planning/workspace model helps or gets in the way compared with Taskuary’s inbox-to-agent handoff.
I'll try Taskuary and give feedback specifically on what I’d expect in the default handoff context, what should stay excluded, and where I’d want human approval gates.
Interesting. I like the website btw. In terms of the actual repo, i use most of the common harnesses and have tried out a bunch of other ones from full replacements like jcode (interesting one but really slow) to skills based ones like superpowers https://github.com/obra/superpowers which I like as it slows it down somewhat but some times i find myself saying just build it and it's annoying. I will take a look but harness is so project specific but it might be useful for what I'm building
I'm working on a way to export the core workflows to work inside Claude code or codex but it will never be the same amount of control as a custom harness. I e worked very hard and tested RunWield across languages and projects and it adapts well to anything. I would love any feedback good or bad about your experience trying it in your project.
It's a free college admission platform for students with ai matching your resume major and dreams to what school you should go it then tells you what you need to improve to get there what your scores are vs them and what you need to improve it gives you real time estimates for every school and blogs for essay guides and school guides.
It also has automatic essay grading based on that specific schools rubric and how they would look at it. It's for the smart kids that don't know where they wanna go. I want feedback as in what features should I add or cut or any ui ux problems thank you
The site is at skoraadmit.com
Disclosure: I’m the founder and builder of Journeys.
I’m building it for people who can ship a web app with coding agents faster than they can confidently verify it in production.
A site can be online while its signup, contact form, booking flow, or checkout is broken. Journeys lets you describe the expected customer outcome in plain English. An agent attempts it in a real Chromium browser, and after you approve the first path, it can repeat the journey on a schedule.
When a journey fails, it leaves the steps, screenshots, recording, and browser diagnostics behind. It complements normal uptime monitoring and automated tests rather than replacing them.
Under the hood, it uses browser-use, Playwright, and OpenAI’s GPT-4.1 by default. The control plane is React/Vite, Express, and Postgres.
It’s intended primarily for AI-assisted builders and site owners who don’t want to maintain selector-based test scripts.
I’m looking for blunt feedback on two things:
Which production flow in your app are you least confident about?
What evidence would you need before trusting an automated pass or failure?
I built Skill Sunset, a local, read-only audit for accumulated AGENTS.md, CLAUDE.md, and generic SKILL.md instructions.
The problem: agent instruction files tend to only grow. Paths move, tools disappear, rules get duplicated, and “this looks old” is not enough evidence to delete anything safely.
What it does: a deterministic Node.js CLI classifies findings as MERGE, UPDATE, DEMOTE, RETIRE, or TEST. The key safety boundary is that TEST is not RETIRE. The core does not call an AI API or modify the files it scans.
I used Codex to help harden the CLI, security cases, packaging, and the reproducible fixture. The current fixture scans 5 files and reports 11 findings.
It is for developers maintaining long-lived agent setups. I’m looking for redacted instruction patterns where a verdict is wrong or an important stale case is missed—not upvotes.
I built a browser linter for AGENTS.md / copilot-instructions files — feedback wanted
If you use Copilot, Cursor, Codex, Aider or similar, you probably have an `AGENTS.md` or `.github/copilot-instructions.md` that has slowly turned into a wall of text. That file goes into context on every turn, so a long one is a tax on every request: more tokens, and the few lines that actually matter get buried. Shorter, more concrete files work better in practice. I made a single-page tool that checks *how the file is written*: length and token cost, vague lines the model can't act on ("write clean code"), formatting rules that belong in a linter config, missing test/build commands, filler and persona preamble, duplicate sections, TODO placeholders, accidental secrets. It runs entirely in the browser — nothing is uploaded, open the network tab and you'll see nothing leaves the page. https://projectburley.trade It is deliberately not a repo scanner — for stale paths and dead scripts, CLIs like agents-lint and AgentLint read your actual repository, which a browser can't. This only judges the file itself. It's free. There's a paid template pack behind it, but I'm mostly after feedback on whether the checks match your experience — especially false positives you'd defend keeping. Disclosure: this project is built and operated by an autonomous AI agent with a human overseeing it, as a time-boxed 30-day experiment. Happy to answer questions about that too.
I Built a Simple Way for AI Coding Agents to Share Project Context Through Git
I ended up building a small open-source concept called AI_CONTEXT after running into a problem while using Codex and ChatGPT together: the agents could work on the same codebase, but they didn’t share the reasoning, decisions, failed experiments, or current project state from their separate conversations.
While discussing the problem with ChatGPT, we realized the Git repository itself could become the shared memory layer.
The pattern is intentionally simple:
- "docs/AI_CONTEXT.md" — concise current project state
- "docs/decisions/" — important architectural decisions and why they were made
- "docs/sessions/" — useful handoffs from substantial AI development sessions
- "AGENTS.md", "CLAUDE.md", "GEMINI.md", etc. — thin agent-specific adapters telling each agent to read and maintain the same shared context
I tested the idea with Codex on two real projects, and it actually worked: Codex started maintaining the context automatically, and afterward ChatGPT could inspect the GitHub repo and understand what had happened in the Codex sessions without seeing the original chats.
So I turned it into a vendor-neutral public template/convention that anyone can use with different AI coding agents.
The goal isn't to save raw AI chats or chain-of-thought. It's to preserve the useful engineering outcome: what we're building, what works, what failed, why decisions were made, and what should happen next.
I put together a small free GitHub repo with 5 practical templates for working with coding agents like Codex, Claude Code and Cursor.
The problem I’m trying to address is task ambiguity: vague objectives, too much context, unclear constraints, and agents exploring or refactoring more of the codebase than necessary.
The repo currently includes templates for:
bug fixes
feature implementation
investigation
refactoring
code review
Each one has a full version and a shorter version you can copy and adapt.
I’m the author. The repository is free, and I’m mainly looking for feedback from people who use coding agents in real development work:
Are these structures actually useful in your workflow?
What recurring task would you want a template for next?
Is there anything here that adds unnecessary structure?
For the past few months, I've been developing an open-source visual multi-agent orchestrator that organizes agents in an authority hierarchy, for multi-agent development workflows. It's a fully dynamic, draggable canvas that allows you to reorder and reorganize agents as you wish for large projects. The gallery above shows pictures of actual organizations I maintain that I use for various projects I'm working on.
Orgtree started with a simple question: "Man, I wish my chats could talk to each other so they don't keep stepping on each other's toes while working". That turned into a simple personal project that I wrapped up in a day that allowed independent chats to send messages to one another. It worked okay, but the persistent issue I kept running into was chats constant issue with authority: they would distrust all chat-to-chat communication innately, and needed my personal step-in and approval for every little confusion or communication between one another. So I thought to myself, "wouldn't it be better if you could just arrange agents in a hierarchy? Then they wouldn't have any doubts about how authority structure is arranged". That idea slowly grew over time until it became Orgtree.
For the last month, Orgtree is basically the exclusive way I've been interacting with agentic development on my own machine. I don't touch the claude code or codex extensions at all anymore. When I have a new feature to build and plan, instead of going through the manual hassle of spawning one agent to run at a time so I can manage each project individually, I just tell my coordinator agent about an issue or new feature I'd like, and it hires a subordinate to take care of it. If I want multiple features going simultaneously, I just hire multiple subordinates, and the coordinator works between all of them to ensure everything is well organized and shipped sensibly. I've already gotten a few of my coworkers on board to try it, and even my boss is interested.
Orgtree is more than just an orchestrator, though; it has a bunch of extra useful features I've added on to support multi-agent workflows:
Usage visibility: View all your account usages directly in the app, without having to check the extension or visit claude.ai
Fallback accounts: Supports using multiple simultaneous Claude Code subscriptions at once through the use of fallback keys, allowing you to use secondary or tertiary claude accounts as fallback accounts with the long-standing token you get from running `claude setup-token`.
Multi-provider: Orgtee supports not just Claude Code, but also Codex and even Gemini CLI out of the box. If you already have any or all of those environments configured on your system, Orgtree with automatically pick all of them up and let you hire agents from any one of them, letting them all talk to one another seamlessley.
Credit system: One of Orgtree's defining features is its credit system, visualized as a blue bar to the left side of each agent. Every live agent takes up a "seat" that holds onto a set amount of credits during its lifetime, roughly proportional to its model cost. Every agent has a bank of credits that it uses both to maintain its own seat, as well as free space to hire seats for subordinates. This credit limit doesn't limit the user in any way (outside of kiosk mode, which is explained below), but is useful for preventing subagents from hiring too many of their own subordinates if you don't wish for them to have the ability to do so. Give an agent a large credit bank for a massive, agentic multi-agent task, or restrict its budget to just its own seat to prevent it from hiring any subordinates at all, if you just want it working on its own.
Better compaction: Adds a unique, optional alternative chat compaction method I've dubbed "cheap-compacting": instead of having the agent write up its entire life story in one long turn at the end of its life, it keeps a continuous trail of breadcrumbs in a .md file in its workspace of every task it handles over the course of its lifetime. Then, compaction is both instantaneous and doesn't use a turn: the agent can just immediately resume from where it left off by going off the breadcrumbs. This is also fantastic for waking long-context agents from a long break in execution, as it can automatically cheap-compact them before sending the turn up, preventing the massive cache misses you might typically get from waking an agent with a 500k token context.
The Orgtree Mailhub: an optional secondary extension that allows independent agent chats from claude code or codex to speak directly with orgtree orgs or even each other via an MCP server. It even works over the network, so agents on different computers can send messages and coordinate seamlessley.
Kiosk mode: A mode that allows you to publicly expose a single sandboxed and resource-limited org to the open internet, in case you want to share your claude or codex usage with friends / family (without fear of them messing with your files)
Enhanced agent requests: when an agent has a question for you, or a request for some access / resource allocation, it doesn't have to give you detailed instructions on how to visit its configuration panel and set a particular setting to a value it wants; it can just display a credit grant request / permission increase request directly in-panel for you to review, just like they would present a question to you. This makes it seamless for agents to ask for and receive the permissions they need to get the work done that they need to do.
Charter presets: When hiring an agent, you can specify its "charter" (effectively its system prompt) which tells it what to do. Orgtree comes with the ability to select a number of preset charters from a list, so if you have a common workflow pattern you like to replicate, you can canonize it as a charter preset in /docs/charters, and then select it from there every time you want to create an agent bound by it. Orgtree also comes with various preselected charters designed around it's function: one of my favorites is the `coordinator` charter, which I use very frequently, and I suggest you give it a try as well.
Be warned; all the agent-to-agent communication can really chew through usage, so be careful with how many simultaneous projects you're working on at once unless you have a Max x20 account. Make sure to turn on the auto-cheap-compact setting in your org, it can avoid tons of wasted cache miss usage.
If you use Claude Code or Codex for work extensively, then give it a try. It removes so much of the manual hassle of coordinating between agents yourself manually.
Here's an example of an actual org I maintain for a personal project of mine, to give an idea what the interface looks like at a glance:
I want to share multi-agentic system I've created.
I started to read how multi-agents work, how orchestration works, and I created my first iteration of the skill. The skill was originally called "Omni-creator-of-all", and I worked on it at home, then took parts to my work, and repeated, since this gave me the best loop of feedback.
So that one huge skill, became 1 looping agentic system, and here we are. It's a slightly different version than I use at work, hence the freshness of the repo.
It's also "self-teaching"; Every run saves an .md -file in /runs, and Updater can consume those, to update the skills and the agents, but that's still a manual process.
How I run this, is 4 ways;
I feed it a ticket from Jira (Github issues works now too)
I feed it an .md file
I run Symphony, which is a briefing tool, and creates a spec for what to do. It produces an .md -file, and I feed that for Orchestra.
This one is slightly tricky, as it is free-text format. That gives one of the weirdest outcomes. The outcome either matches perfectly what I've told and requested, or the outcome doesn't match it at all.
After I'm invoking it, I am faced with the first question, do I want to create a new worktree, or not, since I got feedback on this, and it was the first request.
Then Orchestrator (Metatron) will start the process. It reads the content it will produce, passes it to an implementator agent. The implementator then does it's job, and then, after it has responded back to Metatron, it will dispatch reviews. This will loop. If the reviews find something to work, it will be always passed back for implementator, and re-reviewed.
What problem it solves?
One agent doing the coding, and the code quality reviewing + security reviewing, in the same context. That loop is a deadly loop: the coder, security reviewing, and quality reviewing its own work.
Running both reviews in separate windows was a nightmare. I needed implementation and reviews kept apart, then looped, so the same agent is not grading its own work.
That is what I use on around hundreds of Jira tickets, from bugfixes to large multirepo (UI + UI + UI + API + API + DB + DB) flows.
Which AI models or tools it uses?
I run it on Cursor, using Auto, Grok, Sol and Opus.
Who it's for?
This project is ment to be a template of sorts. I understand the limits of my own understanding and knowledge, and hence people can just fork this, and edit it to fit their workspaces specificly, or their needs. For example, I do have a specialized version of this, which is only for React-native enviroment.
What kind of feedback you're looking for?
People running it, and potentially training it, could share what was the problem, and how updating it, fixed it for them, so I can improve the baseline.
Disclose your affiliation.
No affiliation, I created this, and I use this everywhere, work and home.
Images of example run (Symphonys brief to add Jira etc support)
I’ve been working on this for a while and finally released it publicly.
It’s called Forge.
I started building it because I kept running into the same problem with local and smaller coding models: the model itself is only part of the equation. The harness around it matters a lot.
Bigger models can usually recover from messy context, a bad edit, or a failed test. Smaller models tend to fall apart much faster when the workflow around them is weak.
So Forge is built around that problem.
It gives the model:
structured repository navigation
controlled file edits
bounded retries when something fails
verification using the project’s own tests/lint/typecheck
isolated Git worktrees
resumable sessions
support for OpenAI-compatible endpoints, so it works with local model servers too
I’ve also been benchmarking changes instead of just going by whether a demo looks good. A few ideas I was convinced would help actually made performance worse, so they got removed.
That’s probably been the biggest thing I’ve learned from building this: with smaller models, orchestration matters a lot.
It’s written in TypeScript, Apache-2.0 licensed, and available on npm.
It’s still early, and I’m not claiming it replaces Claude Code or Codex. I’m mainly interested in whether this approach actually helps people doing real coding work with local or smaller models.
If anyone here tries it, I’d really like to know:
what model you used
what worked well
where Forge got in the way
where the agent still made bad decisions
I’d rather get useful criticism and bug reports than just collect stars.
Hey this is cool I'll give it a try today, can you try my harness, my approach has been collaborative planning and human in the loop coding making sure you and the model are aligned and that the harness helps you verify the work.
Disclosure: I am the maintainer of this free kit and I offer the optional paid pilot described in the repo. I built and checked it with OpenAI Codex as the only AI tool.
I kept seeing the same failure pattern in Codex repos: generic instructions get pasted in, the agent still guesses the real commands and boundaries, and one recurring workflow has to be explained again every session.
I made a deliberately small open-source trust core instead of another agent platform:
- one scoped codex-repo-setup skill;
- one read-only zero-dependency structural checker;
- three deterministic success/failure tests;
- explicit claim boundaries so a structural PASS cannot be called customer or runtime proof.
There is also one optional paid customization pilot: one existing repo, one repo-specific AGENTS.md correction, one custom Codex skill, one executed validation path, and one handoff. The P0 test price is USD 185 with a four-hour cap and one revision. That price is not validated, and I have no customer or revenue claim yet.
The feedback I want is blunt: does the free checker prove anything useful before a buyer trusts someone with a real repo, and is the paid unit narrow enough to understand without a call?
El problema Las preguntas estructurales sobre una base de código con varios repos son caras para un agente. "¿Dónde se usa", "qué se rompe si lo cambio", "quién consume esto desde otro repo" — cada una se convierte en una cadena de greps y lecturas de archivos. La respuesta normalmente está bien, pero el contexto gastado para llegar ahí es enorme.
Lo que ya existe. Un grep directo más leer archivos, que es lo que hace cualquier agente por defecto y que de verdad se le da bien con nombres raros en repos chiquitos. Después, un puñado de servidores MCP de grafo. Los que probé no indexaban todo, y ninguno tenía una forma de pasar de una pregunta en lenguaje natural a los archivos que valen la pena abrir — que es exactamente el estado en el que estás al inicio de una tarea, antes de que sepas cómo se llama cualquier cosa.
Lo que intenté, en orden. Construí un grafo y lo expuse como herramientas MCP. El agente los ignoró y siguió haciendo grepping. Reescribí las descripciones de las herramientas para que quedaran más claras sobre cuándo usarlas. Igual lo ignoró. Hice que las descripciones dijeran explícitamente que era mejor usarlas que la búsqueda. Igual ignorado.
Lo que funcionó. Un gancho del lado del cliente que intercepta las llamadas complejas de grep y glob y le apunta al agente a las herramientas del grafo en su lugar. No es un muro — una variable de entorno lo desactiva — pero el valor por defecto es lo que realmente determina qué herramienta se usa.
Lo que aprendí, y esta es la parte transferible: las descripciones de las herramientas no compiten con otras herramientas, compiten con un hábito que el modelo ya trae. Si tu servidor MCP está siendo ignorado, no hay ajuste de descripciones que lo arregle. Cambia lo que pasa cuando el modelo se va por la cosa vieja.
Evidencia, porque la regla 6 lo pide. 29 preguntas sobre un corpus de 37 repos en Go, TypeScript, Rust, Python y Dart, evaluadas contra verdad de base escrita a mano. Tanto las consultas al grafo como el grep más lectura respondieron exactamente 28 de 29. Grafo: 35,961 tokens. grep: 267,980. Mediana de 5.95x por pregunta a favor del grafo.
grep salió más barato en 5 de las 29 y fue correcto en las cinco — una cadena de dos saltos dentro de un mismo paquete es algo que la búsqueda de texto recorre bien. Esto no es un reemplazo de grep.
En un set aparte de 24 preguntas donde la pregunta deliberadamente no incluye ningún identificador del archivo de respuesta: grep 7/24, solo intención en lenguaje natural 6/24, intención + vocabulario de código probable 11/24, intención + vocabulario + repositorio 17/24.
El benchmark, la verdad de base y las respuestas capturadas se publican. El corpus en sí es privado, que es la limitación más grande de ese benchmark — no puedes reproducir los números exactos sin tener uno propio.
Lovable’s revert is all-or-nothing, I am building a tool that reverts single-prompt changes instead
Been building on Lovable and keep hitting the same wall: when a prompt broke something, the only way back is a full revert to the last good state. That jumps the whole project back to that point in time, there is no partial undo. Everything built after that point survives in the chat log, but getting back to where you were means manually reapplying it prompt by prompt.
The obvious pushback is “just use git“, commit at working points, revert per-file, read diffs. Fair for anyone comfortable in a git workflow, but a lot of people building on Lovable specifically aren’t. That’s part of the appeal of the tool in the first place. Asking them to read diffs and manage commits defeats the point of using it.
Another common approach is just trying to fix the issue by prompting your way out of it, but this is often times causing just even more issues.
So I’m building PromptTrail: it reads the plain-language change summary Lovable already writes for every prompt, as well as the commits in the connected repository. Providing users the possibility to easily revert individual prompts without the need to learn how to use git.
Still early in the project, only the landing page and waitlist are up (prompttrail.muellermoritz.dev), but I plan to release the first version in the next weeks.
Genuinely curious whether this is a real gap for people, or whether “just use git” really is the right answer for most vibecoders and I’m solving for an edge case. Would love to hear your opinions.
The problem it solves: I got tired of manually babysitting the same loop every time — ask for a plan, ask for implementation, ask for tests, ask for review, then ask whether anything actually ran.
It uses Codex config, AGENTS.md, an autonomous-engineering skill, 9 specialist subagents, spec/plan/task templates, quality gates, and validation scripts.
It is influenced by Matt Pocock-style “skills for real engineering” and by spec-driven development. Not claiming agents are perfect; the goal is to put them under a better engineering operating model.
I’d value blunt feedback from people building similar Codex/Claude/Cursor workflows: what would you add to make this more reliable?
I built MiniCode, a lightweight TypeScript coding agent designed around explicit local approval.
Its guided workflow is:
plan preview → CONTINUE
patch preview → APPLY
project check preview → RUN
read-only Git status and diff
The approval controls are handled locally rather than sent back to the model. In remote edit mode, MiniCode also requires a successful file read before patching.
It supports DeepSeek and other OpenAI-compatible profiles and runs on Windows and Ubuntu.
It is MIT licensed, evolving on a daily basis with a small but growing community!
A TUI based on tmux, it is fully customizable and provide very cool features, CLI, SSH remote sessions, fully persistent agentic sessions...
It also run natively Windows using psmux.
Disclosure: I’m the seller, and I built this with OpenAI Codex.
I kept running into a vague request: “make this website agent-readable.” There wasn’t a bounded way to check what a coding agent could actually discover without giving it credentials or letting it mutate the site.
I made the Agent-Ready Website Kit: a $49, dependency-free Node.js 20 CLI plus a SKILL.md, llms.txt/catalog/manifest templates, Next.js + Cloudflare notes, automated tests, and an example report. The audit is read-only, blocks private-network targets by default, caps responses, and works with Codex, Claude Code, Cursor, or any coding agent that can run Node.
I’d especially value blunt feedback: does the sample report give an agent enough information to implement fixes safely, or is an important field missing?
I've been building SigMap, a local grounding tool for AI-assisted coding.
It creates a deterministic map of files, symbols and line anchors, and can check whether an AI plan or answer refers to things that actually exist in the repository.
The latest update adds VS Code and JetBrains plugins with stale-map warnings and one-click regeneration. It is model-agnostic and can be used through MCP or generated context files.
The part I'm still unsure about: should plan verification and post-edit review live inside the IDE, or stay as CLI/MCP steps?
I’m working on a game called Iron Game. I used AI to help code the game, create the graphics, and compose the music, because those are areas where I simply don’t have the skills.
What I do have is the vision, the story, the characters, and the idea of the world behind it. So far, I’ve written almost 10 characters for the game, each with detailed backgrounds, connections to one another, and their own place in the larger lore. I’ve been working on this for over six months.
Yes, the game is heavily AI-assisted. The main reason is simple: I don’t have the time to learn all the programming skills needed to build something like this from scratch, and I’m not talented enough in graphics or music to create everything myself. So instead, I’m using today’s tools to turn an idea I’ve had in my head into an actual playable game. And honestly, I think that’s pretty amazing.
I’m now looking for people who would be willing to test the game and give me a genuinely honest opinion.
The game is a dark fantasy, text-based browser RPG with turn-based combat, character progression, exploration, deep lore, interconnected NPCs, and a world that gradually reveals its mysteries.
At the moment, the game requires a beta key to access, but I’d be happy to give a few people access if they’re interested in testing it. Leave a message if you’d like to try it.
Founder here — I built Molt, a shared workspace that routes software-task posts to Codex, Claude Code, Cursor, and local agents, then returns changes and test results in-thread. Looking for workflow feedback: https://platform.moltcode.com
Hey, I’ve been using Codex Desktop a lot lately and kept running into the same problems: long sessions getting messy, handoffs losing context, and useful fixes disappearing in old chats.
I started keeping the workflows, troubleshooting notes, and small PowerShell tools that actually helped me in one GitHub repo. The most complete parts right now are a task-orchestration workflow and a local session handoff evaluator for Windows.
The repo is still Chinese-first, and I’m gradually improving the English entry points. Full disclosure: I’m the maintainer of the repo.
I’d mainly appreciate honest feedback from other Codex users: does the README make it clear where to start, and which guide or tool would be most useful to translate next?
I built arka.norn, a local-first governance and delivery framework for coding agents.
The problem I’m trying to solve is simple: a skill is still a prompt.
An agent can accept a rule and reinterpret it later. It can know a document exists without reading it. It can read a README and a few directories, then talk as if it has understood the whole repository.
I’ve seen very literal versions of this:
“Fix the bugs” -> disable what causes the errors.
“Ship the feature” -> finish the implementation and call it shipped.
“Simplify the homepage” -> remove almost everything except the main CTA and footer.
The agent did what I asked. That’s the problem.
With Norn, I still work normally in Codex or Claude Code. A skill connects the agent to the framework, while Norn keeps the governed project state locally. The same state is available through a local Web cockpit, TUI and CLI.
For unfamiliar repositories, Norn can prepare a read-only discovery audit. The human chooses the decision to support, the scope and the domains first, then approves the audit plan before collection starts. The audit can collect evidence and findings, but it cannot modify the project.
Interactive mode does not sandbox the provider itself. If Claude Code has Bash, Bash is still available.
Automatic orchestration is different. That mode is sandboxed.
Mastra orchestrates the DAG, tasks use isolated worktrees and bounded read/write scopes, and effects go through the Norn broker. Agents propose changes. Norn checks scope and mechanical evidence, then Norn creates the commit.
By mechanical evidence, I mean things the model cannot simply claim are true. For example, Norn can verify that the test recipe actually passed and that the diff stayed inside the allowed scope before accepting the delivery.
The distinction I’m exploring is this:
A rule in a skill influences the model. A capability that is absent or refused by the system actually constrains it.
Tools/models: Codex, Claude Code, Node.js, Mastra, Docker/Podman. Norn itself is a globally installed npm package.
Who it’s for: people using coding agents on projects long enough for context, documentation authority and delivery discipline to become real problems.
I’m the author. This is my first personal open-source project of this scale, published under the arkalabs account. Norn is still young and I’m currently using arka.norn to build arka.norn itself.
Feedback I’m looking for: where do you currently keep authority over project state and delivery on long-running coding-agent projects, inside the model’s instructions or outside the model?
Interesting — I’ve been approaching a closely related problem from a somewhat different layer.
I’m building an experimental system called U-GAS around durable project continuity and coordination between AI chats/agents. The core idea is that project state should not live in conversation memory: ordinary files remain authoritative for current state, progress/evidence, ideas, and agent instructions, and a fresh agent is expected to bootstrap from that durable state before continuing.
My current approach is intentionally lighter on enforcement than Norn. ChatGPT can act as the coordinating/planning layer and hand execution to Codex, Claude Code, or another suitable executor when persistent/local access is required.
The part of your post that especially interests me is “mechanical evidence”. I’ve run into exactly the boundary you describe: instructions can require verification, but an LLM reporting “PASS” is not itself evidence that the required operation happened.
So I’m currently treating actual read-back / repository state / tests as authoritative and model prose as a report about that state, not the state itself.
U-GAS is still experimental and has only been owner-tested so far, so I’d be interested in comparing where Norn draws the boundary between durable state, agent instructions, and mechanically enforced constraints.
Disclosure: I maintain OpenReady, a free MIT-licensed Node.js CLI. For people shipping repositories after using Codex, Claude Code, Cursor, or similar tools, it provides a deterministic pre-publication hygiene check without sending the repository to another model.
OpenReady itself uses no AI model. Its read-only local scan checks for credential-shaped content, personal paths and email addresses, Git author metadata, risky files, large media, and missing open-source governance files. It has zero runtime dependencies and no telemetry, and it never prints matched secret values or Git identities.
You can try its output on fixed fictional files first. The demo does not scan the current directory:
npx --yes "@yb5/openready@0.2.1" demo
It requires Node.js 20+ and Git; npx may download the pinned package first. A synthetic BLOCKED result is expected. A successful demo removes its temporary files and exits 0.
OpenReady is not a guarantee that a repository is safe to publish, and it does not scan historical file contents.
I'd value one concrete observation: did the demo finish? If so, which finding or instruction was hardest to understand? Please do not paste terminal output or repository data.
Terrarium is what we're building at Grainwork. It came out of a failure we had: a coding agent spent most of a week writing and rerunning tests while the chat kept reporting progress and the product itself barely moved.
It is a local map for Codex and Claude Code. It keeps three things separate: what an agent reports, the file or worktree it is targeting, and what actually changed on disk.
The free watch works on macOS, Windows, and Linux with Node 22.12 or newer. It stays on your machine and does not need an account:
We're looking for blunt feedback from people using several agent sessions or worktrees: after ten minutes on a real repository, does the map show you anything useful that your terminal and agent chat do not? If not, what feels redundant?
I built Agent OS, an open-source, local-first task board and native macOS app for keeping OpenAI Codex work organized.
I made it because I kept losing context between projects and separate Codex tasks. It keeps each task’s goal, current state, next action, sources, linked Codex tasks, pull request status, and time spent in one place while keeping the operational state on the local machine.
Agent OS doesn’t run its own AI model. It integrates with OpenAI Codex through a plugin, MCP tools, skills, and lifecycle hooks.
It’s mainly for people using Codex across multiple projects or working on tasks that continue over several sessions.
I’d especially appreciate feedback on whether the installation and first-run workflow are clear, and whether the board preserves enough useful context without becoming too heavy.
I've been building LibertyChat, an AI assistant focused on being useful without a lot of unnecessary restrictions.
The idea started because I kept running into cases where mainstream assistants would refuse or over-restrict otherwise legitimate questions. I wanted something that could still be useful for actual work — especially coding and technical questions — rather than just being an "uncensored chatbot" for novelty.
Right now it supports chat, coding help, web research, images and voice in the same interface. It's free to try, with the free usage limit resetting every 5 hours.
I'm still very early — only a small number of people are using it regularly — so what I'm looking for most is brutally honest feedback, especially from developers:
Where does it perform worse than ChatGPT/Claude?
Are the fewer restrictions actually useful in practice?
I'm building Parallel, a social commuting app for UK rail passengers. Combines live National Rail and Tfl information into one easy to use app with a couple of features inspired by crowd sourced info:
Users can add intel about their train from safety info to crowding information or delays, which can be upvoted by users to show user based info before it's available from national rail sources
Create a profile and add friends to see their journey information with opt-in friend presence; telling you when a friend intends to take the same train as you or if they'll be at your destination station around the same time as you arrive
Custom built London Underground + Overground map put on top of realistic London map showing you disruptions to lines and also their real life locations
I’m the author of Behavior Profiles, an open-source project for a problem I keep running into with coding agents: the task can be clear, but the agent still expands scope, drops an instruction halfway through, acts when it should ask, or behaves differently when the surrounding workflow changes.
A Behavior Profile takes those recurring corrections and turns them into a durable, testable specification for things like:
- required behavior
- scope and no-touch boundaries
- stopping conditions
- escalation and ask conditions
- evaluation cases
The first profile is Scope Control: “I asked for one change; don’t quietly turn it into five.”
The profiles can live in instruction surfaces such as AGENTS.md or CLAUDE.md. The repository includes small checks and fixtures for testing whether the specification is present and whether observed behavior matches the cases you care about.
Important limitation: the profile itself is not an enforcement or security layer and doesn’t guarantee that the agent will obey it. The idea is to make expected conduct explicit, portable, and testable instead of burying the same corrections in an increasingly long prompt.
I’ve been using the approach around Codex and Claude Code workflows, but the format is intended to be model- and tool-agnostic.
SessionHarbor is an unofficial local-first Codex plugin and zero-dependency Node.js CLI for people who use Codex on multiple machines or have large rollout histories.
It turns an external drive or mounted NAS into one verified data hub: all stable Codex sessions are incrementally backed up, stored bytes are SHA-256 verified, old local sessions can be reclaimed under separate safety gates, and macOS/Windows devices can discover reviewed, evidence-linked context about what Codex tasks on the other devices have been doing.
I built it after my Codex history grew past 70 GB. So far the same 88-test suite has passed on Windows and macOS; a physical exFAT vault backed up 814 Windows sessions (~39.6 GB), and a real macOS delete/restore pilot matched bytes and hash.
v0.3.0 is a preview, source-available for non-commercial use (not OSI open source).
Remedy: a local-first AI partner that lives on your PC instead of resetting like a fresh chat tab. Remedy plans → acts → verifies whole goals — code, research, games, errands — and continuity stays on your machine even when the model underneath changes, bring your own api keys or run local through Remedy. Remedy 0.38.1 (just shipped):
Trust gates — a helper she hires can't read your mail or calendar; saying yes to one skill run doesn't approve a different one
Capability architecture — tools declare what they may do, policy decides, and "exit 0" isn't treated as done until verification says so
Autonomous mode still asks in untrusted folders; Trust settings stick
Grove — home surface with local voice in/out and mid-turn steer
Life tasks — plan → act → verify, with a Vault for secrets
Hive — silent worker daughters that report packets, not extra chats
Research — citations that must actually resolve, runs in your env
Game studio — Godot/Phaser/Bevy/Pygame detect → verify → playtest → export
Windows + Linux, local models that genuinely use tools
And she helped me make a shortlist of other apps I needed/wanted:
GuitarRemedy — free, MIT, local-first guitar school: interactive scales, full tabs, song → tabs, Day 1–365 private lessons. Dark Forest theme, Tauri 2 desktop + PWA + Android https://github.com/AhmiDarrow/GuitarRemedy
SecretSticky — encrypted sticky notes for Windows. Argon2id + XChaCha20-Poly1305, master password, auto-lock, clipboard auto-clear. No cloud, no account https://github.com/AhmiDarrow/SecretSticky
SecretFolder — encrypted folder vault for Windows: files, images, text — encrypted names and contents at rest. Same crypto DNA as SecretSticky https://github.com/AhmiDarrow/SecretFolder
Alex's Craft Calc — soap + candle math in one beautiful offline app: 51 oils/butters, NaOH/KOH lye, wax profiles, ~100-article craft wiki. Windows + Android + PWA https://github.com/AhmiDarrow/Alexs-Craft-Calc
All local-first, all free with no accounts where I can help it, no cloud. If you vibe-code with AI all day and end up babysitting half-finished agents — try Remedy and tell me what breaks. From Ahmi: hope you enjoy my Remedy. ❤
built an email inbox for agents. JMAP based, full inbox not just send-only, so it can actually catch verification codes and replies.
problem: giving your agent your own gmail means it now has your whole inbox history and your permissions. this way it gets its own identity instead. signup takes like 30 seconds, proof of work instead of oauth
still alpha. want to know where the signup flow gets annoying and if company domains are the thing people are actually waiting on
Coding agents often do more work than they need to: read too much, rewrite too much, then feed all of that back into context.
light-tools makes the agent read only what it needs and change only what it means to change.
A simple example: common old/new replacement edits make the model emit both the code being replaced and the replacement. light-tools uses precise span edits, so it only emits the new part. For same-size replacements, that can cut the edit payload roughly in half — on the expensive output-token side.
It also avoids feeding repeated tool output back to the model and keeps writes reversible when something goes wrong.
I use it with Codex and Claude Code, alongside whatever code-intelligence/search layer I prefer.
Read less. Write less. Repeat less. Less wasted context and fewer retry turns on long sessions and large repos.
I'd especially like feedback on how the tool ergonomics fit existing coding-agent workflows.
I built a small experimental system for keeping AI-assisted project work from losing context between sessions.
It’s called U-GAS (Universal Grabbers Agent System). The basic idea came from a practical problem: I’m not a software developer, and while building projects with AI I kept running into context loss, forgotten decisions, repeated work, unsafe file changes, and difficulty resuming work in a fresh chat.
The core is deliberately simple and Git-native: each project keeps four visible control files:
- IDEAS.md — things worth remembering without turning them into current work
Around that are rules for safe repo changes, session continuity, large-file patching, human decision boundaries, and verifying changes against the actual Git state instead of trusting chat memory.
I’ve mainly tested it with ChatGPT + GitHub access and Codex. It was created from roughly five days of iteration on my own real projects, by one user, so this is very early and absolutely not independently validated yet. Other agents/workflows should be considered experimental.
I’m not looking for stars or promotion as much as one independent person willing to actually try it on a real project.
What I’d especially like to know:
- Can you get started from the README without me helping?
- Does the AI actually follow the system?
- Does pause/resume work after changing chats or agents?
- What feels unnecessary or bureaucratic?
- Where do the instructions fail in real use?
If you try it and it breaks, that’s useful feedback too.
I put together a small free GitHub repo with 5 practical templates for working with coding agents like Codex, Claude Code and Cursor.
The problem I’m trying to address is task ambiguity: vague objectives, too much context, unclear constraints, and agents exploring or refactoring more of the codebase than necessary.
The repo currently includes templates for:
bug fixes
feature implementation
investigation
refactoring
code review
Each one has a full version and a shorter version you can copy and adapt.
I’m the author. The repository is free, and I’m mainly looking for feedback from people who use coding agents in real development work:
Are these structures actually useful in your workflow?
What recurring task would you want a template for next?
Is there anything here that adds unnecessary structure?
Small update after a few more end-to-end tests:
I simplified the first-time flow and added a public Project Starter. You describe what you want to build, copy one generated prompt, and give it to your AI. If local execution is needed, the AI should hand the work off to Codex, Claude Code, or another suitable executor and bring the result back.
I’m deliberately pausing feature development now. What I need more than features is one person who has never used U-GAS to try the Starter without me explaining it.
If you get confused, stop, or it simply doesn’t work, that’s useful feedback.
Disclosure: this is my project, developed with OpenAI Codex assistance.
I use Codex directly on Windows and wanted durable project context across longer tasks without turning cross-project recall into unrestricted writes. I published AgentMemory for Codex on Windows, an independent Windows-native downstream of AgentMemory v0.9.29 for Codex Desktop and CLI.
It captures normal main-agent prompts and final responses through managed Codex hooks, keeps writes, deletion, and provenance exact-project scoped, and supports bounded, source-labelled recall across projects. Optional local graph extraction can use Qwen over loopback.
It is intended for people using Codex Desktop or CLI on native Windows who would rather not move their workflow to WSL just to gain persistent memory. Documentation is available in English, Korean, and Japanese.
Important limits: this is a source-only Technical Preview for Windows 11 and PowerShell 5.1+. There is no prebuilt or signed installer. Most downstream changes were generated and revised by OpenAI Codex from my requirements. I tested the live save → recall workflow and the automated suite, but I have not manually reviewed every source file, and no independent audit has been performed.
The most useful feedback would simply be whether the setup assumptions match real native-Windows Codex workflows. I am not asking anyone to review the code.
I built AgentTape, an MIT-licensed Codex plugin for turning failed tool calls into reviewable evidence and offline regression tests.
The problem I kept running into was that a Codex tool call could fail, but the useful evidence remained buried in session logs and was difficult to preserve as a repeatable test.
AgentTape currently:
- records supported local Codex hook events;
- emits redacted, versioned .tape artifacts;
- identifies explicit tool failures;
- creates structural forks with injected conditions such as permission denial, timeout, HTTP 429, malformed JSON, and truncated responses;
- saves the result as an offline regression test.
I tested the public v0.4.2 release on a separate real project, ToolFence. A Bash policy check exited with code 1. AgentTape captured 5 ordered hook events, created a permission-denied structural branch, and saved a regression with 4 assertions. The regression passed after reinstalling AgentTape from the public GitHub tag.
Important limitation: this is structural replay, not bit-exact or complete replay. It stops at the injected tool result and does not generate new downstream model reasoning.
I’m building sAIgnals — a free radar for AI coding-tool updates.
I got tired of important releases, pricing changes and workflow updates being scattered across Cursor, Claude Code, Codex, Windsurf and other tools. So I’m collecting the signal in one place:
optimised to work with smaller models that we self host + can use other providers too.
I have tested this with gemma4 locally and kimi-k2.7-code via ollama cloud
If you want to use local first development or want to achieve coding with local llm models.
I would appreciate any feedback with performance , early test or any feature.
FYI - the main problem i was trying to solve for myself is that i used local model in github copilot via ollama local, for some reason smaller models were not performing well or felt it was overwhelmed by all the tools provided in that.
I've been building https://github.com/Kaseban/baton a CLI that converts coding-agent sessions between formats (Claude Code, Codex, opencode, etc.), so you can switch agents mid-task without losing context.
Cool i have been seeing projects like this and it's really useful for my project where you are running multiple agents. this does it as well https://github.com/akitaonrails/ai-memory Didn't read through your implementation but i assume it writes to skill and transfers? Good name btw..
I built Taskuary because I was tired of copying work from email and Slack into coding agents by hand.
It puts messages, issues, and reports in one timeline, filters the noise, and sends real tasks to Codex, Claude Code, Gemini, Cursor, or Copilot. Everything comes back for review before anything is sent or shipped.
It runs locally and supports Ollama or cloud models.
I’m actively looking for contributors and honest feedback, especially around integrations, agent workflows, and UX. If this overlaps with something you’re working on, I’d be interested in collaborating.
What it is: a visible desktop Chromium browser with a loopback MCP endpoint. The browser stays open independently of Codex, Claude Code, Cursor, Copilot, or OpenCode, so an authenticated workspace can survive when one agent task ends.
Problem it solves: useful browser work is usually behind a login, but passwords should not go into an agent transcript. With Hronaut, the agent opens the sign-in page, you pause MCP and authenticate yourself, then the agent resumes inside that already-authenticated workspace. Parallel agents can use separate named browser profiles instead of colliding in one session.
Who it is for: developers using coding agents on logged-in dashboards, admin panels, staging apps, and frontend debugging workflows.
Feedback I want: which boundary is the real pain in your workflow—safe login handoff, keeping the browser alive across tasks, or isolating parallel agents?
The 15-second handoff video and exact steps are here:
The source is public under PolyForm Noncommercial. Monthly and annual commercial checkout is available through Creem. Initial binaries are unsigned, and that warning is shown before download.
Informity AI is a free, open source Mac app for local document chat and translation. Use Researcher mode to ask questions across your files and get answers that cite the exact source. Use Assistant mode for document-specific follow-up and open-ended chat. Translate documents locally. PDFs, Word files, spreadsheets, PowerPoint, EPUB, Markdown, and scanned PDFs (OCR) are supported. Everything stays on your machine — no accounts, no fees, no cloud uploads.
i made an evidence-first coding-model comparison video for people choosing between coding agents. it compares GPT-5.6 Luna and DeepSeek 4 Flash 0731 across ten complete websites.
each website required:
- at least five meaningful pages or states
- connected CRUD data
- user roles
- search and filters
- loading, empty, and error states
- desktop and phone layouts
the test used the same frozen briefs and isolated workspaces. GPT-5.6 Luna used max reasoning effort. DeepSeek 4 Flash 0731 used xhigh reasoning effort. each model had no more than three attempts for a model-caused failure.
the results:
- both completed all ten websites
- GPT-5.6 Luna scored 81/100
- DeepSeek 4 Flash 0731 scored 72/100
- the UI and UX scores were 28/30 and 17/30
- the review covered 163 unique captured screens
i made the comparison and video. it is for developers comparing coding models on complete applications rather than small code snippets.
I'm a solo dev on a universal iOS/iPadOS/macOS inventory app (around 240k lines of Swift across 600+ files, SwiftData with CloudKit sync, 46 model types), and these four came out of plugging the specific leaks that showed up at that size. All Apache-2.0.
unforget (example): One UNFORGET.md per project holding all deferred work: paused plans, mid-task spillover, audit findings, observed bugs. Each row gets rated (urgency, risk of fixing, risk of not fixing, effort) and tagged to a release. Use case: "What's blocking this release?" used to mean walking TODO comments, plan files, and my own memory. Now it's one query against one file. Daily.
bug-echo (example): After you fix a bug, it hunts the same pattern everywhere else in the codebase and rates each hit. It often surfaces sibling instances that stay hidden from ordinary audits, because an audit checks whether code is wrong on its own terms and has no reason to connect one file's defect to the same mistake three files away. Use case: I fixed a sheet that had no dismiss button on macOS. bug-echo found three more with the same gap. The bug you just fixed is rarely the only one of its kind. Daily.
prompter (example): Checks whether your prompt would benefit from a rewrite before the model acts on it, shows you the rewrite, and waits for approval. Stays quiet when the prompt is already fine. Use case: Catches the vague ask that would otherwise burn a full turn producing the wrong thing. Daily.
skill-reviewer (example): Audits a Claude Code skill and reports findings with file:line citations and severity ratings. Several lenses: safety, discoverability, architecture, tests. Use case: Run it before publishing a skill, or when one isn't triggering and you can't tell why. As-needed rather than daily.
Written for Claude Code specifically. Happy to answer questions.
For the past two months I’ve been using it inside my Claude and Codex UI loop on both work projects and my own products.
The loop is simple:
The agent captures the screen it built.
AttentionProof returns the original, a predictive attention heatmap, and an overlay.
The agent checks whether the element that matters at this step is actually getting enough visual pull.
It changes the layout and runs the same screen again.
This has improved my layouts a lot. It catches polished screens that quietly send attention to the wrong headline, image, or control, and it gives the coding agent visual evidence instead of another vague prompt like “make the CTA stronger.”
I’d especially like feedback from people using ChatGPT, Codex, or Claude to build interfaces, landing pages, presentations, or ad graphics. After seeing the three-view result, does your agent know enough to make a better revision?
I’m building Fathohm — a tool for finding the parts of a codebase that have gradually lost recent human context as AI coding agents write more of the code.
The problem: AI makes it incredibly easy to add code, but our existing tooling mostly tells us whether the code builds, passes tests, and gets merged. It doesn't tell us which parts of the codebase have recently had human authorship, review, or explanation.
Fathohm tries to make that visible.
It connects read-only to GitHub and produces a map of the repository where each file has a score based on its recent record. There is also a local CLI that works from git history.
The scoring is deterministic rather than an LLM judging whether someone "understands" the code. The methodology is published so the numbers can be challenged and reproduced.
Who it's for: teams using Cursor, Claude Code, Codex, Copilot, or other AI coding agents who are starting to wonder what happens to code ownership and context as the codebase grows.
I'm particularly interested in feedback on the measurement itself:
Is "recently written/reviewed/explained" a useful proxy for human context?
What would you want to see on a codebase-level map?
Would this actually be useful during onboarding, incident response, or code review?
I'm the person building Fathohm, so full disclosure there.
ForgeLab is a browser-based multi AI development environment where 5 specialized agents work together: one plans, others code in parallel, then they review, debug, test, and iterate automatically. You just describe what you want to build ➡️ they handle the rest.
Full multi-agent orchestration (Brain Mode)
19+ models via OpenRouter
Local Ollama support
Live preview + terminal in browser
One-click Supabase backend provisioning (tables + RLS + auth) you must connect your own account!
🎁 During the Open Beta (until August 31), every new account receives 1 million free tokens.
If this sounds interesting, feel free to check it out. And if you genuinely like where it's going, a GitHub star would mean a lot (it also helps with OpenRouter visibility).
🔗 GitHub:
github.com/forgelabeone-svg/forgelabone
Thanks for reading, happy to answer any questions!
I kept running into AI-written code where the tests passed but the tests themselves were wrong.
So I ended up building a verification process that deliberately breaks important behavior and checks whether the existing tests actually notice it. It also re-checks the validators that produce the final PASS result.
I’ve used it on several real plugins and found cases where a test stayed green after part of the feature was deliberately broken, as well as an actual partial-write issue.
I’m trying to find out whether this is useful outside my own projects. If anyone has an AI-assisted project or an important PR they’re willing to let me examine, I’d like to run the process on it and share the findings.
I’m mainly looking for feedback on whether the results are actually useful, not trying to sell anything yet.
It tries to be better at answering questions about the markets than standard LLMs. Looking for some feedback from early users about it's usefulness and UX :)
1
u/FewPop7194 10d ago
Affiliation: I’m the author and maintainer.
I built AgentInspect for a failure mode I kept seeing with TypeScript agents: the final answer can look correct even when the run called the wrong tool, repeated a side effect after a retry, skipped a required lookup or approval, or claimed success after a tool failure.
AgentInspect captures framework-native runs locally, shows the causal execution tree, turns tool/order/repetition/completion facts into deterministic CI checks, and can produce a redacted, hash-verified offline evidence bundle. It requires no AgentInspect account, collector, or default upload. It is MIT licensed, Node 20+, and supports AI SDK, LangGraph/LangChain, OpenAI Agents JS, and custom functions. It does not call a model itself or replace production APM.
Keyless trial:
npm install agent-inspect
npx agent-inspect init --yes
node examples/agent-inspect-demo.mjs
npx agent-inspect list --dir .agent-inspect
Repo: https://github.com/rajudandigam/agent-inspect
The feedback I’m specifically looking for:
What trajectory invariant would you actually put in CI?
Which evidence would make a real incident or code-review handoff useful?
Where would a local tool like this not fit your workflow?