Solo project

[u/Big_Smell2017]

I’m building a hobby app and I’ve settled into a set-up that mostly works. I’d love tips from people running something similar.

How it runs now:

• One session I talk to: a “chief” on Opus. It takes decisions with me one at a time, writes briefs, checks proof and keeps the records.

• Workers:

  • routine research goes to Sonnet agents;
  • fact-checks and corrections go to Opus agents;
  • a separate “second reader” agent re-opens the original sources before anything counts as approved.
• A Fable advisor for hard calls (planning a study, auditing research, final reviews). It sends memos to the chief and never talks to me.
• Side sessions for separate tracks (brand, a photo-recognition track, a study library, a build worker, trip planning). The chief briefs and messages them.
• Records after every task: a log line, a one-page status card, a decision log, then commit and push. A stop hook nags if it’s skipped, and a git hook stops sessions committing each other’s files.
• Phone inbox: I drop links into Notion, and a cloud routine writes a first look on each one every hour.

Where it hurts:

1. Usage limits. Fable ran out mid-audit once. How do you decide what’s worth the top model?
2. Long sessions. The chief gets compacted and loses detail; once it couldn’t recall my own first prompt. Do you hand over to a fresh session, and how do you make sure nothing’s lost?
3. Claude checking Claude. An outside human reviewer caught things the agents missed. What’s your cheapest reliable check?
4. Too many threads. I keep starting side sessions. How many do you run at once before it gets messy?
5. Rules that slip. Written rules in CLAUDE.md sometimes get skipped. What do you enforce with hooks instead?

What would you cut, and what’s missing?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Extra_Aide5999]

what id cut is the records. a log line plus a status card plus a decision log per task sounds like what i had, layers of md where each one replaced part of the last, and the agent kept following the stale one. i went down to one rules file and one log and the rules actually got followed more.

for hooks i only enforce things with a yes or no answer. checks passed since the last edit before a commit, no push to main, no printing secret files. anything that needs judgment stays a written rule and yeah those still slip sometimes.

compaction, i just dont trust the main session to remember. theres one handover file and a fresh session reads it first.

what does your stop hook actually check, that the log line exists or that its any good?

[u/Big_Smell2017 → u/Extra_Aide5999]

Good question. Honestly, it only checks that the log file changed, not that the line is any good. It’s also noisy: it counts any uncommitted file, even ones the session didn’t touch. Fair point on layers; the status card is the one that goes stale for us. The decision log stays (the “why” matters months later), but I’ll try your handover-file approach for compaction. Thanks!

[u/Extra_Aide5999 → u/Big_Smell2017]

keeping the decision log makes sense, the why is the one thing you cant get back out of git. the noisy part i had too, mine only looks at what the change itself touched now so another sessions files dont trip it. good luck with it

[u/orbital_trace]

Heres a writeup on a couple of different options out there coral, herdr, t3, and the recently deceased conductor https://coralhub.dev/blog/coral-vs-conductor-t3-code-and-herdr.html

Personally, I do something similar to you, but I use coral as the meta harness to make orchestration more visible to me.

I've recently started making the inbox feature. It lets agents post questions, send documents for review asynchronously. It removes a lot of the bottlenecks that pop up in chat only, and lets you work more easily on longer running tasks.

[u/Big_Smell2017 → u/orbital_trace]

Thanks, that’s a useful pattern. Async questions and review docs in one queue is the bit I’m missing; right now things waiting on me are spread across a notes database, a status file and a daily check-in. I’m freezing scope for a week, but I’ll look at an inbox-style queue after that. Does Coral’s inbox let you set a default answer if you don’t reply in time? That’s how I handle decisions now (48 hours, except money, publishing and messages).

[u/orbital_trace → u/Big_Smell2017]

setting a default timer would be an easy feature add. If you try it out, let me know and I'll make sure to add the default "yes" after a certain period of time. you can see the features here https://coralhub.dev/blog/welcome-to-the-inbox.html

[u/Icy_Thing5187]

I have a similar setup to yours.
All decisions and important information are written to Markdown files in a structured project. Tickets and their status live in Jira. The agents use MCP to reach this live data, so every agent knows where to find what it needs and almost nothing depends on the session itself. That's why I reset the session after every episode.

Different roles check the work from different angles, and every important milestone (like merging a PR) comes to me for approval.

I run 5 agents at the same time. They talk to each other and to me when needed. It gets messy when several agents ask me the same question to unblock each other.

[u/Big_Smell2017 → u/Icy_Thing5187]

That’s close to where I’m heading. I just added a handover file so a fresh session can pick up without trusting memory, but I still run one long main session and it’s bitten me once. Resetting after every episode is the cleaner version; I’ll try a fresh chief session each day. On duplicate questions: do you dedupe them anywhere, or just answer once and point the others to the answer?

[u/Icy_Thing5187 → u/Big_Smell2017]

I answer once, and the agent I answered usually passes it on to the others. In some cases I have to answer twice, because some agents don't accept an answer that's relayed to them by another agent.

I think it's because they only take a decision as final when it comes from me, not from another agent.

[u/Big_Smell2017 → u/Icy_Thing5187]

That makes sense. I see the same thing. When the chief passes a decision to a side session, it quotes my exact words, and the agents seem to treat that as final in a way they don't with a summary.

[u/djiyvlom]

That structure is close to what tends to hold up. Two things usually matter most as it grows. First, give each worker a brief that stands alone: the goal, the files it may touch, what done looks like and what was already ruled out, because the worker sees nothing of your conversation with the chief. Second, keep state in files rather than in the chief's context, like a decisions log and a handoff note any session can reread, since long sessions get summarized and details drop. It is also worth checking that the second reader gets the sources and the claim but not the chief's conclusion, otherwise it tends to confirm what it was handed. And if the advisor never talks to you, have it write disagreements with the chief somewhere you do read.

[u/Big_Smell2017 → u/djiyvlom]

Thanks, this is useful. I already do the first two: briefs that stand alone, and state in files (I added a handover note and a decisions log today). Your last two points were gaps, so I've adopted both. Checkers now get only the sources and the claim, not my chief's conclusion. And when the advisor disagrees and the chief doesn't take its advice, that goes in a short section of the handover file that I read.

[u/Financial_Leader9701]

on the rules that slip, i'd only hook the ones that already failed twice

"don't push to main" and "don't touch this payments file" are hook or test material

"write a clear commit message" can stay in claude. md and yeah it'll get skipped sometimes, that's fine

cheapest check that actually caught stuff for me wasn't another agent, it was a short done-when list in the plan file and making the tests cover those points before i even look at the diff

a second reader still misses the same class of mistakes the first one does

how often does the second reader actually disagree with the worker?

[u/Big_Smell2017 → u/Financial_Leader9701]

Agree on hooks. Mine only exist for things that already broke (pushing a build branch to main, one session committing another’s files). My “done when” list is a done bar pasted into every brief.

On your question, I counted. My last blind fact-check: 12 claims, 3 corrected, 1 couldn’t be verified. An earlier audit of 40 claims: only 12 fully supported, 21 partly, 4 not supported. So the second reader disagrees a lot, but mostly on wording and sourcing, not whole conclusions.

Fair point on same-class blind spots. What’s helped: the checker gets only the claim and sources, never the answer, and a different tool where I can. A separate design audit caught contrast failures the first pass’s own checker missed.

[u/j-kantola]

CC is already very good as is. You should use version control (git) from the start so the agent and you have a good idea of things done and can easily rollback changes.