Skills und Pakete

Skill erstellen und aufrufen

Ein Skill ist eine wiederverwendbare fachliche Anleitung. Er erweitert weder Toolrechte noch die feste Rolle eines Custom Agents. Voraussetzung: Projekt-CWD und eine CLI-Sitzung.

Legen Sie .lurus/skills/code-review-guide/SKILL.md an:

---
name: Code review guide
description: Checklist for reviewing TypeScript changes
userInvokable: true
argumentHint: Review the current changes
version: 1.0.0
---

Check behavior, edge cases and test coverage. Explain findings with file references. Treat this checklist as guidance, not as permission to modify files.

Global: ~/.lurus/skills/code-review-guide/SKILL.md mit identischem Inhalt. Alternativ wird eine einzelne .md-Skilldatei unterstützt; der Key entsteht dann aus deren Pfad. Unterstützende Markdown-Dateien im Skillverzeichnis neben SKILL.md werden nicht als zusätzliche eigenständige Skills geladen.

/skills
/skills show code-review-guide
/skills activate code-review-guide
/code-review-guide src/example.ts
/skills deactivate code-review-guide

Die Liste und show laden Skills neu. Prüfen Sie Namen, Quelle und Inhalt. name ist der Anzeigename; der kleingeschriebene, aus dem Pfad abgeleitete Key code-review-guide ist der Aufrufname. Externe Skills sind standardmäßig inaktiv, mitgelieferte Skills standardmäßig aktiv. Die Aktivierung gilt für die jeweilige Quelle. Projektquellen können gleichnamige globale Quellen ersetzen; Kollisionen mit Built-ins, Commands, Agenten oder reservierten mitgelieferten Aufrufen können einen Slashalias verhindern.

Ein manueller Slashaufruf ist unabhängig vom automatischen Skillkontext. Er versucht die Aktivierung für die Sitzung und verwendet die Argumente als Prompt, ohne Argumente den argumentHint. $ARGUMENTS und $1 werden im Skilltext nicht wie bei eigenen Befehlen ersetzt. Der Skill liefert Anleitung für einen normalen Agentauftrag, keine unmittelbar fest implementierte Codeänderung.

Alle Frontmatterfelder

metadata.version, metadata.author, metadata.category sind unterstützte Fallbacks. model, allowedTools und disableModelInvocation sind hier keine wirksamen Skillfelder. Eine Versionsangabe installiert keine Abhängigkeiten.

Aktivierung, Session und Globs

/skills activate-session code-review-guide
/skills deactivate-session code-review-guide
/skills activate code-review-guide
/skills deactivate code-review-guide
/skills audit
/skillify

• activate und deactivate speichern die quellenbezogene Änderung dauerhaft. Bei mitgelieferten Skills entfernen oder setzen sie eine globale Sperre.
• Sitzungsvarianten gelten vorübergehend. Eine dauerhafte Sperre eines mitgelieferten Skills kann die Aktivierung verhindern.
• Vorrang haben temporäre Deaktivierung, dauerhafte Sperre, temporäre Aktivierung, dauerhafte Aktivierung und zuletzt der Standard für mitgelieferte Skills, in dieser Reihenfolge.
• audit: weist auf sehr kurze Inhalte, fehlende oder kurze Beschreibungen und doppelte Namen hin. Keine Schemavalidierung, Sicherheitsprüfung oder Neuladung.
• /skillify beauftragt den Agenten, aus dem bisherigen Nutzerverlauf nützliche Skills abzuleiten, Rückfragen zu stellen und Entwürfe vor dem Speichern zu prüfen. Kein deterministischer Dateigenerator.
• Nur die Liste und show laden Skills neu. Aktivierungsbefehle und audit tun dies nicht.

Fortgeschrittene Datei .lurus/skills/typescript-guide/SKILL.md:

---
name: TypeScript guide
description: Check strict typing when TypeScript files are touched
globs:
  - '**/*.ts'
userInvokable: true
argumentHint: Check the TypeScript changes
---

Use explicit types and preserve strict null checks. Report unsafe assumptions with file references.

/skills
/skills activate typescript-guide

Die Anleitung dieses aktiven Skills wird bei passenden bearbeiteten Dateien in den Kontext aufgenommen. Ohne Globs wirkt ein aktiver Skill als allgemeiner Kontext. Der eigene Matcher ist kein Versprechen sämtlicher Minimatchfeatures. Ein fremder Skill bleibt nicht vertrauenswürdige Anleitung, auch wenn aktiviert: Er kann keine Systemregeln, Permissions oder explizite Ablehnungen überschreiben.

Pakete installieren

Die Installation kopiert Dateien in den gewählten Zielbereich. Prüfen Sie Inhalte, Zielpfade, vorhandene Dateien und Lizenz vor der Freigabe.

Die folgenden Quellen sind fiktive Syntaxbeispiele, keine existierenden Empfehlungen:

/install example/quality-skills
/install bundle example/quality-skills example/review-agents
/install list

Die CLI lädt und prüft die Quellen. Danach wählen Sie einen globalen oder projektspezifischen Zielbereich und prüfen den Kopierauftrag an den Agenten. Nach erfolgreicher Installation wird das Paket registriert. Bis zu 10 gültige GitHub-Quellen sind möglich, auch ohne bundle. Es gibt keine dokumentierten Flags für --force, --dry-run, Version oder --project. Teilweise erfolgreiche Installationen sind möglich.

Prüfen Sie vor der Freigabe Inhalt, Paketname, Zielpfade und Lizenz. Eine Neuinstallation darf vorhandene Skill- oder Agentziele nicht einfach überschreiben. Kopiert werden vollständige Skillverzeichnisse und einzelne Agentdateien. Die Installation aktiviert externe Skills nicht automatisch und erteilt Agenten nicht automatisch Vertrauen.

Verwalten Sie Pakete über die CLI, nicht durch manuelle Änderungen an Registrierungsdaten. Installieren Sie Abhängigkeiten nur nach ausdrücklicher Zustimmung. Installationsskripte fremder Repositorys und pip laufen nicht automatisch in einer Sandbox.

Update und Entfernung

Achtung: Updates können Dateien überschreiben, und bestätigte Entfernung kann ganze registrierte Skillverzeichnisse löschen. Prüfen Sie Änderungen und Zielpfade zuerst. Führen Sie Projektoperationen im richtigen Projektverzeichnis aus; eine automatische Rücknahme ist nicht garantiert.

/install update quality-skills
/install update
/install remove quality-skills

Ein Einzelupdate lädt das Paket neu und erzeugt einen Kopierauftrag. Update ohne Namen ist nur ein Agentauftrag für alle Pakete, keine direkte Updateschleife. Prüfen Sie Änderungen, veraltete Dateien und nötiges Überschreiben vorher; vollständige Atomizität oder Rücknahme ist nicht garantiert.

remove zeigt registrierte Dateien und Verzeichnisse und fragt mit Nein als Standard. Bei Teilfehlern bleiben Einträge für einen weiteren Versuch bestehen. Bereinigen Sie Registrierungsdaten nicht blind von Hand.

Bei Paketnamen wird Großschreibung ignoriert; globale und Projektpakete haben keine unabhängigen Namensräume. Führen Sie Projektoperationen im richtigen Projektverzeichnis aus. Entfernen oder aktualisieren Sie denselben Paketnamen nicht aus einem anderen Projekt; das ursprüngliche Projektziel wird nicht automatisch wiederhergestellt.

LURUS_GIT_CLONE_TIMEOUT_MS steuert das Timeout beim Klonen: standardmäßig 90.000 ms, zulässig sind 5.000 bis 600.000 ms. Ein längeres Timeout macht eine fremde Quelle nicht vertrauenswürdig.

Fehlersuche

Weiter: Commands, Regeln und Memory, Referenz.