Zum Inhalt springen
Denofy
Esc
  • Seiten

    Alle Pakete durchsuchen
  • Verifizierte Pakete
  • Neue Pakete
  • Sammlungen
  • Dokumentation
  • CLI-Referenz
  • So funktioniert die Prüfung
  • Skill veröffentlichen
↑↓ zum Navigieren · Enter zum Öffnen

Sichere Skills schreiben

Was einen Skill riskant macht, wie Denofy ihn von A bis F benotet und mit welchen Mustern dein Skill bei A bleibt.

Aktualisiert am 17. Okt. 2026 2 Min. Lesezeit

Dein Agent befolgt die Anweisungen eines Skills mit deinen Rechten. Ein Skill, der ihn ein fremdes Skript ausführen oder ~/.ssh lesen lässt, ist gefährlich – auch wenn er gut gemeint ist. Diese Leitlinien schützen deine Nutzer und halten dein Paket bei Sicherheitsnote A.

Die großen Vier#

  1. Kein fremder Code. Nie einen Download in eine Shell leiten (curl … | bash, iwr … | iex). Werkzeuge stattdessen mit Paketmanager und fester Version installieren.
  2. Keine Secrets. Keine SSH-Schlüssel, Cloud-Zugangsdaten, Browser-Profile oder .env-Dateien lesen und nie Umgebungsvariablen ausgeben oder hochladen.
  3. Keine Daten nach draußen – außer das ist der Zweck des Skills, dann an einen dokumentierten Host und mit Bestätigung der Nutzer.
  4. Keine versteckten Anweisungen. Kein unsichtbares Unicode, keine HTML-Kommentare mit Anweisungen, kein „ignore previous instructions“ oder „without telling the user“.

Zerstörerische Schritte ausdrücklich machen#

rm -rf, git push --force, Tabellen löschen: Lass den Agent vorher nachfragen und begrenze den Befehl eng (ein Pfad im Projekt, ein benannter Branch).

Skripte klein und lesbar halten#

Jedes Skript in einem Skill ist Code, den der Agent ausführen kann. Nutze lieber Anweisungen mit Werkzeugen, die der Agent schon hat. Wenn du ein Skript mitlieferst: kurz halten, kein eval, keine Netzwerkaufrufe, kein sudo, und in der SKILL.md erklären, was es tut.

Kontextmarker für Beispiele#

Musst du einen gefährlichen Befehl zeigen – etwa in einem Security-Review-Skill –, markiere ihn als Negativbeispiel oder verneine ihn („Never run …“). Denofy zählt ihn dann als Information statt als Befund. Siehe Kontextregeln.

Ausnahmen mit Begründung#

Manchmal ist ein Befund gewollt (ein offizieller Installer, ein dokumentierter API-Host). Erlaube ihn in denofy.yml mit Begründung. Er bleibt im Bericht sichtbar und hält die Note bei höchstens B – ehrlich und besser als Verstecken. Siehe denofy.yml.

So entsteht die Note#

Jede Version startet mit 100 Punkten; Befunde, Lizenzprobleme, neue Risiken und Strukturfehler ziehen Punkte ab, und manche Regeln deckeln die Note (ein kritischer Befund bedeutet immer F). Die ganze Tabelle mit Gewichten und Beispielen steht auf der Methodik-Seite. Der Bericht deines Pakets zeigt genau, welche Abzüge gelten.