Konrad Kowalski (rootsher)Principal Platform & Reliability Architect111000100100010010110110100111100011010101111100

Skills, Hooks and Permissions: write down the method, automate mechanics, reduce risk

date
category
AI Agents
also in
AI Engineering · Automation · Engineering Practices
reading
2 min / 368 words

After the previous levels, Claude knows the repository and can get the context it needs.

And yet similar instructions still appear in later sessions:

During review, check regressions, security and test coverage.

For failing CI, first find the job and reproduce the problem locally.

If you repeat an instruction regularly, it is no longer a good prompt.

It is a repeatable way of working.

Skill

A skill answers the question:

How should Claude perform a specific kind of task?

For example:

text
/review-pr
/investigate-ci-failure
/check-migration
/release-check

Instead of writing every time:

text
check correctness
check regressions
check security
check test coverage

you write it once as a skill.

Example:

markdown
# Review pull request

1. Read the requirements.
2. Inspect the complete diff.
3. Check correctness and regressions.
4. Check security implications.
5. Check test coverage.
6. Separate blockers from suggestions.

Do not modify code.

You keep a project-level skill in the repository:

text
.claude/
+-- skills/
    +-- review-pr/
        +-- SKILL.md

This way it is versioned together with the code.

Hooks and Permissions

Simple distinction:

text
Skill
= how Claude should work

Hook
= what should happen automatically

Permission
= what Claude can or cannot do

Example:

text
"during review, check security"
-> skill

"after editing a file, run formatter"
-> hook

"do not allow specific operations"
-> permission

Hooks and permissions are configured in:

text
.claude/settings.json

For example, a hook can look like this:

json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run format"
          }
        ]
      }
    ]
  }
}

So after editing a file, Claude Code automatically runs the formatter.

In short:

text
.claude/skills/
= way of working

.claude/settings.json
= automation and boundaries

Do not make Claude remember something that the system can do automatically.

And do not secure critical operations only with a prompt.

Example: failing CI

Skill:

markdown
# Investigate CI failure

1. Find the failing job.
2. Read the full failure.
3. Reproduce it locally if possible.
4. Find the root cause.
5. Apply the smallest reasonable fix.
6. Run verification.
7. Summarize the cause and change.

From now on, you do not describe the investigation methodology every time.

Claude has it written in the repository.

Implement this today

  1. Find one instruction you regularly repeat to Claude.
  2. Turn it into a skill in:
text
.claude/skills/<name>/SKILL.md
  1. Find one mechanical step, for example formatter or lint, and add it as a hook in:
text
.claude/settings.json
  1. Check whether operations the agent truly should not perform are constrained by permissions.
  2. Use this on a real task.

Level complete

The level is complete if:

  • you have at least one reusable skill,
  • at least one mechanical action no longer depends on Claude's memory,
  • critical boundaries do not exist only as a prompt.

The most important upgrade:

Instead of constantly explaining to Claude how to work, you write the method once, automate mechanical steps and set technical boundaries.

At the next level we will handle the problem of one context trying to implement, test and review its own work at the same time.

Materials