Konrad Kowalski (rootsher)Principal Platform & Reliability Architect001001010001110000101001111010100101110000001011

Skills, Hooks i Permissions: zapisz sposób pracy, zautomatyzuj mechanikę, ogranicz ryzyko

data
kategoria
AI Agents
także w
AI Engineering · Automation · Engineering Practices
czytanie
2 min / 311 słów

Po poprzednich poziomach Claude zna repo i potrafi sam zdobywać potrzebny context.

A mimo to w kolejnych sesjach pojawiają się podobne instrukcje:

Przy review sprawdź regressions, security i test coverage.

Przy failing CI najpierw znajdź job i odtwórz problem lokalnie.

Jeśli powtarzasz taką instrukcję regularnie, to nie jest już dobry prompt.

To powtarzalny sposób pracy.

Skill

Skill odpowiada na pytanie:

Jak Claude powinien wykonać konkretny rodzaj zadania?

Na przykład:

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

Zamiast za każdym razem pisać:

text
sprawdź correctness
sprawdź regressions
sprawdź security
sprawdź test coverage

zapisujesz to raz jako skill.

Przykład:

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.

Project-level skill trzymasz w repo:

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

Dzięki temu jest wersjonowany razem z kodem.

Hooks i Permissions

Proste rozróżnienie:

text
Skill
= jak Claude powinien pracować

Hook
= co ma wydarzyć się automatycznie

Permission
= czego Claude może albo nie może zrobić

Przykład:

text
"przy review sprawdź security"
-> skill

"po edycji pliku uruchom formatter"
-> hook

"nie pozwalaj na określone operacje"
-> permission

Hooki i permissions konfigurujesz w:

text
.claude/settings.json

Przykładowo hook może wyglądać tak:

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

Czyli po edycji pliku Claude Code automatycznie uruchomi formatter.

W uproszczeniu:

text
.claude/skills/
= sposób pracy

.claude/settings.json
= automatyzacja i granice

Nie każ Claude pamiętać o czymś, co system może zrobić automatycznie.

I nie zabezpieczaj krytycznych operacji wyłącznie promptem.

Przykład: 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.

Od tej pory nie opisujesz za każdym razem metodologii investigation.

Claude ma ją zapisaną w repo.

Wdróż to dziś

  1. Znajdź jedną instrukcję, którą regularnie powtarzasz Claude.
  2. Zamień ją w skill w:
text
.claude/skills/<name>/SKILL.md
  1. Znajdź jeden mechaniczny krok, np. formatter albo lint, i dodaj go jako hook w:
text
.claude/settings.json
  1. Sprawdź, czy operacje, których agent naprawdę nie powinien wykonywać, są ograniczone przez permissions.
  2. Użyj tego przy prawdziwym tasku.

Level complete

Poziom jest zaliczony, jeśli:

  • masz przynajmniej jeden reusable skill,
  • przynajmniej jedna mechaniczna czynność nie zależy już od pamięci Claude,
  • krytyczne ograniczenia nie istnieją wyłącznie jako prompt.

Najważniejszy upgrade:

Zamiast ciągle tłumaczyć Claude, jak pracować, zapisujesz sposób pracy raz, automatyzujesz mechaniczne kroki i ustawiasz techniczne granice.

Na kolejnym poziomie zajmiemy się problemem jednego contextu, który próbuje jednocześnie implementować, testować i reviewować własną pracę.

Materiały