r/BuildWithClaude

Hi, I made this one. I've played Wordle-likes for years and always wanted to build my own, but I never had an idea that felt like mine.

The push came from a strange place. Half of what I read these days is written by AI, and it's never short. Every email, every doc, twelve words where five would do. At some point I said the phrase out loud, long story short, and realised it was a game.

So: you get a twelve-word sentence. You rephrase it in exactly five of its own words. Real English, same meaning, your job is to work out which words carry the sentence and which are just dressed up to look important. Scoring is Wordle style, blue for right word in the right spot, orange for in the answer but elsewhere, grey for out. Five tries, one sentence a day.

My wife and my brother were the playtesters. An early version let "the" beat proper words in the answer, which felt awful to lose to, so the answers now always favour the concrete word. That one change ate a whole weekend.

I used to give Claude Code a feature request and let it do everything in one pass.

Read the repo, decide on the approach, edit twelve files, install a package, add a migration, and then tell me what it changed.

The result was usually not completely wrong. That was the problem.

It was close enough to take a while to review, but far enough from the original request that I would end up undoing half of it.

So I split the workflow into two separate phases:

Phase 1: plan only.

Phase 2: implement the approved plan.

The first prompt is now:

Plain Text

Do not edit the code yet.

Explore the repository and write PLAN.md with:

the goal
the files you expect to change
the proposed implementation steps
what will not change
new dependencies, if any
database or API changes, if any
tests that should be added or updated
anything you are uncertain about

Do not create files or modify existing files besides PLAN.md. Stop when the plan is complete.

The useful part is not the PLAN.md file itself. It is the point where I can catch a wrong assumption before it turns into a large diff.

For example, Claude might assume that a feature belongs in a new service when the repository already has a pattern for it. Or it might plan to add a dependency for something the project already supports. Or it might interpret “add notifications” as email, when the existing product only has in-app notifications.

Those are cheap mistakes in a plan. They are annoying mistakes after six files have been changed.

Once the plan looks right, I use a second prompt:

Implement PLAN.md one step at a time.

After each step:
Show the files changed.
Run the smallest relevant test or check.
Show the result.
Stop if the scope changes or a new dependency is needed.
Do not continue past an uncertain decision without asking.
I also keep this in CLAUDE.md:

For multi-file work, separate planning from implementation. Do not install dependencies, change schemas, or modify external integrations without calling them out first. If the requested change expands in scope, stop and ask before continuing.

The workflow is simple enough that I do not use it for every typo or one-line fix. It is most useful when the request touches multiple components, data flow, authentication, billing, external APIs, or anything I would not want to review as one giant surprise.

The part I like most is the “what will not change” section. Without it, the agent tends to treat unrelated cleanup as part of the feature. Sometimes the cleanup is good. It is still a separate decision.

A plan does not make Claude correct. It just moves some mistakes to the cheapest part of the process: before the code changes.

How are you handling larger Claude Code tasks? Do you plan first, or do you prefer to let it explore and implement in the same pass?

So a bit of backstory. I've always worked corporate, writing code for other people's stuff. At some point I just wanted to build something that was mine, start to finish, even if small.

The idea came from something dumb honestly. Every single night on the couch, me and my girlfriend, same story, 20 minutes scrolling Netflix trying to agree on something and just giving up. Tried a bunch of apps that were supposed to fix this and they either recommended garbage or just weren't really made for two people deciding together. So I ended up building Dunno. Basic idea is you swipe on movies like Tinder, and when you both like the same one it matches, done, that's your movie. Behind it there's an algorithm trying to actually learn what each person likes instead of just throwing popular stuff at you. Also threw in private lists at some point because a few people kept asking for a way to save stuff for later.

It's out now, both stores, and I wanted to share how things have gone since launch because it's not been a straight line at all.

Marketing has been the hardest part by far. No budget really. What actually worked wasn't ads or posting everywhere myself, it was messaging a couple of movie/cinema content creators and they liked the idea enough to show it to their audience. That's when I started seeing actual users show up, not before.

I also killed the monetization pretty fast. Launched with a Pro tier and ads you could remove with Pro, and it just wasn't worth it, barely made anything and it got in the way more than it helped. So I ripped it out and made everything free. At least for now. And honestly free with no ads is a decent selling point on its own these days anyway.

Nobody warns you about the store setup side of things either. Getting everything configured, the Pro integration, analytics, all of it, is genuinely a nightmare when it's just you. And the second you're selling anything you're signing paperwork you didn't know existed and going through review processes that seem designed for teams with a legal department, not one guy in his room. Android's 14 day closed testing requirement before you can even go live nearly broke me, just waiting around doing nothing useful while the clock ticks.

Then there's the TMDB thing, the movie database I use. If you start making money off an app that uses their data they want you on a commercial license and it's genuinely expensive per month. Between that and ads not really paying off, going free was kind of the obvious move, didn't want a fixed cost like that hanging over me before I even had real users.

And yeah I'll just say it, I used AI to help build part of this. I know that's usually an automatic downvote around here but I reviewed every line, every decision on what the app should actually do was mine, and honestly most of the polish came from just bugging my friends constantly for feedback and going back and forth on tiny details (my girlfriend is genuinely about to leave me over how much time I've dumped into this thing). Not trying to hide that I used it, just being honest about what actually building solo looks like. I get why people are sick of low effort AI slop apps but if you actually know what you're doing with it, it's just another tool. Used lazy it shows immediately. Used with care nobody can tell.

Ask me anything, stack decisions, how I got the creators... whatever.

I kept doing the same annoying thing: start a task in Claude Code, switch to Cursor for something it’s better at, and lose 20 minutes re-explaining what I was doing. So I built Contexo — a small local CLI that sits underneath whatever AI coding tool you’re using.
What it does right now (all free, Apache 2.0, no account):
• contexo handoff <target> — compresses your current session into a Task/Decisions/Changes/Next-step brief and drops it into CLAUDE.md, AGENTS.md, or .cursorrules, so the next tool picks up where you left off.
• contexo estimate — tells you what a prompt will cost before you send it, across every model.
• contexo run -- <agent-cli> — wraps any agent CLI with a hard daily budget cap. Kills the process the moment it crosses your limit instead of finding out tomorrow.
• contexo mcp — same features exposed as an MCP server if you’d rather wire it into Claude Code/Cursor directly.
Everything runs 100% on your machine, SQLite locally, your own API key. Nothing phones home.
It’s early and rough in places. I’d genuinely like people who run Claude Code / Cursor / Codex regularly to install it, try the handoff + budget cap on a real session, and tell me what breaks or feels wrong before I build anything further on top of it.
Not on npm yet, so for now:

git clone https://github.com/maheedhar132/Contexo.git
cd Contexo
npm install && npm run build
npm link

GitHub: https://github.com/maheedhar132/Contexo
Specific things I’d love feedback on:
• Does the compressed handoff actually capture enough for the next tool to pick up cleanly, or does it lose too much?
• Any agent CLI where the budget-cap cost detection doesn’t work (it scans stdout for $X.XX patterns — some CLIs may format cost differently)?
• Anything that felt confusing in the first 60 seconds of using it?
Happy to answer questions here or take issues/PRs on GitHub.

For me and my team, HTML is a new type of doc we collaborate on now - reports, slides, designs, mini apps, etc.

While Claude can share it as an artifact, it’s not so friendly for other agents and Google drive is also very hard with HTML.

How do you share HTML?

Anthropic documents that Claude marks its output: C2PA on files, plus a model-level text watermark. Their help center even says proofreading can stamp human-written text.

So I set up an open-source tool as a Claude Code skill and asked Claude to strip Claude's marks from my own files. Worked in one conversation. It also catches invisible Unicode (zero-width spaces etc.) and metadata from ~30 other AI tools: ChatGPT, Midjourney, Cursor, Gemini, Stable Diffusion.

Try it on a file you think is clean:

git clone https://github.com/haidrrrry/claude-watermark-remover.git

cd claude-watermark-remover

python3 service/scripts/inspect_file.py yourfile.md

It prints exactly which hidden characters and metadata are in there. One more command removes them. Python stdlib only, nothing uploaded.

Honest limits: metadata and invisible characters strip verifiably. The statistical watermark in word choice can only be rewritten, not deleted, and no tool can promise otherwise.

MIT fork of watermarks-remover, extended with the Claude Code skill and wider detection. Feedback welcome, especially false positives.

I’ve been contributing on MARGINAL, an open-source governance layer for coding agents. Claude Code support just landed, and I’d really appreciate people trying it on real work and telling me where the design is wrong.

I’m especially interested in technical criticism, bad cases, and reproducible failures.

• GitHub: https://github.com/SignalLayerLabs/Marginal
• Site: https://signallayerlabs.github.io/Marginal/

The idea is simple: agents are good at taking actions, but not always good at deciding whether the next action is still worth the compute.

MARGINAL watches the trajectory and records things like repeated actions, unchanged workspace state, weak progress, redundant verification, outcomes, and governance overhead.

For Claude Code specifically, the integration is currently Observe-only. It uses native Claude Code hooks, writes recommendations to a local Decision Ledger, and does not block tools, rewrite arguments, or inject output back into Claude. If MARGINAL fails, the hook fails open and Claude Code continues normally.

Install:

claude plugin marketplace add SignalLayerLabs/Marginal
claude plugin install marginal-claude-code@marginal

A few core pieces:

• local-first trajectory and evidence tracking
• deterministic reason codes and decision hashes
• engine-declared success/failure from Claude Code hook events
• same-state repetition detection
• governance overhead measurement
• replay and benchmark support
• conservative fail-open behavior
• no fake token accounting when Claude Code doesn’t expose per-tool usage

The larger idea is Earned Enforcement: MARGINAL shouldn’t get permission to block an agent just because it detected a loop. It should first demonstrate that its interventions are actually reliable.

Claude Code is not at that stage yet. Recommendations stay recommendations.

The next layer I’m working toward is counterfactual evaluation and intervention regret:

Would Claude Code actually have done better if MARGINAL had stayed out of the way?

That’s the question I think matters if this is going to become something more useful than another loop detector or token limiter.

If you run Claude Code heavily, I’d be interested in the cases where MARGINAL completely misunderstands what the agent is doing.

Something I kept running into building agent tooling: giving an agent an MCP

tool that *could* answer a question about the codebase doesn't mean it will.

Tool-call decisions are probabilistic, not guaranteed. The agent has to

recognize it needs the tool, remember it exists, and choose to call it over

just grepping. A lot of "codebase context" products are architected as

exactly that: an MCP server sitting in the tool list, unused more often than

not.

Graft's bet is different: don't wait to be asked. It hooks directly into

Claude Code. The matching nodes get pulled into every prompt automatically,

editing a file surfaces its dependents inline, and the graph re-syncs itself

in the background after every edit, all without the agent deciding to invoke

anything. Same reason Chrome doesn't ship with an ad blocker built in: the

core stays general, and the extension handles the specialized job. Graft is

that extension for context.

Underneath, it's a typed graph, not a vector index: tree-sitter builds a

deterministic per-symbol graph (no model call), and an optional `--deep` LLM

pass groups that into markdown nodes with typed links (`depends_on`, `uses`,

`produces`) an agent follows like any other file. Method calls resolve

through the receiver's type (constructor assignments and type annotations,

not just call-site name matching), so a common method name doesn't pull back

every unrelated method with that name across the codebase.

The claim: up to 4× cheaper and 3× faster, with better or no loss of

correctness. Setup: 162 runs, two repos (graft itself + a real Node/Express

auth service), 3 trials each, single-file and multi-file questions split

evenly. Three variants of the same Claude Sonnet 5 agent: cold (explores from

zero), push (context bundled up front), pull (MCP tools, nothing injected,

paid for only when asked). A separate Opus 4.8 model graded correctness with

a required-keyword floor, so a fast-but-wrong answer couldn't win by being

fast. Cost is cache-aware (reads ~0.1×, writes 1.25×) to match real billing.

Results: push cut cost 32%, tool calls 46%, latency 60%, at equal correctness

(93% both, no loss). Pull gave up most of the speed but correctness jumped

to 98%, +5 over cold, the "better" half of the claim, and worth noting: pull

*is* the MCP-tool-list approach, and it still worked, because the harness

forced the call. Left to its own judgment across a real session, that's

exactly the discipline that erodes.

Second test, because a benchmark on questions can still be gamed: reset

PocketBase to its base commit before 5 merged PRs, re-implemented each with

and without graft, scored by file-overlap with what the maintainers actually

changed. 5/5 reproduced, at 21% lower cost.

Opensource, MIT licensed

Here's the repo link : https://github.com/NanoNets/Graft

I'm not a developer. For the last few months my entire job has run through Claude Code, and since I can't read the code it writes, I had to find another way to trust what comes out. The same failures kept returning: corrections I'd already made, settled decisions quietly reopened, a confident "done" with nothing behind it.

What it is ballast is the piece of my setup I cleaned up and open-sourced: a goal-completion framework — one hook plus eleven markdown skills. It's packaged as a Claude Code plugin, and because the skills are plain markdown, the same files run on Codex through an AGENTS.md block (conventions only there — more on that below).

The loop, start to finish A goal arrives, and the first move is mobilize: check what the project already holds — standing rules, verified notes, solved procedures — and using what exists is mandatory, not optional.

What's missing gets built, not guessed. The goal skill cuts the goal top-down into a pyramid of atomic pieces — no overlaps, no gaps — then fills them bottom-up, and every piece passes a verify gate before it bears weight: claims stay labeled drafts until they survive refutation against primary sources, with an optional second model configured to argue back. Research can be delegated to any second CLI you point at it, but whatever it returns lands as hearsay and goes through the same gate. The skeleton lives in a file, so the next session picks up the same tree instead of starting over.

Before anything ships, it gets rehearsed: a zero-context reader executes the deliverable and every stall gets fixed — the release this post describes went through that procedure itself, three rounds. Done means a check passed, not "Claude said so".

And what the work settles outlives the session. Decisions go to an append-only ledger, and reversing one means sweeping every surface the old wording still lives on. Verified facts land in a knowledge base that gets read before any new research. Procedures that recurred become skills. Corrections become rules: you correct Claude once — "this repo uses pnpm, npm broke the lockfile twice" — and from then on a hook running on every prompt delivers that rule's full text with any message that matches it. Claude follows it because it arrived with the message, not because it remembered. Coming back after a break is a thirty-second read.

What I have to be straight about Only the hook is code — the eleven skills are markdown conventions that hold exactly as well as the model follows them, and can drift like any prompt (the README labels every piece as code or convention; on Codex there is no hook at all, so everything there is convention).

Claude Code wrote all of it — the hook, the skills, the docs — with me steering. It's free — MIT.

Try it:https://github.com/svy04/ballast— on Claude Code, install is two slash commands: /plugin marketplace add svy04/ballast, then /plugin install ballast@ballast. On Codex, docs/CODEX.md is the wiring guide.

If you know prior art for this loop, open an issue and I'll link it in the README — injecting context on prompt submit is a documented hook pattern, and append-only records are older than software; "I haven't seen the whole loop bundled elsewhere" is the most I can claim. Happy to answer anything about the setup — and if you're a non-developer hitting the same walls, I'd like to hear what breaks first when you try it.

https://reddit.com/link/1vp9h8b/video/7j9jav4z5sjh1/player

Hi everyone. I had zero coding experience before starting this project — a web app for my company (automotive industry): passing work orders between service departments, scheduling vehicle handovers, and managing a car wash (queue scheduling, cost/profit tracking).

**First attempt – ChatGPT:** Built a similar app for fun on a paid plan. It generated .zip file packages I just dropped into a folder. Worked locally, but deployment failed — it used SQLite instead of PostgreSQL, so it couldn't handle concurrent users. Shelved it.

**Second attempt – Claude:** Subscribed (~$25/month). Spent a week planning with Claude: architecture (PostgreSQL, Django, Tailwind + HTMX + Alpine.js), features, module structure, user permissions, org structure, notifications (push + Brevo email), VPS/domain setup, UI direction, data security. This produced a ~1500-line CLAUDE.md meant to guide development.

**Implementation:** Set up GitHub, WSL2 + Docker, VS Code + Claude extension. Skeleton and database went fine. Problems hit once building the first of four modules — token usage exploded. I likely made it worse by pasting VS Code errors into regular chat and copying responses back manually. Burned 100% of my weekly usage in 3 days, left with a barely-functional module stub, then blocked for days.

**Now:** Only after hitting the limit did I research skills, plugins, opening new chats to manage context, and that the terminal apparently works better than the VS Code extension. Wondering if the 1500-line CLAUDE.md itself is part of the problem.

I have a solid functional plan but my motivation has dropped. Questions for those with more experience:

1. Continue fixing the current project, or start over? If rebuilding, how should I approach it?
2. Should documentation be split into a docs folder with separate files per backend/frontend/module, instead of one giant CLAUDE.md?
3. How should CLAUDE.md and project docs be structured to avoid burning tokens so fast?
4. How do skills actually work — added per-project, or can they be set globally in Claude Code?

Any advice appreciated.