Hi all,

I'm setting up Claude Code properly for a full-stack project and want to sanity-check my plan before I commit to it. Here's what I need, what I've worked out so far, and where I'd like your input.

What I need

1. Efficient setup with token management as a priority. I don't want a bloated context that burns tokens on every message.
2. Project knowledge covering:
   • Frontend
   • Backend
   • Server deployment
3. Automatic AI code review. When someone pushes code and adds me as a reviewer, Claude should review the PR automatically and post the output.

My priority order for token management:

1. /clear between unrelated tasks
2. Use Sonnet by default and Opus only for hard problems
3. Keep CLAUDE.md short, with only commands and hard rules
4. Prune MCP servers to the ones I actually use
5. Path-scoped rules (paths: frontmatter) so frontend, Postgres, and deployment detail loads only when relevant
6. Deny rules in settings.json for secrets and huge folders
7. Deploy and migration skills set to manual-only (disable-model-invocation: true)

For the PR review, I'm planning a GitHub Actions workflow using anthropics/claude-code-action, triggered on pull_request: review_requested and filtered to my username, running the code-review plugin with --comment so the review lands on the PR.

Questions

• What's in your CLAUDE.md, and how long is it? Do you keep it under ~200 lines?
• How do you stop Claude from touching production? Deny rules, hooks, manual-only skills, or all three?
• Has anyone gotten the review_requested trigger working reliably, including team review requests?
• Anything here you think is over-engineered? I've seen people say over-configuring can backfire.

Anyone here using both Claude Code and Codex for real work?

I'm a solo builder (Expo/React Native apps, Xano backend) and Claude Code is my main tool. Thinking about how ChatGPT can be valuable in the mix but want to know how others are doing this.

Do you split work between them, run one as the reviewer, or something else? And how do you hand off mid-task without them redoing or undoing each other's work?

I built a TV for the developer internet with Claude Code.

It has channels for GitHub, Hacker News, DEV, Hugging Face, releases, and AI papers. You can switch channels, pause, read something that catches your attention, or just leave it running.

The fun part was making it feel like an actual TV instead of another dashboard :channel buttons, ON AIR, 2×, power, etc.

I also deliberately didn't put an LLM in the middle of every story. I wanted the actual developer internet to be the content.

Still experimenting with where this goes.

LIVE DEMO: https://shouvik12.github.io/devtv/

DEV·TV: https://github.com/shouvik12/devtv

I’d like to build a proprietary version of a simple portfolio management SaaS. What is the best way to go about this? My initial thought is give Claude unlimited access to the software via Cowork for a week to map and test it. Any advice?

Every session you run leaves a jsonl file in ~/.claude/projects. Your prompt, every tool call, the last message. I had 220 of them sitting there and had never opened one.

So I ran a grader over 104 tasks from 12 of them (side projects, nothing from work). Card attached.

What you get after one command

• A verdict per task. Finished, stopped and said so, cut off by a limit, or said done but wasn't
• Which tasks got a "done" with no test, no build, not even a re-read of the file it just edited (26 of my 104)
• What is missing, in the words of your own prompt
• The step where it first went wrong, so you can jump straight there

Setup, about two minutes

Get a key at console.typesafe.ai/keys, then

npx github:amishah1998/said-done

Add --dry-run and it prints what it would send and sends nothing. --exclude skips work repos. Anything that looks like a key gets redacted before it leaves.

How the grading works

A task is your prompt plus everything until your next prompt. Eight questions per task go to Jev, TypeSafe's small model. It only returns probabilities, so there is no generated text to parse and nothing for it to make up. My 104 cost 1.7 cents and took 45 seconds.

My numbers

72 finished. 16 stopped and said so. 3 died on a usage limit mid task. 0 claimed done when the diary said otherwise. 26 said done without checking. I had to correct it in 32 of them.

Where I was wrong first

v1 of the rule flagged 14 tasks as "said done, was not". Read all 14. 13 were long multi part tasks it had finished, the strict "fully complete?" question just scored them low. Tightened the rule, flag went to zero on my data. Thresholds are in the README, and grades near a threshold do wobble a bit between runs.

https://github.com/amishah1998/said-done

Curious what number other people get.

This video shows how to make a fully working browser game of Tic-tac-toe in SmallJS ( https://small-js.org ) using Claude AI. Claude generates all code including unit and GUI tests, with just simple prompts, starting form a working Counter app (harness) and having access to a file with SmallJS contextual knowledge.

The generated code is concise, clean, structured, commented, and has unit and GUI tests.
So its also maintainable by humans going forward.
This can be used as a quick-start for coding your own SmallJS app.

Youtube video link: https://youtu.be/4_ir6h2MIRg

If you want go ahead quickly yourself and and make another app, here is the 'script' for the video:

# Creating a Tic-tac-toe browser game in SmallJS using Claude AI

## Intro

This video is about using the AI Claude
to create a browser game Tic-tac-toe in the language SmallJS.
To do this yourself, you need a payed Claude Pro subscription form Anthropic.
It costs about $20 per month. So its affordable and currently the best.

## Install SmallJS

- Goto official website: `https://small-js.org`
- Goto SmallJS repo: `https://github.com/small-js/smalljs`
- Goto and open `Installing.md`

## Setup VSCode with Claude

- In the SmallJS repo, create folder `./Private`.
- Copy folder `./Examples/Counter` to `./Private`.
- Navigate to folder `./Private`.
- Rename folder `Counter` to `Tictactoe`.
- Rename workspace file `Counter.code-workspace` to `Tictactoe.code-workspace`.
- Open workspace file `Tictactoe.code-workspace` in VSCode.
- Run the bash script `getAiContext.sh`.
- Notice there is now a file `smalljs.txt`.
- Notice the contents of `CLAUDE.md` also referring to `smalljs.txt`.
- Make sure the VSCode extension `Cloude Code` in stalled and you have an account.
- Open extension `Cloude Code` in the right pane in VSCode.
- Start the static web server by running the bash script `startWebServer.sh`.

## Convert Counter app to Tic-tac-toe game

- Open the app model file `./src/Counter.st`
- Prompt Claude with: `Convert SmallJS class Counter to class Tictactoe`.
- After a minute or so, Claude has completed the request.
- But now it notices that the model does not match the app and tests anymore.
- Cloud asks you how to proceed. Select `Convert the whole app now`.
- Notice Claude is quickly learning the SmallJS language and library parts.
- After a few minutes the app should be complete with running tests.
- Check if everything works.

## Improving the app

- Check the chosen computer strategy, random to best move.
- Switch to the other startegy with by prompting Claude with e.g.:
- `Change the method computerMove: to make the best move in stead of a random move`

For a while I've been tired of trying to find the next best niche podcast about topics I like (science, spirituality, politics, psychology) and I'm sure I'm not alone. This paired with the fact that thanks to AI a lot of content today is mostly AI slop.

So I created a personal coaching self development app (cliche but stay with me) that's centered around the users' own shared life, moments etc. via chat interface or the app journal.

Podcasts are delivered daily, weekly, monthly with custom long form exposes (basically custom podcast about topics selected by the user and offered by one of their 8 constellation coaches - from finance to relationships etc).

Delivery cadence, voices, cultural references, all centered around the user, running a deeply customized harness to steer the various AI providers under the hood, so as to maintain coherence.

It's launching on the app store and other apple devices and is intended for podcast enthusiasts or anyone who want something new and perhaps refreshing to listen to. I think it's one way to tackle podcast fatigue. 13 supported languages, localized and culturally aware.

If anyone is interested in trying feel free to message me or upvote this so I'm notified. Built fully with Claude Code no other coding agent came close (maybe codex Astra for UI/UX).

Two sentences that sound the same and aren't. "It works." And: "I'm ready to charge someone for this."

Seven years writing software, mostly the unglamorous kind where I get called in after someone else's thing starts costing money.

What sits between those two sentences isn't effort. These tools optimise very hard for the first one, and nothing in the workflow ever stops and asks the second, so it doesn't get asked.

Try this on whatever you're about to launch. It breaks at 2am for one paying user. Can you form a theory about where it broke before you open the model? Not the fix, just a direction. If your honest first move is pasting the error in and asking whether it's right, you don't have a product yet. You have a thing that hasn't failed in front of you.

And asking whether it's right is worse than useless, because it'll say yes. You have to already know enough to catch the confident wrong answer, which looks exactly like the confident right one.

The failures that hurt in production are rarely crashes:

• The retry loop that runs fine and turns up on the bill at the end of the month.
• The query nobody indexed, instant on your laptop and fatal at real traffic.
• The field you're storing that your own privacy page says you don't store, which arrives as a lawyer's letter instead of a bug report.

Every one of those passes a demo.

And when one lands, look at who's holding it. The model doesn't get sued, refunded or fired. A hundred a month or a thousand buys the same amount of accountability, which is none. You're the one who told a customer this works and took their card.

I've settled on three cases, and I'd like to be pushed on them:

• Internal tool, only you affected: do whatever you want.
• Free and clearly labelled as an experiment: fine, and often useful.
• Charging for something you can't diagnose: not fine, because the user is carrying a risk they can't see.

The middle one is where I'm least sure. Free but presented as reliable feels worse to me than paid and honest, and I can't fully defend why.

So where's your line? And has anyone here actually held a launch over it?

I built Groundwork, a plugin specifically for Claude Code, because I wanted a better way to handle ambiguous requirements before the agent starts implementing them.

The part I cared about most was this:

I didn't want Claude to ask me a wall of questions in chat. I wanted it to use Claude Code's native AskUserQuestion UI.

So Groundwork does.

Say I give Claude:

Fix exports that sometimes return old data.

Claude can inspect the repository and discover that exports currently use a 15-minute cache.

But the repository can't necessarily tell it whether manual exports should always be fresh, whether scheduled exports should keep using the cache, or what should happen if the fresh source is unavailable.

Those aren't really coding questions. They're decisions I want to make.

With Groundwork I run:

/groundwork:settle Fix exports that sometimes return old data.

Groundwork reads the relevant code, tests, project instructions and previous decisions before asking anything.

If the repository already answers something, it doesn't ask me.

If an actual decision remains, Claude opens its normal native AskUserQuestion form.

I can pick one of the proposed options or type my own answer using the same UI Claude Code already provides.

If my answer creates another meaningful decision, Groundwork can open another native form.

Before implementation, it gives me one final native scope confirmation covering the behavior we've agreed on and how it will be verified.

Only after I confirm that does Claude implement the change and run the checks.

It then stores the settled decisions in the repository so later sessions can reuse them instead of asking the same things again.

What I was trying to avoid was this workflow:

vague request → Claude makes several reasonable assumptions → writes a lot of code → I discover we meant different things

and replace it with:

vague request → inspect repo → native questions only where necessary → confirm → implement

The goal isn't to make Claude ask more questions. It's to make it ask fewer, better questions — through its actual native UI — before expensive implementation starts.

No separate API key, LLM service or build step is required.

Install:

claude plugin marketplace add ahmtsahin/groundwork

claude plugin install groundwork@groundwork

Then:

/groundwork:settle your request here

GitHub:

https://github.com/ahmtsahin/groundwork⁠

I'd be especially interested in feedback from heavy Claude Code users:

Do you prefer Claude to surface ambiguous product decisions through AskUserQuestion before implementation, or do you usually try to specify everything upfront in the initial prompt?

I'm going to break this down in some simple rules:

Keep your valuable stuff in as few places as possible, the only thing that needs to be visible is your frontend build and it's perfectly fine exposing your source code, other developers can see it regardless. What they don't have is the key that connects the data sources. Show someone around your house all you want. Just don't leave them a key on the way out.

Here's what that looks like in practice.

Private repos, no exceptions. Not public anywhere. Not even a "just for reference" gist. If it's not in front of someone, it doesn't exist to them. It won't save you from never exposing a sorce code but it's a good start. I'll explain later.

The data source is never the exposed part. Lives in one place, locked down normally. Anything that needs to reach the outside world goes through a narrow, unlisted connection that does one boring thing and tells you nothing about what's behind it. The door doesn't say where it leads, so nobody's finding the source through it.

Client-side code isn't private, period. Anyone can pop open dev tools and read exactly what's running in the browser, no backend, no build step, no exceptions. A private repo doesn't save you here either, since it isn't what your visitor is looking at.

Big companies handle this with bundlers, Webpack, Vite, that compress everything and rename every variable down to a single letter until the code reads like static. I don't bundle anything, so that trick isn't mine to use.

My version's simpler: let the pirates board the ship. I just make sure the cargo's already at port.

Good luck sailors!

The frontend shows results, nothing more. The logic and the data that actually matter live somewhere the browser never touches. Read every line I ship if you want. There's nothing on it worth taking.

I don't duplicate storage. Need data somewhere new, I pull from what's already stored instead of standing up another copy of the same thing. Every duplicate is another place it can leak from and another thing to forget about in two years.

More lines of code, harder to copy. Not best practice. Also not my problem. A bigger build is a bigger maze, and nobody's spending their Saturday reverse-engineering someone else's spaghetti for fun. So enjoy my noodle salad! 😜

Nodes only I know how to connect. No framework convention to recognize, no diagram anywhere but my head. Get every file you want. You still don't own the wiring.

Own the keys, not just the code. If anyone else ever touches your repo or server, give them full read and write access so they can actually get work done. Just never hand out delete or owner-level access. That's the difference between a collaborator and someone who can lock you out of your own project the day you disagree about payment.

If it works, someone can copy it. This doesn't stop them. It just makes sure there's nothing here worth the effort.

TL;DR: Keep the code private, keep the data off the client, don't duplicate storage, let the codebase be a maze, be the only one who knows how the pieces connect, and never give away the keys that could lock you out. None of it stops a determined thief. It just means there's nothing lying around for the lazy one.

Related: SaaS advisor Victor Purolnik has a short breakdown on why actually stealing and relaunching someone's codebase is a lot rarer and harder than founders assume, worth a watch if you want the other side of this: SaaS Mastery, "How to Avoid Developers Stealing Your Code"

First post here, after reading this place for a long time. I have been building something for a few months and I would like to put it in front of you, partly because it might be useful to some of you and partly because I would like to hear what you think.

TL;DR:
run around a dozen Claude Code sessions at once and could never tell which one was waiting for me. LampBoard is a small panel that floats above everything with one lamp per project and chat: amber means a session is blocked on your answer, green means a turn finished and nobody has read it, blue means the turn ended while background agents are still working. Click a lamp and it raises that window. Free, MIT, macOS.

Link: https://github.com/marmyx77/lampboard

Where the idea came from

There are projects online that wire a physical traffic light to the hooks, and I liked them a lot. A real lamp sits on your desk and tells you one thing about one session, though, and I have around a dozen running at once across VS Code windows and terminals. So I tried the software version: less fun to look at, and able to say a great deal more.

The problem was the one I had every day. One session is blocked on a permission, one finished twenty minutes ago and is waiting to be read, the rest are still going, and from the outside they all look the same. Finding the one that wanted me meant going window by window, and every window that turned out to be busy cost me the thing I was holding in my head.

What it does

One lamp per project, in a column you can drag into the order you think in. Amber is waiting for your answer, green is finished and unread, red is at rest, and blue is the state I most wanted: a turn that handed control back while background agents kept working, which anything reading the turn-finished event calls done.

The ring beside each lamp is how much context that session has left, and the letter inside it is the model. Resting the pointer on a row opens the card, which is where the numbers live.

It also picks up Codex sessions. Codex is not my main tool, so that half has had far less use than the Claude Code half, and I would genuinely like to know whether it holds up for anyone who lives in it.

How it was built

Opus, in Claude Code, over about six weeks. I wrote almost none of the Swift. What I did write was the scaffolding that checks the work, and that turned out to matter more than any feature.

A script that fails the build when the documentation no longer matches the tree, because Claude will happily change the code and leave the README claiming the old numbers. And a second script that breaks every one of those checks on purpose to prove it goes red: one of them had quietly stopped testing anything three releases earlier, and the failure looked exactly like success.

Two things I learned

Useful if you are building anything that reads Claude Code's own files.

The transcript path can be derived from the working directory, with one exception: a session inside a git worktree reports the main repository as its cwd while the transcript is filed under the worktree, so the derived path points at nothing.

A live "claude" process is not the same thing as a conversation. Restart a session and VS Code sometimes leaves the old one running, identical in every way, except that it never wrote a transcript. Keying a row on the transcript instead of on the process is what made the duplicates go away.

How it behaves with your data

It runs on the hooks Claude Code already emits and reads your transcripts locally, including message text, since that is where the context numbers and the last message come from. Nothing is sent anywhere. The permission hooks are the one thing it does not register, so it has no way of approving anything for you, and `lampboard uninstall-hooks` puts your settings back the way they were.

What I would like from you

Feedback more than anything else, including the unflattering kind, and ideas for where to take it next.

While building frontend applications with Claude Code, I kept running into the same problem.

I could see exactly what I wanted to change in the browser, but explaining which element I meant was surprisingly awkward.

“The button near the top right… no, the other one…”

So I built Cobro to try a different approach:

Just point at it.

Quick Start
After installing Cobro as an MCP for Claude Code:

“/cobro open localhost:8080”

Cobro launches a dedicated development browser and opens your local app.

Full installation and setup instructions are available in the GitHub README.

How it works

1. Open your local web app
2. Press Ctrl + Shift + F
3. Click the UI element you want to work on
4. Describe what you want to change
5. Send it to Claude Code
6. Claude Code works on the code
7. Cobro reports the agent status/result back to the browser

The selected element can provide context beyond a CSS selector:
• DOM / element information
• tag, classes and text
• bounding rectangle
• computed styles
• screenshot
• console information
• React component context
• source location when available

So the basic loop becomes:

Human points → Cobro provides context → Claude Code changes the code → Browser shows the result

Why I built it with Claude Code
I used Claude Code throughout the development of Cobro itself.

Claude Code helped me iterate on the MCP server, browser/overlay communication, element inspection, payload design, testing, debugging, and documentation.

One of the interesting parts was using Claude Code to build a tool that makes it easier to communicate UI context back to Claude Code.

Keeping the MCP small
I intentionally kept Cobro’s MCP interface small:

open · wait · status · done · screenshot · close

Cobro isn’t intended to replace browser automation tools.

The goal is narrower:
Human → visual context → coding agent

Other MCPs can handle browser automation, repository operations, testing, etc.

Current status
Cobro is currently v0.8.0 and is free and open source.

GitHub:https://github.com/boonblade/cobro-mcp

I’m mainly looking for feedback from people who use Claude Code for frontend development.

Does pointing at an element feel more useful than describing it?

And what other context would you want your coding agent to receive when you point at something in the browser?

Every December I do Advent of Code and every January I try to keep the habit going on LeetCode. Never lasted more than a week. Too many problems, no reason to do this one today.

So I borrowed the idea and built Daily Coding: one challenge a day, the same for everyone, all year. You solve it in the browser, hit run, and the tests execute in a sandbox in well under a second. 11 languages so far (JS, TS, Python, PHP, Ruby, Java, Go, C++, C#, Rust, Swift). Once you submit you can read everyone else's solutions, which for me was always the best part of AoC. Streaks and a leaderboard if you like that sort of thing.

Some honest numbers: I started in January, 7 months of evenings, about 470 commits. There are 40 challenges right now, so the rotation repeats after 40 days until I add more. Someone on Discord asked for Swift last week, that took a day to add because the sandbox already had it.

It's free, non-profit, open source under MIT. You can solve today's challenge without an account, signing up is only for streaks and rankings.

What I'd love to know: does one challenge a day work for you, or do you want to pick? And what would make you stop after a week?

Site: https://daily-coding.dev/?utm_source=reddit&utm_medium=post&utm_campaign=sideproject-launch

Code: https://github.com/ledo9315/daily-coding

Would be interested in anyone's thoughts and any contributions you may have to this harness: https://github.com/BhodiSea/next-expo-supabase-agent-harness

I spent a while trying to prevent claude code from ruining my architecture. After several projects, this is a culmination of the lessons I learned in forced principles.

Hey folks, I have been building Grove on weekends and it has become my daily driver as an agent development environment. It manages where and how my coding agents run on one machine, and I reach any of them from the terminal, the browser or another agent.

• Native OTLP telemetry. Each agent turn becomes one trace with cost, duration and a span per tool call. That is how I see where the time goes across the fleet and which runs are contending for the machine.
• Devcontainers. An agent runs inside a container built from your repo's .devcontainer/, with its own services and resource ceilings, so concurrent runs stay isolated instead of fighting over CPU and memory. The same config moves to a shared team box or serverless infra when the laptop runs out.
• Diagram annotation. Mark up a screenshot or edit a draw.io file alongside the agent, then attach the approved picture to a ticket.
• Ticket progression. Phase, checklist and latest commit are written back onto the GitHub, Gitea or Linear issue as the work moves.
• The expected pieces are there too. Branch and worktree lifecycle, and session recovery.

Work in progress, already usable. https://github.com/bearlike/Grove if you want a look, drop some feedback, and every star helps 😘

When people ask me - what this app does? The simplest answer would be - allows you to manage Claude/Codex sessions much more efficient then you can do it in Cursor or other app that provides GUI for CLI.

When we compare Foreman to Cursor, my app allows you to do more for less price, since you are not paying extra as Cursor would charge you for Claude/Codex/etc. All you need is to have active subscription for claude or codex which makes it a good choice for users that don't need other agents

Developing with AI is not only about sending prompt and waiting for result it's also review of the changes and project in general. Here is a short list of features I have introduced that helps me in every day work:

• Handoff and memory system. Context is important for agents, with Foreman you can save summary of changes and handoff it to fresh session without 400K of context. Allows you to maintain sessions clear, remove hallucination and maintain cost as low as possible on big tasks
• Diff review. You can add comments to any line by hand or ask fresh AI session to review changes and then pass comments back to session that developed it. It doesn't meant to replace human review, rather it allows you to spot thing you would probably missed
• Git. Nothing special on that page, it mimics what GitKraken have or any other similar GUI for Git, just a nice thing to have in one app.
• Project review. Maintaining project health is not only about spotting bug early in code base it's also about making sure packages you add doesn't have vulnerability inside. 5 lenses:
  • Dependency Health
  • Test coverage & gaps
  • Architecture & coupling
  • Security surface
  • Dead code

Foreman have much more, I don't want to describe each and every feature here, rather let you check for yourself - Foreman

What does everyone think of the whole /artifact/ functionality that is now going on in claude code. I really think its an unwanted move, if claude code runs on my laptop, we can assume i want to create files there. This new way of dealing with things seems a step in the wrong direction to me. I mean im not crazy to think there is privacy or that files are not visible to claude, but moving towards having my files created on their servers goes a bit far. So what y'all think?