How it works

stele works in three places: when a session starts, around each write, and in your pull requests.

Here’s what a normal session looks like from the agent’s side.

When a session starts

Claude Code loads .claude/rules/stele-rules.md the same way it loads CLAUDE.md. So the agent knows your rules before its first write.

It’s also told to create and change files with Write and Edit, because those are the tools stele can see.

Before a write

Most of the time, nothing happens here. The agent already has the rules, so the write goes ahead.

If a rule is new to the agent, stele stops the write once and shows it the rule. This happens if you changed a rule after the session started, for example. The agent reads the rule and tries again, and the second try goes through.

After a write

stele reads the lines the agent just wrote and runs your checks on them.

If a line breaks a blocking rule, the agent gets the file, the line, the rule and your message, and it’s told to fix it. The write isn’t undone. The agent fixes it with another edit.

If a line breaks a non-blocking rule, the agent gets a note instead.

In your pull request

stele check runs the same rules on every changed file. This also catches what the hook can’t see, like files written through a shell command. See Run stele in CI.

How stele protects itself

When the agent uses Write or Edit on stele.md, your Claude Code settings or stele’s own files, Claude Code asks you first, every time. The same goes for a shell command that visibly writes to them. A change there could weaken your rules, so only allow it if you asked for it.

If stele.md gets broken, your last good rules keep applying, and the agent is told about the error.