Skills teach, hooks check: how my AI agent's skills and guardrails work together

If you've used Claude Code or Codex for a while, you've probably collected some skills: folders of instructions that teach the agent how to do something well, like designing a UI, writing tests or auditing a backend. And maybe some hooks: scripts that run before or after the agent acts and can stop it.

Most people treat them as two separate things. A drawer of skills over here, a couple of hooks over there.

That's the mistake I made for months. A skill on its own is advice: the agent reads it when it remembers to, follows it when it's convenient. A hook on its own is a wall with no map: it blocks, and the agent doesn't know what to do instead. The interesting part is what happens when every important skill has a hook that checks it, and every hook points back to the skill that explains how to get past it.

That's how Senzu is built: 43 skills, 24 hooks and 22 commands for Claude Code and Codex. This post is a tour of the best ones and, more importantly, of how they hand work to each other.

Senzu is written in Spanish, but it works the same in English: the skills and hooks are read by the agent, and you talk to it in your language. I explained exactly how (and the three places where Spanish still leaks through) in the previous post. The hook messages below are real, in Spanish, with my English translation underneath.

The one idea: skill = how, hook = proof

Here's the whole design in one picture:

The left column teaches. The right column checks. For example:

• ui-verify teaches the agent to measure a page in a real browser, phone first. stop-guard won't let it say "done" after touching UI unless that verification happened.
• project-planner teaches it to split work into small cards with a "done when" and a "how to verify". tarjeta-guard won't let a card be marked done without the proof written in it.
• depurar (debug) teaches a method: reproduce, write the failing test, one hypothesis, narrow it down, fix the cause. depurar-coach fires the moment a test or build command fails and reminds the agent of that method before it starts changing things at random.

If you only take one thing from this post, take that: for every rule you care about, write down how to do it, and then write something that checks it was done.

Where the hooks live: five moments of a session

Claude Code and Codex fire hooks at specific moments. Senzu puts at least one hook in each:

1. SessionStart: before you've typed anything, session-start tells the agent the stack, the branch, the project memory (decisions in force, what didn't work), the design system if there is one, and the next step of the method (install, adopt, plan…).
2. UserPromptSubmit: when you write, prompt-router matches your words against the skills and suggests the one that fits, once per skill per session. memoria-viva (living memory) notices when you're stating a rule ("from now on…") and makes the agent write it down.
3. PreToolUse: before every command or file edit. This is where the walls are: the hard no's, the method, your conventions, your architecture, your vetoes.
4. PostToolUse: after it acts. edit-tracker records which files this session touched, format-on-save formats them (only if your project has a formatter configured, and never more lines than the agent changed), and depurar-coach watches for failures.
5. Stop: when the agent wants to finish. This is where "done" gets checked: verification, devlog, memory, uncommitted files.

The order matters. A hook at SessionStart can't block anything, but it can make sure the agent starts in the right place. A hook at Stop can't prevent a mistake, but it can stop a mistake from being called finished.

Now the best ones, in the order you'd meet them in a real feature.

1. The router: read one skill, not forty

Forty-three skills is a lot of context. If the agent loaded them all, there'd be no room left for your code. So the first pair is about reading less:

• skill-router (a skill) is a decision tree: "is this UI? backend? a bug? a plan?", and for each answer, which skill and which section of it to read. Senzu's skills have a "minimum reading per task" table, so the agent opens one reference, not a manual.
• prompt-router (a hook) does the first step for it. Each skill in the registry has a priority and a set of keywords. When your message matches, the hook injects one line: "this looks like a job for gsap-scrolltrigger; read its SKILL.md first". The more specific skill wins: ask for a React Three Fiber scene and you get react-three-fiber, not the generic threejs-webgl.

Many of the keywords are already English (landing, hero, dashboard, animation, debug, legacy, screenshot), which is part of why it works when you write in English.

2. Design before code: ui-ux-pro-max + front-skill-reminder + code-hygiene

This trio is my favourite, because it fixed the thing agents are worst at: deciding what a page should look like before writing it.

ui-ux-pro-max (by Next Level Builder, with a Senzu layer on top) is the entry point for anything visual. It picks style, palette, typography and layout pattern for the business and the stack, and saves them as the project's design system (MASTER.md). Everything after reads from there.

But a skill can be skipped. So front-skill-reminder checks the very first UI edit of each session. If there's no design system and no brief, it blocks:

Notice the escape hatch: if it really is a one-line fix to something already built, the agent says so explicitly and retries. The wall fires once per session. It's there to force a decision, not to be annoying.

Then the third piece. During the design rounds, everything you reject goes to a gustos.md file (tastes) under "No". code-hygiene reads that file on every edit. Vetoed a carousel? It can't come back:

That's three components talking to each other through two files. The skill writes MASTER.md and gustos.md; one hook demands the first exists, another enforces the second. None of them would be worth much alone.

3. "Done" means proven: verify-build + ui-verify + stop-guard

This is the pair I'd install first in any project, even without the rest of Senzu.

code-quality ships a script, verify-build.mjs, that figures out what kind of project it's in (Node, PHP, Python, Rust, Ruby, Java, .NET, Deno, monorepos with several of them) and runs lint, types, tests and build for what you touched. When everything passes, it leaves a small mark that says "verified after the last edit".

ui-verify does the same for the screen: it opens the page in a real browser at 375, 768 and 1440 px, phone first, checks horizontal overflow, tap target sizes, contrast and console errors, and measures geometry in pixels. If something its container centers is 4 px off, it says so, with the probable cause. On mobile it actually opens the menu, taps it and checks it closes with Escape.

And stop-guard connects them. When the agent tries to finish, it checks: did this session edit code? Is there a verification mark after the last edit? Did it touch UI? Is there a devlog entry for today? Are today's decisions in the project memory?

Here's one it gave me, for real, while I was writing the previous post with an agent:

The agent had written the post, generated the images, committed, and was about to tell me "all done". It couldn't. It ran the build verification, ran the UI check at 375 and 1440 px (0 problems), added the decision to the memory, and then it was done. That's the whole point: the end of a task is where agents cut corners, so that's where the strictest hook lives.

4. Plans that close with proof: project-planner + tarjeta-guard + arranque-guard

project-planner turns a feature into phases of small cards. Each card says which skill to use, what "done" looks like, how to verify it, and what it's for:

### F1-T2 · Checkout page  [M] [doing]
- What for: the customer can pay without leaving the shop
- Skill: ui-ux-pro-max
- Done when: a test payment ends on the thank-you page
- Verify: verify-ui 375/1440 + test payment
- Verified: —
- Meets: —
- Devlog: —

Then /siguiente (next) runs them one at a time. Two hooks keep that honest.

arranque-guard (start guard) blocks writing code when a step of the method is missing: no Senzu installed, an existing project with no adopted conventions, or no plan and no idea what we're building, in which case the agent has to ask you first.

tarjeta-guard (card guard) simulates what PLAN.md would look like after the edit and, for every card that moves to done, demands the last three fields, filled with real things:

"Meets" is the subtle one. It's not enough that tests pass; the card has to say how it fulfils its purpose. The tests can pass on a checkout page that doesn't let anyone pay.

5. Your project's rules, not the agent's: /adoptar + conventions-guard + arquitectura-guard

On an existing codebase, the problem isn't that the agent writes bad code. It writes different code: its own naming, its own validation style, its own folders.

/adoptar (adopt) uses the code-quality skill to study the real project (naming, structure, validation, tests, git history, the language of identifiers and comments), proposes the conventions with a real example of each, and seals them once you agree. Then:

• conventions-guard blocks code that introduces a pattern the sealed conventions forbid. Only what's introduced: old code that already breaks a rule isn't your problem today.
• guard makes the sealed file untouchable for the agent. It can't edit it, move it, delete it or restore it, from the editor, the terminal or a commit.

ddd-hexagonal is a library of 74 documents on domain-driven design, hexagonal architecture and light CQRS, including a checklist for when not to use them. If you declare an architecture (MVC with services, hexagonal or DDD), arquitectura-guard reads your real import map and blocks imports that cross a layer: the domain importing the framework, a controller using the ORM directly. I showed those messages in the previous post; the pattern is the same as everywhere else. The message says what's wrong, where the code should go instead, and how you (not the agent) can approve an exception.

6. Memory you don't have to maintain: devlog + the memoria hooks

The devlog skill keeps a diary per project: one entry per relevant step, what was done, why, and how it was verified, plus a short MEMORIA.md with the decisions in force (D-012 · We do X because Y · see entry 063), what didn't work, and what's pending. It also has a search script that understands word stems, typos and synonyms.

Writing it down is the skill. Using it is the hooks':

• session-start injects the memory at the start of every session. If the agent wants to contradict a decision, it has to quote it and ask.
• memoria-archivo (file memory) fires the first time a session touches a file: "here's what the memory and the devlog say about this file". That's how the agent learns that a component broke twice for the same reason before it breaks it a third time.
• memoria-viva catches your rules as you say them, and estado-sesion saves where the session left off, so /retomar (resume) can pick it up tomorrow without you explaining anything.
• stop-guard, again, won't let a session close with decisions in the devlog that never made it to the memory.

7. The hard no's (that still explain themselves)

Finally, the walls that don't pair with any skill, because there's no "right way" to do these things. You just don't:

• guard: no git push to main/develop/staging/production, no rm -rf on dangerous paths, no destructive database commands, no curl | bash, no --force. The agent can't grant itself permissions or turn hooks off: only you can, from your own terminal.
• secrets-guard: real-looking credentials don't go into code. AWS, GitHub, Stripe, OpenAI and Anthropic keys are recognized by their shape.
• protect-files: .env, already-applied migrations, lockfiles and generated files are off-limits.
• backend-guard: migrations that drop or rename columns in one step, and personal data written to logs.
• cierre-limpio (clean exit): no ending a session with your own files uncommitted, and no touching files another agent is working on. I often run Claude Code and Codex on the same repo, and this one is what makes that possible.

What it feels like from the inside

I'll be honest: some of these walls hit me while writing this very post.

• code-hygiene blocked a throwaway script I wrote to capture the hook messages, because it had a console.log. Fair, and the fix was one line.
• The guard from an older Senzu installed on my machine blocked a heredoc because the text merely mentioned a protected file. That false positive is exactly what v2.16 ("quoting isn't doing") fixed: newer walls look at what actually runs, not at what a string says. I just hadn't updated that machine.
• And stop-guard, as you saw above, didn't let the agent call the previous post finished until it was verified.

That's the trade. A good wall costs you a few seconds now and then. A missing wall costs you the afternoon you spend finding out the agent "verified" something it never ran.

Build your own pairs

You don't need Senzu to use the idea. Pick the one rule you repeat to your agent most often and write two things:

1. A skill that explains how to do it right: short, with a "minimum reading" section so the agent doesn't load more than it needs.
2. A hook that checks it was done, at the right moment (PreToolUse to prevent it, Stop to refuse calling it finished), and whose message says what to do instead.

If you'd rather start from mine:

/plugin marketplace add petersonsenadevs/senzu
/plugin install senzu-all@senzu

Then /instalar in your project. In Codex, add the same marketplace from the app.

• Repository (MIT): github.com/petersonsenadevs/senzu
• Website and docs, with a page per skill and per hook generated from the repo: getsenzu.vercel.app

Skills from other projects keep their author and license in CREDITOS.md, and every week a job checks whether they've changed upstream and opens a PR for me to review.

Which pair would you add first? I'm always looking for the wall I haven't thought of yet.