Brand-check hook catches forbidden words before they reach a draft
Spacing and font hooks fix layout drift across 40+ templates
A11y and SEO hooks block bad alt text and missing meta
Post-publish verify confirms the live URL renders correctly
Six hooks run on every project I touch. They catch the mistakes I used to find three days later, after a draft was already live. Here is what each one does and the exact failures it stops.
Why Hooks Beat Memory Files
I run a workspace with roughly 130 memory files. Each one holds a rule: brand words to avoid, spacing tokens, font stacks, the way I write meta descriptions. For a while I assumed Claude would just read all of them and behave. It does not work that way. Memory files are reference material, not enforcement. Claude reads what it needs and skips the rest, and the rules it skips are exactly the ones I care about most.
Hooks fix this because they fire on an event whether Claude remembers the rule or not. A hook is a small script that runs before or after a tool call. It does not depend on the model staying focused across a long session. It runs every time, returns a pass or fail, and blocks the action when something is wrong. That difference matters more than it sounds. In a 4 hour session the model will forget a rule it followed perfectly at the start. The hook does not forget.
The other thing hooks give me is a clean failure message. When a brand-check hook blocks a word, it does not just say "no." It says which word, which line, and what to use instead. That turns a vague correction into a one line fix. Over a few hundred edits that adds up to real time saved.
I keep each hook small and single purpose. One hook checks one thing. When a check fails I know exactly which hook fired and why. A giant do-everything hook is harder to debug than the bug it was meant to catch. Six small hooks have caught more real problems than any prompt instruction I have ever written.
If you want the full setup that these hooks sit inside, Claude Blueprint walks through the workspace structure I build on. The hooks below assume that kind of foundation: clear memory files, a defined output format, and a publish step that can be intercepted.
Brand-Check and the Words That Cost Money
The brand-check hook is the one I would never ship without. It reads any text Claude is about to write to a file and scans for a list of forbidden words and phrases. The list is specific to my work: studio name spellings, currency format, banned comparisons, words that leak legal meaning I do not want in a casual blog post.
Here is a real example of what it catches. I format prices as "33 EUR" with a space. The model loves to write currency symbols instead, or stick the symbol after the number. The hook catches every variant and blocks the write until the format is right. Same with em dashes. I do not use them. The model produces them constantly because most training text is full of them. The hook flags every single one and points at the line.
The expensive catches are the legal-adjacent ones. Certain phrases about returns or guarantees carry meaning I am not equipped to make binding in a blog post. The hook holds a list of these and refuses to let them through. I would rather a draft fail a check than publish a sentence that promises something I cannot stand behind.
The list grows over time. Every time I catch a bad word by hand, I add it to the hook so I never catch it by hand again. That is the real value. The hook is a record of every mistake I have made and decided not to repeat. After a year the list has 40-odd entries and it blocks something on roughly one in five drafts.
Setting this up is simple. The hook fires on file write, reads the content, runs a list of pattern matches, and returns a non-zero exit code with a message when one hits. Claude reads the message and fixes the line. No back and forth, no re-prompting. The fix happens inside the same edit cycle. I covered the broader workspace logic in Claude Blueprint, and the brand-check hook is the first thing I add on top of it.
Spacing and Font Hooks Stop Layout Drift
Layout drift is the slow kind of bug. No single edit breaks anything. But across 40 templates and a few hundred small changes, the spacing slowly stops matching. One section uses 24px gaps, another uses 20, a third hardcodes a pixel value that should have been a token. By the time you notice, the fix is a tedious sweep across dozens of files.
The spacing-check hook stops this at the source. It reads any style or markup change and checks margins, padding, and gap values against my approved scale. I use a fixed set of spacing tokens. If a value is not on the scale, the hook flags it. The model is told to use the token name, not a raw pixel value, and the hook enforces it. This sounds rigid. It is, and that is the point. Rigid spacing is what makes a site look like one person built it on purpose rather than forty people patching it at random.
The font-check hook works the same way for type. I have a defined font stack and a defined set of sizes and weights. The hook reads any change that touches typography and confirms it uses the approved values. The classic failure it catches is a stray font-family declaration that the model invents because it seems reasonable in isolation. It is reasonable in isolation. It is wrong in context, because it does not match the other 39 templates.
What I like about these two hooks is that they catch problems a human reviewer almost always misses. Nobody eyeballs a 20px gap and thinks "that should be 24." You only notice when two sections sit next to each other and look slightly off, and by then you have lost the thread of which one is correct. The hook holds the source of truth so I do not have to.
These two together have probably saved me more cleanup work than any other pair. A consistent layout is invisible when it works and glaring when it does not. The hooks keep it invisible.
A11y, SEO, and the Checks Users Actually Feel
The a11y-check hook reads markup and confirms the accessibility basics are present. The single most common thing it catches is missing or lazy alt text. The model will happily write alt="image" or leave it blank, and both are useless. The hook blocks any image without descriptive alt text and any interactive element without an accessible label. It also checks heading order, because skipping from an H2 to an H4 breaks screen reader navigation and the model does this more often than you would expect.
These are not edge cases. Roughly 1 in 5 people use the web in a way that depends on these details: screen readers, keyboard navigation, high contrast modes. A blank alt attribute is a wall for those users. The hook makes the wall impossible to ship.
The SEO-check hook handles the metadata layer. It confirms every page has a title within the length that displays cleanly in search results, a meta description in range, and exactly one H1. It checks that the description is not a duplicate of the title and is not empty. It also flags when an image is large enough to slow the page, because page weight affects how the page ranks and how fast it feels.
The thing both hooks share is that they catch problems no casual review surfaces. A page looks fine in a browser with broken heading order and a missing meta description. It looks fine right up until a screen reader user hits it or a search engine indexes a blank summary. The hooks check the layer humans skip.
I run these on every page write, not just at publish. Catching a missing description while the page is being built costs one line. Catching it after publish means reopening the file, re-running the publish step, and verifying again. For social copy that goes alongside these pages I schedule through Buffer, and the same principle holds: fix the metadata once at the source, not in five places downstream. The earlier the check fires, the cheaper the fix. That is the whole logic of hooks in one sentence.
Post-Publish Verify Closes the Loop
The first five hooks run before something ships. The sixth runs after. The post-publish verify hook fetches the live URL once the publish step completes and confirms the page actually rendered. It checks that the page returns a 200, that the title in the live HTML matches the title I wrote, that the main content is present and not a half-empty template, and that no obvious error string appears in the body.
This hook exists because of a specific failure I kept hitting. The publish step would report success. The file uploaded, the platform accepted it, every local check passed. And the live page was broken anyway, because of a caching issue or a template error that only showed up on render. I would not notice for hours, sometimes days, because nothing told me to look. The success message lied.
Post-publish verify fetches the real page and reads what a real visitor would see. If the title is missing or the body is empty or the response is a 404, the hook fails loudly and I fix it immediately, while I still remember what I changed. The window between "I published" and "I know it worked" went from hours to seconds.
The verification list grows the same way the brand-check list does. Every time a publish fails in a new way, I add a check for that failure. It now confirms structured data is present, that the canonical URL is correct, and that the page is not accidentally set to no-index. Each of those came from a real incident where I shipped something broken and only caught it by luck.
For the storefront side, where pages publish through Shopify, this hook matters even more, because a broken product page is a broken storefront. The verify step gives me one honest answer to one question: is the thing I published actually live and correct. Background on the wider workflow lives in Claude Blueprint, which connects these hooks to the publish pipeline they protect.
Bottom Line
Six hooks, each doing one job. Brand-check stops forbidden words and bad currency format. Spacing and font hooks hold the layout together across dozens of templates. A11y and SEO hooks catch the things real users and search engines feel but casual review never sees. Post-publish verify confirms the live page is actually live and correct.
None of these are clever. They are small scripts that run on an event and return pass or fail. The power is that they run every time, with no dependence on the model remembering a rule across a long session. A memory file is a suggestion. A hook is a gate.
Start with one. The brand-check hook is the easiest to build and catches the most embarrassing mistakes. Add a new pattern every time you catch a problem by hand, so you never catch that one by hand again. Within a few weeks you will have a set that fits your work exactly. If you want the workspace structure these hooks sit inside, Claude Blueprint lays out the foundation I build every project on top of.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Top comments (0)