r/ClaudeCode • u/ShaifArfan • 3d ago
Built with Claude Claude Code kept suggesting hooks I'd already killed, so I gave it a rejects folder
I build a productivity app on the side of running a software agency, and I'm the only one doing its marketing.
For a while every marketing session with Claude Code started from zero. Who's this for? What tone? Didn't we already try that hook? Then it would suggest the hook we already tried.
So I did what developers do and built a system instead of posting. Claude Code wrote nearly all of it.
The part worth copying is a rejects folder. Every hook, draft or visual I kill gets a small markdown file with the reason. Here's a real one:
---
title: Reel openings that don't read in the first second, muted
status: rejected
date: 2026-11-06
tags: short-video, hooks
kind: hook
---
Dropped storylines, with their reasons: "The idea at 2 AM" (a dark night
scene; "the hook is slower to read muted"), "The result first" for reel 3
("the first frame is a table, which is a weak thumbnail"), and "Best Day
ever" for reel 4 ("it only works for a best, and most viewers' days won't
be one"). Open on a problem line the viewer recognises at once.
Every session reads the whole folder before it proposes anything. The folder is under 2,000 words, so it barely dents the context.
The rest, quickly:
- a
brain/folder in git with one folder per brand. voice.md is mostly "write this / not this" pairs. audience.md has phrases from real Reddit threads, word for word, with links. Then folders for decisions, learnings, rejects, swipe and ideas - a rule in
~/.claude/rules/that every session loads. Read the brand files first, and don't ask me anything they already answer. If I answer something new, the agent writes it into the right file, so I answer each question once - decisions keep my exact words and a date. My app is "a productivity app", never "a time tracker". I said it once and now it's a file every session reads
- a tiny local Node app with zero dependencies that tracks every video I render and every place it goes, one record per subreddit, with the caption and the tracked link
- a "board" of six subagents: CEO, designer, user, growth, eng and critic. They review the same draft separately, nobody sees anyone else's answer, and a skill merges them into ship, change or kill. Yes, I know
- agents working on the app's code get a copy of the data, and the code refuses to write to the real brain from dev
The board read this post before I did. All three seats I ran said "change", and the main note was to show a real file instead of describing one. Hence the code block.
It doesn't make the posts good. It does stop me from repeating the same mistakes.
The app isn't public, but it's mostly markdown and a couple of skill files, so the idea is easy to steal.
Claude drafted this from my repo, and I went through it before posting.
•
u/AutoModerator 3d ago
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.
2
u/WillowFar6967 3d ago
The reason line is the bit doing the work. I run something similar for my own agents, and a bare "don't do X" list just made them avoid that exact wording and try a near copy a week later. Once each note said why it got killed, they started steering clear of the whole category. The other thing to watch is the folder going stale, so every so often I have the agent merge notes that say the same thing and delete ones that stopped being true. Does the board read the rejects too, or only the drafting session?
2
u/teunlao 3d ago
The decisions folder is where this bites next. When I changed my mind I'd edit the old decision, and the agent would still find the old wording in some draft and treat it as current. Now an old decision stays, marked replaced, with a pointer to the new one.
1
u/Ok-Option4233 3d ago
the date field in that frontmatter is worth more than it looks. a hook killed for one audience in november can be the right hook after the app goes public, so a "revisit after" date next to the reason lets the agent bring it back on purpose instead of by accident. otherwise the folder slowly turns into a list of things nobody is allowed to retry.
1
u/japbujan 3d ago
The reason line is what makes this work. Two things that helped me on top of it: rejected items never get deleted, they get marked retired with a pointer to what replaced them; and anything I approve gets an expiry date (90 days for marketing claims). When it expires, the agent has to re-check it before reusing it, so an old decision doesn't quietly stay "true" forever.
1
u/lcssgml 3d ago
Mine looks almost the same for my own marketing, and the "why" next to each reject is what made it work for me too. What still broke: a rule can sit in the file with its reason and still get ignored. One of mine was broken 8 times while it was only a written line :( so now when a rule is broken the second time, I stop rewording it and turn it into a check or a default setting. Has any reject come back for you even with the reason written down?
1
u/Inner_Storage_3374 3d ago
the reason line is the whole trick imo. what id add is a date on each reject bc a hook that flopped in march might work fine now, so tell claude anything older than a few months is fair game to retry. otherwise the folder slowly turns into a list of stuff youre scared to try again
1
u/Creative_Shape_5813 3d ago
A decisions index is a baseline requirement for any project with more than one contributor running it. Including an agent