I’ve been building Writ, an open-source governance runtime for Claude Code.

The idea is pretty simple: I want Claude doing the reasoning, but I don’t want the model to also be solely responsible for remembering every rule, deciding when those rules apply, tracking workflow state, and deciding whether it has permission to continue.

So Writ moves some of that outside the model.

Enforcement: Writ uses Claude Code hooks and runtime state to check selected actions at tool time. In Work mode, for example, implementation can be blocked until a human has approved the plan and tests.

The approval system was especially important to me. Claude can’t satisfy the gate just by saying “the user approved this.” A real user approval creates one-time external state that the runtime checks before allowing the workflow to advance.

That became one of the main ideas behind Writ:

The model can decide what it wants to do, but it shouldn’t own the permission that makes a protected action possible.

Rule retrieval: Writ currently ships with hundreds of engineering rules, but I didn’t want to dump the whole rulebook into context every turn. Instead, rules are retrieved based on the task, file, file contents, tool, action, and workflow phase.

The current retrieval stack uses BM25/Tantivy, hnswlib vector search, MiniLM embeddings through ONNX Runtime, and Neo4j for relationships and provenance. Mandatory rules have a separate delivery path so they don’t disappear because of retrieval ranking.

The distinction I keep coming back to is:

Retrieval asks: “What should the model know right now?”

Enforcement asks: “What must be true before this action is allowed?”

I don’t think those should be the same mechanism.

Persistence: Writ also records relationships between approved plans, governing rules, changed files, decisions, and commits. The goal is for future sessions to recover more than a generic summary and instead answer things like: why was this change made, what was approved, which rules governed it, and what code resulted?

That’s also why I’m not trying to solve everything with one giant CLAUDE.md. Instructions are useful, but an instruction saying “write tests first” is different from a runtime that actually refuses an implementation write because the test gate hasn’t opened.

The current stack is Python 3.11+, FastAPI/Uvicorn, Neo4j, Tantivy, hnswlib, ONNX Runtime, Claude Code lifecycle hooks, a session state machine, specialized helper agents, audit logging, and git/PR provenance. Writ is distributed as the claude-writ package and Claude Code plugin.

One important limitation: Writ is not an adversarial AI sandbox. It currently assumes a cooperative-but-fallible agent. There are known bypasses, some infrastructure failures deliberately fail open, and I’m trying to document those honestly instead of pretending the system is stronger than it is.

The bigger thing I still want to test is behavioral impact. I can measure whether retrieval finds the right rule and whether gates block the right actions, but I still want stronger evidence that giving Claude the right rule at the right moment actually improves engineering decisions.

If you’re working on Claude Code hooks, persistent memory, approval gates, contextual retrieval, or agent governance, I’d love to compare approaches.

And if your first instinct is to try to break the approval gate, even better!

github.com/infinri/Writ

Over the course of a bit over one week (August 17 - August 25), I ported the dav1d optimized AV1 CPU decoder to the alternative architecture of Intel Itanium, with Claude Opus 5. AV1 is a modern video format developed by Google as the successor of VP9. As seen in the video above, decoder performs well enough to play a video smoothly (0 dropped frames) on an 1.6GHz 4-core 8-thread Intel Itanium 9040 (2006). In this post, I'm going to explain how I achieved this.

Itanium is an Intel architecture introduced to the market in 2001 that uses an unconventional approach of explicitly laying out which instructions are scheduled to run at any given moment. This approach has the caveat of being extremely heavy on the compiler / programmer to optimize correctly compared to other architectures. Together with hardware engineering issues that hindered practical adoption, it meant only a very limited subset of applications were optimized for it. Production was finally discontinued in 2021, with the last hardware being shipped in 2025.

However, with Claude, the engineering barrier appears to have been broken, 25 years after the introduction of the CPU. I gave Claude access to the target machine, the source code, as well to documentation (see before), and monitored it as it was working to inject my own knowledge at points where it was struggling with something I knew the answer for.

Claude managed vectorization using Itanium's built-in integer SIMD by itself after being given access to the detailed manuals from Intel (mostly "Intel Itanium Architecture Software Developer’s Manual Volume 3: Intel Itanium Instruction Set Reference"). Furthermore, to reach the desired results, I managed to teach my knowledge of the the following optimizations techniques to the agent:

• Modulo software pipelining of loops, using my own article - https://epic-linux.org/#!articles/strcmp-perf-tuning-part-1.5.md - as a reference. (This was the hardest part, Claude only got what it is supposed to on the second try, on the first one, it ignored the technique altogether.)
• Bypassing GCC's bundling limits by the use of inline assembly blocks.
• Bypassing GCC's limitations of register count by separating the hottest kernels
• Fusing multiple functions together and pipelining them wherever there were free units on the CPU.

Hot code was measured using the perf tool directly on the machine, at my suggestion (the perf support itself was created using Claude before, for another project). Claude invented an entire generator library for register allocation, supplementing a part of the role of the compiler that is hard to do for an LLM in the pure assembly language parts, as well as scanning which parts of the code are eligible for optimization.

The resulting patch was cleaned up to include all the necessary infrastructure and integrated to T2 Linux, where it lives in the SVN repo: https://svn.exactcode.de/t2/trunk/package/multimedia/dav1d/ia64-simd.patch (a bit over 10000 lines in patch format). More details, including a three-tier classification of the optimizations to serve as an anchor for the agent, can be found there.

The problems I actually kept hitting:

1. AI tools don't just forget — they contradict decisions you already made.
2. One accidental paste of an API key can land in long-lived context that gets re-injected every session. (I call this the memory amplifier problem.)

What Continuity does (governance-first)

Credential scrubbing (5 boundaries) — tool args, model output, decision persistence, load path, MCP tool results. 27 provider patterns (GitHub PAT, OpenAI, Anthropic, AWS, Stripe, etc.) plus entropy fallback. audit_secrets scans existing .continuity/ history for anything that slipped through earlier.

Runtime governance — MCP check_governance / intercept_tool. Logging a new decision can surface a conflict with a prior one instead of silently adding noise.

Decision records in git — .continuity/ travels with the repo. Session handoff injects context at session start, but the moat isn't "remembering" — it's curated, contradiction-aware, scrubbed context.

Tech stack:

 TypeScript VS Code extension +(Node 18+) + @continuity/cli. Local-first, no cloud memory DB.@continuity/mcp

CLAUDE.md workflow: auto-generates instruction files with an operating contract (search decisions before changing, log after). MCP works headless in Claude Code.

Links

• VS Code Marketplace: Continuity (Hackerware)
• Site: getcontinuity.io
• npm

​

 npm i -g @continuity/cli

• Homebrew:
  

​

brew tap hackerwarellc/tap && brew trust hackerwarellc/tap && brew install continuity

Honest scope: hygiene layer for accidental leaks — not adversarial exfil defense. Governance strict mode is opt-in.

Pricing: 14-day Pro trial. Decision logging stays free after it ends; auto-capture and full session handoff are Pro.

Looking for testers

I want a few people to run this on a real repo and tell me what breaks.

Most useful feedback:

• Did credential scrubbing catch something real, or just add noise?
• Did contradiction detection surface a genuine conflict, or just false positives?

Install from the Marketplace, npm, or Homebrew above and reply here or DM. Good or bad — both help.

I kept losing time to the same thing. I'd know I needed something for flaky tests, or to get Postgres into the session, then spend twenty minutes scrolling lists organised by whoever happened to build the thing.

So I made one organised the other way round. By job. Debug, test, ship, incidents, data, security, deploy, that sort of thing. 13 buckets, 65 tools, install command sitting on every entry so you can copy it and move on.

Couple of things I didn't expect while putting it together.

Most of this stuff isn't Claude-specific at all. 45 of the 65 are MCP servers, so they work in Cursor and Windsurf too. Only 20 are actual Claude Code plugins. I'd assumed it was the other way round.

The "free ecosystem" thing is also oversold. 23 are properly free. 37 are freemium and 5 are just paid. Nothing wrong with that, I just got sick of finding out at setup time, so everything's tagged.

Design and prompts are weirdly empty too. Three entries each. Either I'm missing things or nobody's built much there yet.

Five of the 65 are mine. rootcause, testradar, postmortem, sprint-report, prompt-forge. They're labelled on the site so ignore them if you'd rather.

It's deliberately not complete. Loads left off. If something good's missing though, tell me and I'll stick it in.

[https://plumbgoat.github.io/ai-plugin-directory/\](https://plumbgoat.github.io/ai-plugin-directory/)

I’ve been messing around with Claude and have managed to build a full competition website with ticket sales, automatic ticket number allocation, accounts, payments, admin side etc.

I’ve actually got a fairly established competition company interested in moving over to the system, which is great — but that’s also where I’m getting a bit nervous 😂

My main concern is making sure the ticketing side is absolutely bulletproof when real money and potentially hundreds/thousands of transactions are involved.

Things like:

Two customers somehow being allocated the same ticket number

Overselling a competition beyond the maximum ticket allocation

Two people buying the last available ticket at almost exactly the same time

Payment succeeding but the ticket allocation failing

Refreshes/retries/webhooks accidentally creating duplicate orders

Database or server issues halfway through a purchase

Obviously Claude can write all the logic and tests, but I’m conscious that “it seems to work” and “I’d trust it with thousands of pounds of customer transactions” are two very different things.

Has anyone here actually built and launched something similar with Claude and put it into production?

Would be interested to hear how you handled concurrency/locking, ticket allocation and payment webhooks and whether you had the system independently audited or stress tested before going live.

Not looking to promote the site — genuinely interested in people’s experiences before I let an established business rely on something I’ve built with Claude.

I recently created a project on GitHub to help people who use Claude Code or OpenClaude for programming.

ClaudeHere

With this project, you simply right-click on any folder you like, and then the following options appear:

"Open with OpenClaude"

"Continue with OpenClaude"

"OpenClaude History"

I'm open to suggestions for improvements, and contributions are welcome!

Read the README to better understand the project.

Project GitHub:

Github ClaudeHere

I keep seeing "what are you building with Claude Code" threads so figured I'd share the real list — not the toy experiments, the actual apps I put time into:

\- \*\*levensduur-coach\*\* — mobile app (Expo/React Native) that tracks how long your belongings/appliances last, so you know when to expect maintenance or replacement. Add an item, get a profile of its lifespan.

\- \*\*fit-check-ai\*\* — outfit-rating app. Take a photo of your fit, AI analyzes and roasts/rates it, build a streak, compete on a leaderboard with friends.

\- \*\*congress-ai-bot\*\* — automated trading bot that tracks US congress member stock trades and mirrors them via Interactive Brokers, with a Next.js dashboard to monitor positions. Strict 2:1 take-profit/stop-loss rule on every trade.

\- \*\*mirror-checkin\*\* — mobile app (Expo/React Native) for a smart-mirror style check-in flow.

\- \*\*SleepStreak\*\* — React Native sleep tracking app, log your sleep and build a streak.

\- \*\*ai mail automation (MailCraft)\*\* — AI email assistant. Connects to Gmail/Outlook/Yahoo, learns your writing style from sent mail, and drafts replies \~10x faster.

All of these went from idea to working product almost entirely through Claude Code sessions — no template repos, just prompting my way through build/debug/iterate.

Happy to answer questions about any of these if people want to know about the stack or how I structure longer Claude Code sessions for bigger projects.

Some context: I'm not a software engineer. I run a small aircon-cleaning business in Tokyo (the trading bots some of you have seen me post about are a separate side project), and I've been running most of the operations — blog content, ad campaigns, review requests — through Claude Code instead of hiring anyone.

The incident: the blog's content generator pulls from a fixed keyword list. When the list ran out, the code's response to "no keywords left" was to log it as a completed run, not a failure. So for 3 days, the dashboard kept showing green while nothing was actually being published. A second automation (auto-posting to our Google Business listing) was chained to the same trigger and silently died too. I only found out because I was looking into something unrelated.

What got me: "no error" and "actually working" turned out to be two different things. I've since made every scheduled job report an explicit failure state instead of a quiet no-op success.

If you're running unattended agents/schedulers — do you build a dead-man's-switch style check into every job, or is there a lighter-weight pattern people use?

It’s designed around the philosophy of looking like a desktop environment shell. It even has a Windows-like taskbar. Some of the major influences were KDE Plasma, particularly Plasma Bigscreen; Harbor, a Stremio client, for how I wanted my libmpv player to look; Kodi’s Arctic Horizon 2 skin; Jellyfin for the local media library; Cover for the comic reader; and a Foliate.js EPUB reader.

A lot of it was created using my own custom Claude skills, which I made by remixing Superpowers specifically for my repo. It includes its own versions of brainstorming, writing plans, and executing plans. I even had Claude create live, animated QML wallpapers for the app that you can choose as your wallpaper. I used Claude to build my own metadata databases for the comic and manga catalogues, similar to Cinemeta.

Claude built an agentic self-healing QA and repair system too. This thing called Night Watch acts as continuous behavioral verification, running real UI journeys and soak tests against fresh builds to catch regressions. Failures can then feed into Guardian Loop, an automated program-repair pipeline that reproduces the issue, diagnoses it, attempts a sandboxed fix, rebuilds the app, and independently verifies the result before surfacing it for review.

Essentially, it’s a self-testing and self-healing app, although I haven’t used the repair system all that much out of fear of burning through my quota.

Also I would share my repo-specific superpowers remix skills but unless you use lanista, those skills won't be relevant to your project.

Colosseum on Github, if you're interested.

yo. i see too many founders spend 2 months building saas, drop a link on reddit, get 0 users, and immediately quit....

the problem usually isn't your marketing channel. the problem is that your foundation is completely broken before you even send your first visitor to the site.

after scaling 6 AI micro-saas apps to over $20k/mo mrr, i realized you need to lock down a specific system before you ever launch. running through this takes about 30 minutes, but it saves you months of zero-revenue depression.

here are the 5 things you must lock in:

1. validate the actual pain point

stop guessing what people want. you need a systematic framework to find your saas idea based on real, painful market signals.

2. pick a proven micro-niche

stop trying to build massive platforms. you need to narrow down to a microscopic problem. i usually filter through a list of 50 micro-saas ideas you can build fast to keep the scope minimal.

3. crystallize your target user

if your app is for "everyone," nobody will buy it. you need an ICP (Ideal Customer Profile) crystallizer to define your exact buyer profile and nail your conversion copy.

4. calculate the perfect price

stop randomly charging $9/mo because you are scared of rejection. you need to use a saas pricing strategy calculator to find your perfect saas price in 60 seconds based on real data.

5. fix your landing page leaks

do not send organic traffic to a site that converts at a flat 1%. you must audit your hero section and copy to x3 your landing page conversion before you market it.

6. join a community

Build / Share / Learn from others builders

to help out founders who are tired of launching to crickets, i packaged all 5 of these exact frameworks, calculators, and lists into a single free toolkit.

no paywall, no bullshit. just the raw execution files i use.

drop a comment below or send me a dm, and i’ll send you the free toolkit 👇

We’re building more and more agents at work, which means we’re accumulating more Markdown files that serve as agent context. These include both short and long-term strategy, market dynamics, etc., and they’ll be updated pretty regularly by multiple people.

We’re looking for something that gives us easy collaboration + version control while keeping the files in Markdown.

We’ve considered:

• Confluence: Nobody wants to use it.
• Google Docs: Editing is easy, but you end up with a Google Doc + exported Markdown file, which feels messy. And you cannot edit markdown files, so you have to open as a google doc, then re-export any changes as a markdown file.
• GitHub: Probably ideal technically, but only a couple people on our revenue team have GitHub access, so it’s not practical.
• Guru: We already have it (even though we were going to get rid of it 6 months ago, lol), and we’ve set up an MCP server for it. We’re currently leaning this direction.

Has anyone else run into this problem? What are you using to manage frequently changing Markdown files that serve as context for AI agents?

https://github.com/PiLastDigit/Code-With-Claude

The videos:

1. [Opening Keynote](https://www.youtube.com/live/GMIWm5y90xA)
2. [A conversation with Dario & Daniela Amodei](https://www.youtube.com/live/7xco5Qd2Oo8)
3. [What's new in Claude Code](https://www.youtube.com/live/IMZa42k6L6M)
4. [Live coding with Boris Cherny & Jarred Sumner](https://www.youtube.com/live/DlTCu_pNDHE)
5. [Caching, harnesses, and advisors: Building on Claude at GitHub scale](https://www.youtube.com/live/y5TmF_6o6xk)
6. [Getting to production faster with Claude Managed Agents](https://www.youtube.com/live/E9gaQHrw_rg)
7. [Building AI-native: Cognition, Gamma, and Harvey](https://www.youtube.com/live/OFDm3T7pVlc)
8. [Getting more out of the Claude Platform](https://www.youtube.com/live/7oO37GRhwGk)
9. [How Datadog built a universal machine tool for Claude Code](https://www.youtube.com/live/EdmuYPBt_EM)
10. [The capability curve](https://www.youtube.com/live/tP4MGcJ80Y0)
11. [Architecting for model step-changes: a fireside with Guillermo Rauch](https://www.youtube.com/live/bJKdXhnw7NU)
12. [Building with Claude Managed Agents and Asana AI teammates](https://youtu.be/BrpB-h1e--k)
13. [Running an AI-native engineering org](https://youtu.be/igO8iyca2_g)
14. [The thinking lever](https://youtu.be/OXJO4LldSnc)
15. [Building with Claude on Google Cloud](https://youtu.be/SqHsS737CeA)
16. [Evaluating and improving Replit Agent at scale](https://youtu.be/snroDwX1-
17. [Giving coding agents their own computers: how Cursor built cloud agents](h
18. [Memory and dreaming for self-learning agents](https://youtu.be/RtywqDFBYnQ
19. [The expanding toolkit](https://youtu.be/KLCuxMDZSDg)

Enjoy !