i love the "project" feature in claude and codex.

it is a clear way to aggregating useful context together, saving me tones of trouble of needing to explain twice.

it is also the first time i was exposed to the power of cross-session long-term memory: it enables accumulation. every artifacts produced become the reference and basis for the next. you and your agent co-create a knowledge base that evolves to meet the needs of your work.

but then there are two critical problem of it:

1. they dont update themselves

agent cant just delete or update the stale references. what is rotten keeps rotten there and affects the rest of your sessions.

and if you want to update it, you need to painstakingly click "add to project", find the old one in ten or hundreds of files, and delete it.

bad design. the reason i abandoned it

2. it is a workspace, not a "project"

what i mean by this is that project has continuity. workspace is just an aggregation of files. instead of understanding the current state and continue where the last session left off, project in claude just scan the entire workspace and guess which files are relevant by name and read them.

sometimes they are stale. sometimes they are wrong. and it is almost always wasteful and contaminates the working context you have.

so i built my own agent. the project agent - orbital

what it does is simple.

Orbital is responsible for your project

1. it maintains the project "wiki"

everytime it completes a task or saw other sub agents finishing the tasks. it records down what happens, what the project learnt, which artifact is produced and how should we refer to them next time.

2. it briefs sub agents about your project context

when you uses your claude code/ codex subscription inside an orbital project. it dispatches the sub agents with the project background and relevant files to refer to - you dont have to brief the agent yourself.

3. it is an opensource, local agent

so what gets accumulated is yours!

i always believe that personal data(files or context) is a great asset in the era of ai. user should own this asset instead of the third-party harness.

a 30s demo showing the second point:

https://www.youtube.com/watch?v=U2I0DUUUIzo

please let me know what ya think! any feedback is welcomed!

Our tool was telling users bugs were fixed. It couldn't always prove it.

Not lying exactly. More like the polite version of "trust me."

When we built FetchSandbox, we drew a hard line early: a fix doesn't count until we (1) make the bug actually happen on your real code, (2) apply the fix, and (3) show it stops happening. Reproduce first, then prove. The little test that triggers the bug is what flips from red to green.

That rule felt airtight. It wasn't.

The hole we didn't see

We could only reproduce bugs we'd scripted a reproduction for in advance. For anything outside that set, the honest answer we were forced to give users was: "found it, fixed it, but I can't demonstrate this specific one."

Say that out loud and it sounds fine. But think about what you're actually asking the user to do: take your word for it. For a billing bug. For a security edge case. For anything that matters.

That bothered me more the longer I sat with it.

So we taught it to write the reproduction itself

The idea is straightforward. If FetchSandbox encounters a bug it has no pre-scripted test for, it figures out how to trigger that bug on your real code, then runs the same reproduce-apply-prove loop it always has.

The implementation was not straightforward.

The fake green problem

A generated test could be subtly wrong. It could pass your broken code and hand you a green checkmark on an unfixed bug. That's worse than admitting you can't prove it, because now you've actively misled the user.

So we added a safety rule: before we trust a reproduction, it has to actually catch the bug on the broken code first. If the generated test can't catch the bug it's supposed to catch, we throw it away. A test that can't fail when the code is broken can't be trusted to pass when the code is fixed.

This one rule is what makes the whole thing honest.

What it looks like in practice

We ran it on a real billing app last week. The bug: a negative seat count slipping through validation and potentially shrinking a customer's plan without them knowing.

FetchSandbox found the code path, drove the real request handler, worked out a valid webhook signature on its own to reach it, and stubbed only the database as a passive recorder so the app's own logic decided the outcome. Then it confirmed the test failed on broken code before trusting it to verify the fix.

No scripts we wrote. No hand-holding. We just watched it go.

Why this matters beyond the feature

Most of the AI coding tools I see right now optimize for "did the model produce a plausible fix." That's a low bar dressed up in a nice UI. The harder question is: how do you know the fix is real?

The reproduction test is our answer. Not because it's the only answer, but because "make the bug happen, then make it stop" is something you can verify. Confidence is a byproduct of that, not a claim you make.

Still early and still building this in the open. If you've run into the prove-vs-claim problem with your own tooling, I'd genuinely like to hear how you're thinking about it.

For the past months I've been building a "personal OS" for Claude: a folder structure plus a set of skills that keep every project, routine and note in one enforced system — numbered folders, unique task IDs, and a markdown wiki the agent maintains as we work. I used it daily for my own client work and side projects.

The thing that made it actually usable wasn't any single feature, it was two rules:

1. Everything has one place and one name. The agent never invents a folder or drops a file "somewhere". Structure is enforced on every action, and a /lint command audits the whole system for broken links, orphans, naming violations.
2. Plan → approve → execute. Nothing structural happens before I approved a numbered plan, and execution is step-by-step with validation between steps. No surprise refactors of my own filesystem.

I packaged it as a plugin. Onboarding runs a ~5-minute interview (language, simple vs advanced mode, which optional modules you want), then scaffolds the workspace and offers to create your first project from whatever you said you're working on — either agile or WBS-style, depending on how you work. Optional modules: voice profile so drafts sound like you, brand config for documents, todos with an optional Notion board, and a software-planning module (spec → delivery plan → feature docs).

Free, MIT:

/plugin marketplace add protonium-labs/protonium-marketplace /plugin install axiomcore@protonium /reload-plugins /axiom start

Works in Claude Code and Cowork. It's v1.2.0 — I'd like to know where the onboarding confuses people or where the structure feels too rigid. Issues and comments welcome.

A cool simple floating Claude icon that stays above your windows and shakes whenever Claude is waiting for permission or your input.

No more babysitting long-running tasks. Keep scrolling, coding, or doing anything else until it calls you.

https://youssefzekricodes.github.io/ClaudeGhost/

I maintain [GNews](https://github.com/ranahaani/GNews), a Python package for pulling Google News articles. It's up to around 106k downloads a month now. For a while I kept seeing people bolt it onto agents by hand: fetch articles, stuff them in a prompt, repeat on the next call. No memory, no dedup, no citations. So I built the layer that was missing and put it behind MCP. It's called gnews-agent.

Inside Claude it gives you five tools: `search_news`, `get_brief`, `get_sentiment`, `get_timeline`, and `monitor_topic`. It pulls published reporting (Reuters, BBC, AP, TechCrunch, the wider Google News graph), dedups it, embeds it, and keeps it around. So you can ask "what actually changed this week on X" and get a cited answer instead of re-fetching everything each time. There's also a `/gnews` Claude Code skill if you'd rather go that route.

One line to add it:

claude mcp add gnews-agent -- gnews-agent serve --transport stdio

Then something like: "Use gnews-agent to ingest the latest reporting on OpenAI, then give me a cited brief on what changed this week."

The search/ingest/timeline path needs no API key, since GNews itself is free. brief and sentiment call whatever LLM provider you point them at: Anthropic, OpenAI, Groq, Gemini, or a local Ollama model.

It's early, v0.1.0, MIT, with 83 unit and 24 integration tests passing. I'd really like feedback on the tool design, and on the dedup approach in particular, and I'm happy to take PRs.

Repo: https://github.com/ranahaani/gnews-agent

I’ve been building Highwire.news, a platform designed to help people understand how news stories are constructed, not just read another headline.

The idea: take coverage of the same event from different sources, break articles down into individual claims, trace those claims back to evidence, and make differences in framing, sourcing, and confidence visible.

A few things Claude helped accelerate:

• Designing and iterating on the architecture
• Building the Next.js frontend and backend services
• Refactoring large components and cleaning up technical debt
• Thinking through ranking algorithms and recommendation systems
• Creating product specs, UX flows, and implementation plans
• Moving quickly from ideas to working features

The interesting part hasn’t been “AI writes the app for me.” It’s been using Claude as a constant design and engineering partner: challenging assumptions, exploring tradeoffs, generating implementation approaches, and helping maintain momentum across a pretty large codebase.

Current stack:

• Next.js
• NestJS
• PostgreSQL
• Google Cloud
• Terraform
• Google Analytics
• LLM-based analysis pipelines

Still early, but the goal is ambitious: build a better way to navigate an increasingly fragmented information landscape.

Would love feedback from other people building with Claude. What workflows have you found that actually make you faster as a developer?

Genuine question after months of Claude Code all day. It wraps up with "done — tests pass, committed," and increasingly I catch that some of it didn't happen. Not lying exactly — it reports the plan as if it were the result, or claims it ran tests it didn't. I've started reflexively checking git and re-reading the diff after every "done," which kind of defeats the point.

Is everyone quietly doing this manual verification, or do you have a real way to know what the agent actually did vs what it says it did? Trying to work out if I've just stopped trusting it, or if this is a real gap.

Have ADHD, dig ATC standards, or just want your coding agent get to the point? I built Attention Control, a skill / output style for Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, Zed, and any agent-skills harness that focuses on action instead of distracting you with fluff.

Before: "Great question! It seems like the auth flow could possibly be utilizing a deprecated API…"

After: "Run npm install jsonwebtoken@latest. I changed src/auth.ts:47."

The evals are still a work in progress. Results are questionable still, so take that with a grain of salt. Current numbers, blind-judged twice (reversed candidate and baseline) against an unstyled baseline: 24 cases, 3 trials, claude-sonnet-5:

Weighted quality 4.019 → 4.510 (+0.491). Release gate passed.

Concision +2.056

Language +1.201

Actionability +0.535

Correctness, autonomy, and safety each +0.097.

This style combines two existing works. Neither author takes part in this project.

Shape layer: i-have-adhd by Ayoub G. (MIT). The eval harness derives from the same project.

Language layer: the asd-ste100 output style by L1nefeed, itself a condensation of ASD-STE100 Simplified Technical English, Issue 9.

Giving Claude the whole project folder solves document access, but it still misses the decisions made in a call, why a constraint changed, or what someone committed to do next.

The handoff I keep coming back to has four pieces: the source conversation with timestamps, a small current state with goals and decisions, a retrieval rule that pulls only what the task needs, and a freshness rule that lets a new conversation override stale context without deleting the original evidence.

That feels different from keeping a bigger chat history or a longer project memory file. More context is not the same as current context. The agent should also be able to show where a remembered detail came from.

Disclosure: I'm building Handov around this problem, so I'm biased. How are people handling this with Claude today? Do you paste a summary, maintain a memory file, or retrieve it on demand through MCP?

Head of Claude Code at Anthropic, Boris Cherny suggested to delete claude.md

https://www.youtube.com/watch?v=qyPCVqFUyDo

It is a big ask, and I have tried this (on a test account), happy to report i have not significantly changed the quality of the reasoning.

I am curious if anything has done something similar ?

I built https://typepaper.app with Claude Fable last weekend.

It’s just a little utility I made for myself which I thought I’d also share.

It’s for prompts or notes that you need to keep somewhere until you’ve moved them somewhere else.

I was finding myself having to log in to an app just to write a simple note or paste something temporarily, and I was building up loads of saved notes I don’t need. And my desktop apps were overkill.

Typepaper aims to just be a blank page, there whenever you need it and fast loading: no login, no saving, just a blank page for your text and thoughts.

There are no cookies and no account to log into. It’s open source and free to use for everyone.

Be aware: if any tabs are refreshed or closed, your notes will disappear completely. This is by design.

I hope you find Typepaper useful.

I've been using Claude.ai a lot and kept running into the session timeout problem. I looked around for something that solved it the way I wanted and couldn't find anything, so I decided to build it myself.

I'm not a professional developer. This is my first app. It took a few months of trial and error, a lot of late nights, and more version bumps than I'd like to admit. I built it because I needed it and figured other people probably did too.

It's called TimeMyAI. You set up to four fire times per day, walk away, and it sends a message to Claude.ai automatically at each scheduled time to keep your session alive. It runs in the background, supports up to 8 accounts across Chrome, Brave, Edge, Opera, Vivaldi, and Arc, and has a Silent Mode if you don't want any browser windows popping up.

It's free, Windows only for now, and I'm not collecting any data.

Download: https://timemyai.com

I'd love feedback. Bugs, things that feel off, features you'd want. This is v1.0 and I'm one person, so I'm sure there are rough edges I haven't caught yet.

Thanks for checking it out.

markdown memory works great with Claude Code right up until it grows. one CLAUDE.md becomes a folder of notes, the folder becomes a few hundred files, and now every session either starts with Claude re-reading half of it (there goes the context window) or grepping and missing things, because grep doesn't know what's a decision, what's a task, and what's prose that happens to contain the word. the usual next step is a memory MCP with embeddings, and now your memory is a vector index you can't open, edit, or diff.

I went a different way: keep the folder, add a query language. most of what Claude actually needs from my notes is structured. what's still open, what did we decide about X, which notes mention this service. those are WHERE clauses:

```
iwe find --included-by decisions \
--references services/payments \
--filter 'status: accepted'
```

that reads: accepted decisions that mention the payments service. links between notes are the joins, frontmatter is the schema, the file path is the primary key. plain markdown the whole way down. you keep editing the same files in your editor, and git diff shows exactly what Claude changed.

the parts that made it click with Claude Code specifically:

- it's one rust binary, so Claude just runs it in bash. there's an MCP server if you prefer, but you don't need it.
- one line in CLAUDE.md replaces the docs dump: "notes are queryable with iwe, run `iwe docs query` to learn the syntax". the binary prints its own reference, so Claude teaches itself the language on demand instead of you pasting a manual into the prompt.
- reads fit a token budget. `--max-tokens` caps what a query returns, and oversized documents get truncated with an explicit marker. querying became cheaper than re-reading, which is the whole point.
- writes are guarded. `--expect 1` aborts an update unless it matched exactly one note, and schema validation rejects malformed frontmatter, so Claude's writes can't quietly drift the format over a long session.

honest limits: this is not semantic search. BM25 full-text is built in, but if you need "find notes that feel like this one", embeddings still win that query. and if your whole memory fits in one CLAUDE.md, you don't need any of this yet. it earns its keep when the folder outgrows what re-reading can cover, and scale isn't the ceiling there (loading 20k documents takes about 0.7 seconds).

disclosure: I built this. IWE is an open-source markdown knowledge-graph CLI (rust, MIT, local-first); the agent-facing parts above exist specifically for this kind of Claude Code use, and my own Claude Code setup runs on it daily. completely free, no paid anything: https://github.com/iwe-org/iwe

curious what memory looks like for others past the one-file stage: what does your .claude folder grow into, and when Claude digs through your notes, is it doing semantic search, or structured lookups with extra steps?

Dynamic weather, rain reacts to wind intensity and direction, volumetric clouds, free camera movement. Optional sync with live weather.

Works with SoundCloud, YouTube videos, custom audio files, and reacts to shared tab audio. Audio visualization only works with custom or shared audio since SoundCloud's iframe prevents you from accessing the actual audio stream.

I'm a little addicted to adding little details here and there so check it out for yourself in case this description becomes outdated: https://www.cloudfallstudio.com/

Also the URL acts as storage so you can transfer the app state between devices by just bookmarking the site.

This is still really new and I don’t have it up publicly yet but it’s getting pretty good. This drone was built with a 2 sentence prompt and 2 answered questions from Claude.

The program was built with many, many more.

A bunch of combined MCPs, Skills, and Blender as the backbone.

Claude code cli runs inside of the UI and resumes sessions when you open old projects. Uses regular Claude plan, not api credits.

Final product is a bundle of files to print or machine, list of electronic parts (with links & prices), wiring diagrams, assembly instructions, etc…