/ Verzeichnis / Playground / mattpocock/skills
← Alle Server ↗ GitHub
● Community mattpocock ⚡ Sofort

mattpocock/skills

von mattpocock · mattpocock/skills

Matt Pococks persönliches .claude-Verzeichnis — eigenwillige TypeScript-, Test- und Workflow-Skills direkt von einem TS-Urgestein.

Matt Pocock (TypeScript-Pädagoge, Ersteller von Total TypeScript) hat sein persönliches Claude Code Skills-Verzeichnis veröffentlicht. Enthält TS-spezifische Muster, Testing-Philosophie, Refactoring-Muster und Workflow-Meinungen. Kein generisches Bundle — es ist das echte Setup eines Ingenieurs.

▶ Demo ansehen 📦 Installieren 💡 Anwendungsfälle

Warum nutzen

Hauptfunktionen

Live-Demo

In der Praxis

bereit

Installation

Repository des Autors · Offizielle Dokumentation zu Claude Skills

Anwendungsfälle

Praxisnahe Nutzung: mattpocock/skills

Matts TS-Muster auf ein bestehendes Projekt anwenden

👤 TypeScript-Entwickler, die die Code-Qualität verbessern ⏱ ~90 min intermediate

Wann einsetzen: Dein Projekt hat anys und fragwürdige Typen, und du willst eine grundlegende Bereinigung.

Ablauf
  1. Scannen
    mattpocock/ts-review nutzen. /src scannen und jeden any, jeden unsicheren Cast, jedes Typ-Loch auflisten. Nach Datei gruppieren.✓ Kopiert
    → Aufgezählte Befunde, keine Zusammenfassung
  2. Mit Prinzipien beheben
    Die top 20 beheben, schmalste Korrektur pro Fall. Matts „prefer inference“-Regel respektieren — was TS ableiten kann, nicht explizit annotieren.✓ Kopiert
    → Minimale Diffs, Typsicherheit gewonnen
  3. Prüfen
    tsc --noEmit ausführen. Regressionen?✓ Kopiert
    → Saubere Kompilierung oder präzise begrenzte verbleibende Punkte

Ergebnis: Eine messbar typsicherere Codebasis nach einer prinzipientreuen Methodik.

Fallstricke
  • Skill wendet Matts Meinungen an, wo dein Team anderer Ansicht ist (z. B. interface vs. type) — Übersteuern mit „skip the interface-vs-type conversion, keep existing style“
Kombinieren mit: filesystem

Ein Feature test-first bauen, auf Matts Art

👤 Entwickler, die einen stärker testgetriebenen Workflow adoptieren ⏱ ~60 min intermediate

Wann einsetzen: Du hast ein neues Feature zu bauen und willst Test-First mit modernem TS-Tooling ausprobieren.

Ablauf
  1. Test schreiben
    mattpocock/test-first nutzen. Ich möchte eine parseInvoice-Funktion hinzufügen. Test schreiben (vitest, Integration-over-Unit-Bias) vor jeglicher Implementierung.✓ Kopiert
    → Fehlschlagender Test mit realistischen Fixtures
  2. Implementieren
    Jetzt die minimale Implementierung. Typsicher, kein any.✓ Kopiert
    → Grüner Test mit sauberen Typen
  3. Refactorn
    Refactoring-Muster aus dem Skill anwenden — Helpers extrahieren, wenn sie es verdienen, keine verfrühte Abstraktion.✓ Kopiert
    → Refactoring nur dort, wo die Kriterien des Skills erfüllt sind

Ergebnis: Eine Test-Suite, die Verhalten testet, eine Implementierung, die sie erfüllt, und Zurückhaltung beim Refactoring.

Fallstricke
  • Meinungen kollidieren mit dem bestehenden Jest-Setup des Teams — Den Skill bitten, sich anzupassen — er ist eigenwillig, aber umorientierbar
Kombinieren mit: filesystem

Kombinationen

Mit anderen MCPs für 10-fache Wirkung

mattpocock-skills-skill + filesystem

Auf ein gesamtes Repo anwenden

ts_review über den gesamten /src-Baum laufen lassen und berichten.✓ Kopiert
mattpocock-skills-skill + github

Einen PR pro Review öffnen

Für die top 3 Bereinigungen je einen PR mit klarer Beschreibung erstellen.✓ Kopiert

Werkzeuge

Was dieses MCP bereitstellt

WerkzeugEingabenWann aufrufenKosten
ts_review path TS-spezifisches Audit 0
test_first feature_spec Start eines neuen Features 0
refactor_with_types path, goal Typerhaltungs-Refactoring 0

Kosten & Limits

Was der Betrieb kostet

API-Kontingent
k. A.
Tokens pro Aufruf
Review-intensiv — bei großen Codebasen Budget für umfangreiche Lesevorgänge einplanen
Kosten in €
Kostenlos
Tipp
Zuerst nach Verzeichnis eingrenzen; nicht alles scannen

Sicherheit

Rechte, Secrets, Reichweite

Minimale Scopes: filesystem-read
Credential-Speicherung: Keine
Datenabfluss: Keine

Fehlerbehebung

Häufige Fehler und Lösungen

Skill fühlt sich zu eigenwillig an

Das ist der Punkt — spezifische Meinungen im Prompt übersteuern oder forken und bearbeiten

Empfehlungen kollidieren mit Team-Stil

Ausgabe mit dem Team teilen; als Diskussionsanstoß nutzen, nicht als Direktive

Kennt meine Nischen-Bibliothek nicht

Skills sind TS-allgemein — Bibliotheks-Docs dem Kontext voranstellen

Alternativen

mattpocock/skills vs. andere

AlternativeWann stattdessenKompromiss
Your team's linter configDu brauchst CI-seitige Durchsetzung, nicht interaktiven ReviewKein LLM-Reasoning, keine Refactoring-Hilfe
Biome / ESLint with typescript-eslintRegelbasiert, deterministisch gewünschtErklärt nicht sein Reasoning so wie Matts Skills

Mehr

Ressourcen

📖 Offizielle README auf GitHub lesen

🐙 Offene Issues ansehen

🔍 Alle 400+ MCP-Server und Skills durchsuchen