DEV Community: Peterson Andres Sena Arias

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

Peterson Andres Sena Arias — Mon, 12 Oct 2026 10:34:04 +0000

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:

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…).
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.
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.
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.
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:

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.
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.

My AI agent's guardrails are written in Spanish. They work exactly the same in English.

Peterson Andres Sena Arias — Mon, 12 Oct 2026 10:13:13 +0000

A couple of weeks ago I wrote (in Spanish) about Senzu, the toolkit I built to stop repeating myself to my coding agents. Same rules in every project: don't commit to main, check the page on a phone before saying it's done, write down what you did and why, pick the palette before the third component, not after.

The short version of that post: rules in a CLAUDE.md are suggestions. The agent reads them and almost always follows them. "Almost always" isn't good enough for a real project, so I turned every rule that could be executed into something that executes: hooks that block, not paragraphs that advise.

Since then Senzu has gone from v2.7 to v2.19. That's a lot of new walls, a guided start for new and existing projects, a memory that keeps itself up to date, and a website. And the question I got the most after that first post was not about any of that. It was this:

"It's all in Spanish. Does it work if I don't speak Spanish?"

Yes. This post explains why, and then shows you everything that's new.

Why Spanish, and why it doesn't matter

Senzu is written in Spanish on purpose. There's a mountain of tooling for coding agents in English and almost nothing designed for people who work in Spanish, so I built the thing I wanted to use.

But here's what took me a while to see clearly: almost nothing in Senzu is written for you. It's written for the agent.

Think about what Senzu actually is:

Skills are instructions the agent loads when a task needs them: how to design a UI, how to audit a backend, how to plan a feature. The agent reads them. You never do, unless you're curious.
Hooks ("walls", muros in Spanish) are small Node scripts that run before and after the agent acts. They inspect the command or the file and either let it through or block it with a reason. The reason goes to the agent.
Commands like /plan or /adoptar are prompts with a name. You type the name; the agent reads the prompt.

Claude and GPT read Spanish as well as they read English. An instruction like "el dominio no conoce el framework" lands exactly the same as "the domain doesn't know about the framework". The model doesn't translate it into a weaker rule, it just understands it.

What you see is the conversation, and the conversation happens in your language. The hook that runs at the start of every session tells the agent, literally: "respond in Spanish, or in the language the user writes to you in". Write in English, get English back.

Your code doesn't become Spanish either. When you adopt an existing project, Senzu learns its conventions, including the language of its identifiers and comments, and seals them (more on that below). An English codebase stays English.

There are three places where Spanish leaks through, and I'd rather tell you than have you find out:

The rules file installed in your project (CLAUDE.md / AGENTS.md) opens with "Comunícate en español". The session hook overrides it with "or the user's language", but if you want to remove any doubt, tell Senzu once and it will remember for every project:

   /recordar always answer me in English, and write the devlog and plan in English

That line goes to your user memory (~/.config/senzu/memoria.md), which is injected at the start of every session in every project, with the instruction that it beats the agent's own habits.

When a wall blocks something, the raw message is in Spanish. You'll see it scroll by in the tool output. The agent reads it, understands it, and explains it to you in English. Here's a real one, so you know what to expect:

Real output of the guard hook. The "In English" box is my translation for this post; in a session, the agent explains it to you.

Automatic capture of your corrections listens for Spanish. One of the new features (below) notices when you say things like "no vuelvas a…" ("don't do that again") and makes the agent write it down. The phrases it listens for are Spanish, so "from now on, never…" in English slips past it. The workaround is the same command: when you want something remembered, say /recordar … and it's stored, in any language. English phrases for the detector are on my list.

That's it. Everything else is the same as if Senzu were written in English: the same walls fire, the same commands run, the same skills load.

Quick recap: what Senzu is

If you didn't read the first post:

A package for Claude Code and Codex (Codex runs the same hooks since v1.5).
43 skills: mine, plus the best ones I found from other people (with their author and license credited), with a layer on top that makes them work together. A router decides which one to load, so the context isn't flooded with things you don't need.
24 hooks that block or remind.
22 commands for the workflows I repeat in every project.
9 stacks with their own rules: Laravel, Next, Nuxt, Astro, SvelteKit, Vue + TypeScript, Node APIs, WordPress and Python with LangGraph.
MIT licensed.

Now, what's new.

New: a guided start, for new projects and inherited ones

The biggest change since the first post is that Senzu now has an opinion about the order of things, and enforces it.

When you open a session, the start hook figures out where you are and tells the agent the next step of the method:

Empty or new project: /brief (a plain-language interview: what the business does, what visitors should do, what sites you like), then /propuestas (two genuinely different mockups you can open in a browser and vote on piece by piece), /design-system, /plan, and /siguiente to execute one task at a time.
Existing project with code but no sealed conventions: /adoptar first. Before the agent writes a single line, it studies how the project is actually written and agrees the rules with you.

And it's not a suggestion. The arranque-guard hook blocks the first attempt to write code if the missing step hasn't happened. No plan? The agent has to ask you what you're building before it starts.

The new website has a section for exactly this:

Each step links to its command page. The descriptions come straight from the Senzu repo at build time, so they never drift.

`/adoptar`: the agent writes like your project, not like itself

This is the one I'm proudest of, because it fixes the thing that annoyed me most.

Drop an agent into a three-year-old Laravel project and it will happily write code in its style: different naming, a different validation approach, a different folder layout. Every PR becomes a style argument.

/adoptar (adopt) reads the real code: naming, structure, how validation is done, how tests are named, what the git history looks like, which language identifiers and comments are in. It proposes the conventions, with a real example from your code for each one. You agree or correct. Then it seals them in senzu/conventions.md.

From then on:

The conventions-guard hook blocks code that breaks the sealed conventions.
The agent can't edit, move or delete the sealed file, not with an edit, not from the terminal, not by sneaking it into a commit. In v2.14 I found it could be bypassed if the path came in a different format (C:/ vs /c/) and fixed it as a security issue.
The project's convention beats Senzu's own preferences. Always.

New: declared architecture, enforced by a wall

v2.18 adds something I wanted for a long time. You declare your architecture once: MVC with services, hexagonal, or DDD. There are templates for Laravel, Node and Python. A wall makes the code respect it.

It checks layers, bounded contexts, controllers that talk to the ORM directly, DTOs and folders. It reads the real import map of your project (PSR-4, tsconfig aliases, Python modules), so it knows that App\Models\Order lives in infrastructure.

Here's what happens when the agent tries to put Eloquent in a controller of a hexagonal project:

And when it tries to import the framework into the domain:

Both are real outputs, produced by running the hook against a throwaway Laravel project for this post.

Notice the last line of each message: it doesn't just say no, it says where the code should go instead. That's what turns a wall into something the agent can act on in its next attempt. If you really need an exception, you approve it and it's written down with a reason, right on that line.

New: a feature isn't done until the backend says so

v2.17 extended the "no 'done' without proof" rule from the frontend to the backend. The feature-guard hook won't let the agent close a backend feature if:

there's no test for it,
there's a migration that was never run, or one without a working down,
a new config key was added but not to .env.example.

And every command now ends by saying what the next step is, so the chain from /brief to a deployed feature doesn't break in the middle.

Related: plan cards can't be marked as done without evidence (tarjeta-guard), and when the agent says it verified something, verifying means real output: lint, types, tests, build, and the mobile check for UI work. v2.19 taught the build verifier more languages (Rust, Ruby, Java, .NET, Deno, Makefiles) and what to do in projects with no manifest at all, instead of asking for a fake verification.

New: memory that maintains itself

The first post described the project memory: a short file with the decisions in force (D-012 · We do X because Y · see entry 063), injected at the start of every session. If the agent wants to contradict a decision, it has to quote it and ask.

v2.11 made it alive:

Your corrections are written down automatically. When you correct the agent with a rule ("don't do that again", "from now on…"), the memoria-viva hook notices and makes the agent write it down before going on; if it forgets, it can't close the session. (As mentioned above, it listens for the Spanish phrasing for now; in English, use /recordar.)
User memory: rules that apply to all your projects (language, git habits, how you like to be spoken to) live in one file outside any project. That's the /recordar trick from the language section.
Per-file memory: when the agent opens a file that has history ("this file broke twice because of X"), it gets reminded.
/retomar (resume): picks up where the last session left off, with what was done, what's pending and what was decided.

New: two agents, one repo, no mess

I often have Claude Code and Codex working on the same repository. That used to end badly: one agent committing the other's half-finished files, or finishing its session with a pile of uncommitted changes.

Clean exit (cierre-limpio, v2.10): the agent can't end a session leaving its own files uncommitted, and it can't touch files another agent is working on.
Protected branches (v2.12, refined in v2.19.2): no commits or pushes to main, develop, staging or production. Pushing to your own work branch (feat/…, fix/…) is allowed out of the box.
"Quoting isn't doing" (v2.16): walls used to fire when a commit message, a heredoc, an echo, a grep or a comment merely mentioned something forbidden. Now they look at what actually runs. Fewer false positives means fewer reasons to turn a wall off.

New: install profiles, and it tells you when it's out of date

Profiles (v2.9): instead of "everything or pick one by one", /instalar offers profiles: web, backend, frontend, AI agent, library. Each one brings the skills, walls and commands that make sense for that kind of project.
Out-of-date warning (v2.15): at the start of a session, if your installed Senzu is older than the latest release, the agent tells you, along with the two or three changes that matter most to you. No changelog reading required.

New: a website, with docs generated from the repo

Senzu has a home now: getsenzu.vercel.app.

The part I like most is invisible. The documentation is never written by hand. On every build, the site fetches the latest tagged release of the Senzu repo and generates a page per skill, per command and per hook from the real files. The numbers on the home page (skills, hooks, commands, stacks) come from the same place. If a hook is added upstream, it shows up on the next deploy; if a command is removed, its page disappears.

The site and its docs are in Spanish too. If you're reading in English, your browser's translate button does a good job, and so does the agent itself: ask it "what does the feature-guard hook do?" and it'll read the docs and answer in English.

How to try it

In Claude Code:

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

In Codex, add the same marketplace from the app. Then, inside your project, open a session and type:

/instalar

It detects the stack, asks what you want (a profile, everything, or à la carte) and sets it up. Then, if you want everything in English:

/recordar always answer me in English, and write the devlog and plan in English

From there, if the project already has code, start with /adoptar. If it's a new one, /brief. The agent will tell you anyway.

Repository: github.com/petersonsenadevs/senzu
Website and docs: getsenzu.vercel.app
The first post, in Spanish: Le puse muros a mi agente de IA

What it isn't

It's opinionated. These are my working rules, not everyone's. You can turn walls off per project and change permissions, but only you can: the agent can't switch off its own walls, and that's by design.

It doesn't make the agent stop making mistakes. It still makes them. The difference is that now it finds out before I do, and the explanation of what to do instead arrives in the same message.

And it's in Spanish, which, as it turns out, matters a lot less than I thought. The agent doesn't care. Hopefully you won't either.

If you try it, tell me which wall you'd add. There's always one I missed.

[Boost]

Peterson Andres Sena Arias — Sat, 03 Oct 2026 15:19:31 +0000

Peterson Andres Sena Arias

Oct 3

Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

#spanish #ai #claude #codex

9 min read

I got tired of logging in and out of Claude Code, so I built a one-command account switcher

Peterson Andres Sena Arias — Sat, 03 Oct 2026 11:25:10 +0000

Quick confession: last week I logged out of my work Claude Code account four times in one afternoon. Nothing was broken. I just have a second account for personal projects, and Claude Code can only be logged into one of them at a time.

Sign in with the personal account and the work one is gone. Sign back in with work and personal is gone. Every switch is a browser tab, an OAuth dance and about forty seconds of my life. Multiply that by "I switch contexts a lot" and you get a genuinely annoying week.

So I fixed it. The result is cc-switch, and the whole thing is one command:

ccp use personal

Every claude you launch after that runs under the personal account. ccp use work flips it back. No re-login, no browser, no forty seconds. And ccp list tells you who is who:

  Claude Code profiles
  --------------------
  * default                   alice@company.com
    personal   [shared]       alice@gmail.com
    client-x   [isolated]     alice@client-x.com

The trick is a single environment variable

I expected to need something hacky with credential files. I didn't. Claude Code reads an environment variable called CLAUDE_CONFIG_DIR and uses it as the root for everything it stores: credentials, settings, session transcripts, the lot. Point it at a different folder and you get a completely separate identity.

So a "profile" in cc-switch is literally a directory:

~/.claude-profiles/
  personal/    ← its own login
  client-x/    ← its own login
~/.claude      ← your original account, untouched ("default")

ccp use <name> sets the variable for the current shell and persists it for new terminals. ccp run <name> sets it for a single invocation only, which means two terminals can talk to two different accounts at the same time:

# terminal 1
ccp run work

# terminal 2
ccp run personal -p "summarise yesterday's changes"

I use that far more than I expected to.

Then I lost all my chats

The first version worked great for about ten minutes. Then I opened a project under the personal profile and my conversation history was empty. Of course it was: transcripts live in projects/ inside the config dir, and the new profile had its own brand new, empty one.

For some setups that's exactly what you want (a clean-room profile for a client). For my day-to-day it was terrible. I wanted the login separated, not my memory of what I was doing yesterday.

The fix turned out to be clean. On a shared profile, cc-switch replaces the chat folders (projects/, sessions/, plans/, tasks/, file-history/) and history.jsonl with links back into ~/.claude: NTFS junctions and a hardlink on Windows, plain symlinks on Linux and macOS. Credentials and settings stay per profile, chats are one pool, and claude --resume shows the same list whichever account you're on.

If you do want a walled-off environment, you just say so:

ccp add client-x --isolated

You can flip a profile between the two modes later with ccp link and ccp unlink. Nothing gets deleted either way: unlink gives the profile its own empty folders and leaves the shared history where it is.

The bug that would have deleted everything

This is the part I actually want people to read, because it's a general Windows/PowerShell gotcha.

My first ccp remove was the obvious thing: Remove-Item -Recurse -Force <profile dir>. On a shared profile, that directory is full of junctions pointing at ~/.claude. And Remove-Item -Recurse will happily walk straight through a junction and delete the contents of the target.

In other words, "remove the test profile" would have wiped my entire real chat history. I only caught it because I was being paranoid in testing: I made a throwaway profile and counted the project folders on both sides before and after. The fix is to delete the links themselves first (DirectoryInfo.Delete() on a junction removes only the reparse point, not what it points to) and then recurse into whatever is left. rm -rf on Linux doesn't follow symlinks, so the bash version was never at risk, but it does the same explicit dance anyway.

If you write any tool that creates junctions on Windows: test your delete path against a directory you'd be sad to lose. I got lucky. You might not.

Install it

One line, no clone:

Windows (PowerShell)

irm https://raw.githubusercontent.com/petersonsenadevs/claude-code-switch/main/install.ps1 | iex

Linux / macOS

curl -fsSL https://raw.githubusercontent.com/petersonsenadevs/claude-code-switch/main/install.sh | bash

Then:

ccp add personal          # new profile, shares your chats
ccp login personal        # opens claude: sign in, then /exit
ccp use personal          # you're switched
ccp list                  # every profile, with the email signed in on each

It's plain shell (a PowerShell module and a bash script) with no dependencies and no daemon. It doesn't wrap or patch claude; it only sets a variable the CLI already respects. Profile names autocomplete with Tab, and ccp update pulls the latest version when there is one.

What I'd love feedback on

macOS Keychain. On macOS, Claude Code keeps its OAuth credentials in the system Keychain rather than in the config dir. Depending on your Claude Code version, that Keychain entry may be shared between profiles. I've built and tested this mainly on Windows and Linux, so if you're on a Mac and ccp list shows the right account on each profile (or doesn't), I'd really like to hear about it in an issue.
Which folders should be shared? I went with the ones that make --resume behave. settings.json and MCP configs stay per profile on purpose. Would you share anything else?

The repo is here: github.com/petersonsenadevs/claude-code-switch, MIT licensed. If it saves you the forty seconds, a star helps other people find it.

Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

Peterson Andres Sena Arias — Sat, 03 Oct 2026 11:11:59 +0000

Empecé a trabajar mis proyectos con agentes de IA usando Codex, y después llegó Claude Code. Al poco me di cuenta de que, proyecto tras proyecto, le estaba diciendo al agente lo mismo una y otra vez. Que no commitee en main. Que revise en móvil antes de dar algo por hecho. Que deje escrito qué hizo y por qué. Que antes de diseñar decida la paleta y la tipografía, no a mitad de un componente.

A eso se sumaban las librerías y las skills de otros que iba encontrando: una muy buena para diseñar interfaces, otra para animar con GSAP, otra para 3D… Cada una funcionaba bien por su cuenta, pero no se conocían entre ellas. Yo era el pegamento, copiando y pegando instrucciones de un proyecto a otro.

Así que decidí juntarlo todo en un recopilatorio en el que las piezas se ayudaran entre sí. Lo llamé dev-standards, porque era literalmente eso: mis estándares de trabajo. Hoy se llama Senzu.

Y por el camino me siguieron pasando cosas como estas, todas en la misma semana:

Prettier, con su configuración por defecto, le metió 204 punto y coma a un archivo de un proyecto que no los usa. El agente lo dio por bueno.
El instalador de mis propias normas vació el .mcp.json de un proyecto Laravel y se llevó por delante un servidor MCP que estaba configurado.
El agente me dijo que había verificado la web en móvil. Las capturas existían, sí: en una carpeta temporal que yo nunca iba a abrir.
Un loader y una barra de carga «centrados». A ojo lo estaban. Midiendo, no.
Y mi favorita: yo daba por hecho que Codex no ejecutaba hooks. Sí los ejecuta. Lo que pasaba es que mis hooks no entendían cómo Codex describe una edición, así que dejaban pasar todo sin decir nada.

Ninguna de estas cosas es grave por separado. Juntas, son la diferencia entre fiarte del agente y tener que revisarle cada línea.

Las reglas en un CLAUDE.md son sugerencias

Ahí está el problema de fondo. Puedes escribir en el CLAUDE.md o en el AGENTS.md que no se commitea en main, que se verifica en móvil antes de cerrar una tarea o que no se toca el .env. El agente lo lee. Y casi siempre lo cumple.

«Casi siempre» no vale cuando es un proyecto de verdad.

Por eso el recopilatorio no se quedó en un montón de instrucciones: lo que podía ejecutarse, lo convertí en algo que se ejecuta, no que se lee. Y el nombre: si viste Dragon Ball de pequeño, ya sabes por qué Senzu. Una semilla y el proyecto se recupera.

Qué es Senzu

Un paquete para Claude Code y Codex, en castellano, con tres piezas que trabajan juntas:

Skills: las mías y las de otros proyectos (con su autor y su licencia), con una capa en castellano encima. El agente carga solo la que toca: diseño de interfaz, calidad de código, DDD, animación, despliegue… Un enrutador decide cuál leer según lo que pides y en qué orden: primero se decide el diseño y después se elige el efecto, no al revés. Así no se llena el contexto de cosas que no vienen al caso.
Muros (hooks): no aconsejan, bloquean. Si el agente intenta algo que no debe, la acción no se ejecuta y le explican por qué.
Comandos: /plan, /verificar, /brief, /propuestas… atajos para flujos que repito en todos los proyectos.

Así se ve un muro cuando salta:

[BLOQUEADO por Senzu] No se commitea en 'main'. Crea una rama
(git switch -c feat/...) y commitea ahí.

Hace unos días bloqueó al propio agente que me estaba ayudando a sacar la última versión de Senzu, cuando intentó commitear donde no debía. Ahí es cuando sabes que funciona.

Los muros que más me han salvado

Son dieciséis, pero hay unos cuantos que se ganan el sueldo cada semana:

guard: nada de git push sin que yo lo apruebe en ese momento, nada de rm -rf, de borrar la base de datos ni de desplegar a producción por las buenas. Para saltárselo hace falta una variable explícita y mi aprobación, y la norma es dejarlo apuntado en el devlog.
secrets-guard y protect-files: el agente no escribe claves reales en el código (las de AWS, Stripe, OpenAI… se reconocen por su forma) ni toca el .env, las migraciones ya aplicadas o los archivos que se generan solos.
stop-guard: este es mi favorito. El agente no puede dar la tarea por terminada si editó código y no pasó el build, el lint y los tests, si tocó la interfaz y no la verificó en móvil, o si no dejó escrito el devlog del día. Se acabó el «ya está» sin pruebas.
backend-guard: bloquea migraciones que borran o renombran columnas de golpe (primero se añade lo nuevo y luego se quita lo viejo) y datos personales escritos en los logs.
code-hygiene: fuera los console.log, los dd() y los .only olvidados en los tests. Y algo más, que cuento en el diseño.
conventions-guard: en un proyecto que ya existe, /adoptar analiza cómo está escrito de verdad, lo pactamos y lo sella. A partir de ahí, el código que se salga de esas reglas no entra. Manda la convención del proyecto, no la del agente.

Y uno que no bloquea pero que agradezco cada día: el formateo al guardar no impone estilo. Si el proyecto no tiene configuración del formateador, no formatea, y si al formatear cambian más líneas de las que tocó el agente, lo deshace y avisa. Lo de los 204 punto y coma no ha vuelto a pasar.

Las skills que más uso

Son más de cuarenta, pero el agente casi nunca carga más de una o dos por tarea. Las que más trabajan:

ui-ux-pro-max (de Next Level Builder): la puerta de entrada de todo lo visual. Antes de escribir una línea de interfaz decide estilo, paleta, tipografía y patrón según el negocio y el stack, y lo deja guardado en un design system del proyecto. Encima lleva mi capa: perfiles para Laravel con Inertia, Next, Astro y Vue, y las guías de diseño que cuento más abajo.
front-activation: el catálogo de efectos. Más de noventa, cada uno con su receta por stack, su versión para «reducir movimiento» y su coste en móvil. Pides «un marquee de logos» y el agente abre solo esa receta, no un manual entero.
code-quality: buenas prácticas por lenguaje y un verify-build que entiende monorepos y lanza el lint, los tipos, los tests y el build de lo que has tocado.
project-planner: /plan convierte una feature en fases y tareas pequeñas, cada una con la skill que toca y cómo se verifica. Luego /siguiente va una por una.
backend-audit: audita el backend con herramientas de verdad, y cada hallazgo lleva su prueba: la salida del comando, el archivo y la línea, o un test que falla. Nada de «podría mejorarse la arquitectura».

Para animación y 3D (GSAP, Three.js, React Three Fiber…) uso las de Claude Design Skills, también con su capa en castellano.

Memoria que no depende de que el agente se acuerde

Cada proyecto tiene un devlog (qué se hizo, por qué y cómo se verificó) y un archivo de memoria corto con las decisiones vigentes: D-012 · Esto se decidió así · ver entrada 063. Un hook lo inyecta al empezar cada sesión. Si el agente va a contradecir una decisión, tiene que citarla y preguntarme.

Para lo que no está en la memoria hay un buscador sobre el devlog que entiende raíces, erratas y sinónimos. Parece poca cosa. Es la diferencia entre explicar dos veces por qué no usamos tal librería o no tener que explicarlo nunca más.

Cómo diseña

Aquí es donde más se nota que las piezas se conocen entre ellas.

1. Primero pregunta. Si no hay brief ni design system, el primer intento de tocar la interfaz se bloquea. El agente tiene que preguntar antes: qué hace el negocio, qué tiene que hacer el visitante, si hay marca, y dos o tres webs que te gusten. La entrevista va en lenguaje llano (/brief), sin palabras como «hero» o «CTA», porque no todo el mundo habla así.

2. Estructura antes que estética. Con eso escribe un blueprint: las secciones de la página con texto real y, en cada una, qué cambia en móvil. Hasta que no lo apruebas, no se diseña nada.

3. Dos maquetas que se pueden abrir. /propuestas genera dos direcciones opuestas de verdad, en HTML que se abre con doble clic. Cada decisión lleva una etiqueta (A·T1 es la tipografía de la maqueta A, B·B2 los botones de la B…) y un panel «Tu opinión» para votar Sí o No pieza a pieza y copiarlo al chat.

4. Rondas. /ronda hace la siguiente: lo que te gustó queda fijado en todas las maquetas, lo que no te gustó desaparece y cada maqueta trae algo nuevo. Un verificador comprueba antes de enseñártela que se ha respetado todo eso.

5. Los vetos se cumplen. Lo que dices que no te gusta va a un archivo gustos.md. Y aquí vuelve code-hygiene: si vetaste un color o un carrusel, el agente no puede volver a escribirlo. Lo mismo con una lista negra de cosas que delatan una web hecha con IA, como los badges de «disponible», las secciones numeradas «01 / 02 / 03», el «trusted by» con logos en gris o las métricas inventadas. Están bloqueadas por defecto.

6. Construye sección a sección, enseñando cada una antes de pasar a la siguiente. Y cuando el logo ya está elegido, sus archivos finales quedan protegidos y el agente no se pone a hacer bocetos que nadie le ha pedido.

Y al final, verifica.

Verificar es medir, no mirar

Esta parte nació del loader descentrado. «Debería verse bien» no es verificar, así que el verificador de interfaz ahora mide en píxeles: si algo que su contenedor centra está a 4 px del centro, te lo dice, con la causa probable (un margin-left: 8px que sobraba, por ejemplo).

Lo calibré contra webs reales para que no fuera una máquina de falsos positivos. Empezó dando entre 33 y 41 avisos por página y lo dejé en 0-2. De paso encontró algo de verdad: en vuejs.org, un icono de play que está 3 px descentrado dentro de su propio SVG.

En móvil hace lo que yo hacía a mano: abre el menú de verdad. Lo pulsa, mide si los enlaces se pueden tocar con el dedo, prueba que se cierra con Escape y te deja una captura con cada aviso numerado encima de su elemento. La cifra y la imagen, juntas.

La parte divertida

No todo son muros. Senzu también trae un catálogo de efectos con recetas por stack (Astro, Next, Vue con Inertia), y hace poco le pedí algo concreto: que la web se viera normal y de repente se partiera como un cristal.

La demo, a media velocidad para que se vea algo: en tiempo real dura menos de un segundo.

Lo que se rompe es la propia página, no una imagen encima. Cada trozo es una copia del DOM recortada con clip-path a la forma del cristal. Por eso se lee el texto real, nítido, mientras cae girando en 3D. Sin capturas de pantalla y sin librerías.

Y con reglas, porque un efecto así puede acabar siendo un circo: una vez y con intención, se salta con Escape, quien tiene activado «reducir movimiento» solo ve un fundido, y al terminar no queda nada en el DOM. Tiene sus pruebas automáticas en un navegador real, como todo lo demás.

Cómo probarlo

En Claude Code:

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

En Codex se añade el mismo marketplace desde la app. Luego, en tu proyecto, abre una sesión y escribe /instalar: detecta el stack, te pregunta qué quieres (todo, por categorías o a medida) y lo deja listo.

Repositorio: github.com/petersonsenadevs/senzu
Documentación: getsenzu.vercel.app

Lo que no es

Es opinado: son mis normas de trabajo, no las de todo el mundo. Lo puedes adaptar (los muros se apagan por proyecto y los permisos se cambian), pero parte de cómo trabajo yo.

Está en castellano, a propósito. Hay muchísimo para agentes en inglés y casi nada pensado para quien trabaja en español.

Y no hace que el agente deje de equivocarse. Se sigue equivocando. La diferencia es que ahora se entera antes que yo.

Es MIT. Usa skills de otros proyectos, cada una con su autor y su licencia en CREDITOS.md. Cada semana comprueba si esos proyectos han cambiado y me abre un PR para revisarlo.

Si lo pruebas, me encantará saber qué muro le pondrías tú a tu agente. Seguro que hay alguno que se me ha escapado.

Laravel SwaggenerAI: Generate Swagger Documentation with AI in Seconds

Peterson Andres Sena Arias — Tue, 03 Jun 2025 06:20:47 +0000

Tired of writing Swagger documentation manually for your Laravel APIs? Meet Laravel SwaggenerAI, a VS Code extension that uses artificial intelligence to automatically generate complete OpenAPI/Swagger documentation.

Key Features

Multiple AI Providers

The extension supports the best AI models on the market:

Google Gemini (gemini-2.0-flash)
OpenAI GPT-4
Anthropic Claude

Smart Generation

Automatic controller detection
Routes and request analysis
Intelligent caching for faster performance

Complete Customization

Flexible AI provider selection
Simple API key configuration
Multiple formatting options

How It Works

The extension uses an abstraction system that allows working with different AI providers uniformly. Each provider implements the same interface, ensuring consistency in documentation generation.

The process is simple:

Analyzes your Laravel controllers
Automatically detects routes and methods
Generates optimized prompts for each AI provider
Produces ready-to-use Swagger/OpenAPI annotations

Installation and Usage

Install from VS Code Marketplace

Search: "Laravel SwaggenerAI"

Install the extension

Configure your preferred AI provider and API key

Generate documentation with one click!

Optimized Performance

The extension includes an intelligent cache system that avoids regenerating documentation unnecessarily, significantly improving response times in large projects.

Why Laravel SwaggenerAI?

Save Time: What used to take hours, now takes minutes

Consistency: Uniform documentation across your entire project
Flexibility: Choose the AI model that best fits your needs
Free: Available on VS Code Marketplace

Useful Links

📦 VS Code Marketplace Marketplace
📚 Complete Documentation
GitHub Repository
☕ Support the Project
If you find this extension useful, consider:
⭐ Starring it on GitHub
Buy me a coffee
📣 Sharing it with other developers

DEV Community: Peterson Andres Sena Arias

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

The one idea: skill = how, hook = proof

Where the hooks live: five moments of a session

1. The router: read one skill, not forty

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

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

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

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

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

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

What it feels like from the inside

Build your own pairs

My AI agent's guardrails are written in Spanish. They work exactly the same in English.

Why Spanish, and why it doesn't matter

Quick recap: what Senzu is

New: a guided start, for new projects and inherited ones

/adoptar: the agent writes like your project, not like itself

New: declared architecture, enforced by a wall

New: a feature isn't done until the backend says so

New: memory that maintains itself

New: two agents, one repo, no mess

New: install profiles, and it tells you when it's out of date

New: a website, with docs generated from the repo

How to try it

What it isn't

[Boost]

Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

I got tired of logging in and out of Claude Code, so I built a one-command account switcher

The trick is a single environment variable

Then I lost all my chats

The bug that would have deleted everything

Install it

What I'd love feedback on

Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

Las reglas en un CLAUDE.md son sugerencias

Qué es Senzu

Los muros que más me han salvado

Las skills que más uso

Memoria que no depende de que el agente se acuerde

Cómo diseña

Verificar es medir, no mirar

La parte divertida

Cómo probarlo

Lo que no es

Laravel SwaggenerAI: Generate Swagger Documentation with AI in Seconds

Key Features

Multiple AI Providers

Smart Generation

Complete Customization

How It Works

Installation and Usage

Install from VS Code Marketplace

Optimized Performance

Why Laravel SwaggenerAI?

Useful Links

`/adoptar`: the agent writes like your project, not like itself