themominpro/universal-skill-creator

Universal Skill Creator

1. Kern-Neurahmung & unverhandelbare Invarianten

• Mental Modell: Ein weltklasse Skill ist ein bedarfsorientiertes prozedurales Betriebssystem, KEIN unstrukturierter Prompt. Er kombiniert proprietäres Praktiker-IP mit deterministischen Code-Gates (Drei-Zonen-Hybridarchitektur) unter strikter Einhaltung von references/agentskills_spec.md.
• Umgebungs-Hinweis: Python 3 und standardmäßige Arbeitsbereichs-Erkennungswerkzeuge sind vorinstalliert. Versuchen Sie NICHT, Paketinstallationsprogramme zu installieren, es sei denn, ein expliziter Import schlägt fehl.
• Harte Invariante 1 (Zero-Smell-Gate): Liefern Sie niemals einen Skill aus, der python3 scripts/audit_skill.py <pfad> nicht besteht. Alle strukturellen Layout Smells müssen auditiert und behoben werden.
• Harte Invariante 2 (Skript-Schmiede-Pflicht): Wenn ein Kandidaten-Skill Validierung, Schema-Prüfungen oder AST-Vergleiche durchführt, MÜSSEN Sie das begleitende ausführbare Hilfsprogramm in scripts/validate.py erstellen (0 Kontext-Token für Skriptcode).
• Harte Invariante 3 (Kompaktions-Überleben): Invarianten, Paket-Hinweise und die Aufgaben-Routing-Tabelle MÜSSEN sich innerhalb der obersten 1.000 Token von SKILL.md befinden, um Kompaktions-Scherung zu verhindern (references/compaction_resilience.md).
• Harte Invariante 4 (Produktionsstandard): Jeder Skill muss einen domänenüblichen Dialekt, eine Anti-Rationalisierungs-Tabelle und verifizierbare Evaluierungstestfälle enthalten.
• Harte Invariante 5 (Verhaltens-Gatter, nicht nur Struktur): Ein Skill, der Audit und Sicherheit besteht, aber die No-Skill-Baseline nicht schlägt, Druck nicht standhält oder im Stub-Modus nicht richtig routet, wird NICHT ausgeliefert. Siehe references/baseline_grading.md, references/pressure_scenarios.md, references/stub_router_mode.md und references/render_qa.md.
• Harte Invariante 6 (Nur Beispielstruktur): Ausgelieferte Beispiele zeigen nur Struktur, Trigger, Workflow, Entscheidungstabelle, Validate-Skript, Evals. Kopieren Sie KEINE Domänenregeln eines Beispiels in einen neuen Skill. Bauen Sie jeden neuen Skill aus dem SOP, Transkript und der Domänenforschung des Benutzers.

---

2. Aufgaben-Routing-Entscheidungstabelle

Benutzerabsicht / Eingabetyp	Empfohlener Erstellungs-Workflow	Unterstützende On-Demand-Referenz
Kommerzieller B2B-Skill (zum Verkauf / für Kunden)	Vollständige 6-Phasen-Pipeline ausführen (Phasen 0–5)	references/competitor_teardown_protocol.md
Rohe Notizen / SOP / Entwickler-Transkript	Vollständige 6-Phasen-Erstellungs-Pipeline ausführen	references/domain_knowledge_ingestion.md
Skill, der externe APIs oder MCP-Server benötigt	Phase-1-Tool-Discovery + MCP-Verkabelung ausführen	references/mcp_tool_patterns.md
Auditing oder Reparieren eines bestehenden Skills	Zero-Token-26-Smell-Audit & Patch ausführen	references/smell_taxonomy_26.md
Multi-Turn interaktive Wizard-Erstellung	OMSC-Ambiguitäts-Triage-Protokoll anwenden	references/question_triage_omsc.md
Versionssensitiver Skill (CLI, API, beweglicher Leitfaden)	Stub-/Router-Modus verwenden, nur 40-60 Zeilen Zeiger	references/stub_router_mode.md
Jeder Skill, bei jeder Entscheidungsstufe	QA-Checkpoints ausführen, max. 2 Fragen pro Checkpoint, jeden Checkpoint aufzeichnen	references/qa_checkpoints.md
Eingabe im .docx-, .pdf-, .ppt- oder ähnlichen Format	Zuerst natives Lesen des Werkzeugs (Claude Code / Claude) verwenden; Extractor ist optionaler Rückfall, nur vor dem textbasierten Lexikon-Skript erforderlich	scripts/extract_text.py
Nachweis, dass ein Skill tatsächlich hilft	Druck + Baseline-Bewertung + Render-QA ausführen	references/pressure_scenarios.md, references/baseline_grading.md, references/render_qa.md

---

3. Phase 0: Tiefgehende Marktinformationen & Konkurrenzanalyse

Führen Sie vor dem Entwurf der Anweisungen eine Wettbewerbsaufklärung mit agents/niche_researcher.md durch:

• Schritt 0.1 (Konkurrenzanalyse): Suchen Sie nach bestehenden öffentlichen Skills, Prompts oder benutzerdefinierten Anweisungen in dieser Nische.
  • Prüfen Sie die Angebote der Konkurrenz anhand der 26-Smell-Taxonomie (references/competitor_teardown_protocol.md).
  • Identifizieren Sie deren strukturelle Schwächen (z. B. generischer KI-Schrott, Optionsbuffet, fehlende Validierungsskripte).
  • Definieren Sie das Gegenmittel, das die strukturellen Schwächen der Konkurrenz behebt.
• Schritt 0.2 (Domänenliteratur & Dialektaufnahme):
  • Nehmen Sie relevante Bücher, Whitepapers, Podcast-Transkripte und Unternehmens-SOPs in einem dieser Formate auf: .txt, .md, .docx, .pdf, Notizen und Transkripte.
  • Formatierungsregel, Werkzeug zuerst, KEINE harte Regel: Claude Code und Claude lesen .md, .pdf, .docx, .ppt und ähnliche Formate nativ, also verwenden Sie zuerst das native Lesen des Werkzeugs. Erzwingen Sie keine Extraktion, wenn das Werkzeug die Datei bereits gelesen hat.
  • Der Paket-Extraktor in scripts/extract_text.py ist nur ein optionaler Rückfall für Werkzeuge oder Skripte, die Klartext benötigen. Seine eine harte Verwendung ist das Lexikon-Skript, das nur Text liest. Wenn Sie das Lexikon also auf einem .docx oder .pdf ausführen, extrahieren Sie zuerst nach .txt:

  python3 scripts/extract_text.py pfad/zu/quelle.docx --output evals/quelle.txt
  python3 scripts/extract_text.py pfad/zu/quelle.pdf --output evals/quelle.txt
  

  • Gescannte, reine Bild-PDFs haben keine Textebene: Der Extraktor warnt und gibt keinen Text zurück. Erfinden Sie keinen Text dafür; verwenden Sie OCR außerhalb dieses Pakets und protokollieren Sie diesen Schritt, oder lassen Sie Claude die Datei nativ lesen, wenn es kann.
  • Befolgen Sie references/domain_knowledge_ingestion.md, um zu extrahieren:
    1. Maßgebliche Branchenakronyme, Metriken und Standarddialekt (z. B. MEDDPICC, CAC Payback, Hook Dwell-Time).
    2. Kandidaten-Lexikon-Begriffe via python3 scripts/build_domain_lexicon.py <quellen> --output evals/lexicon.json.
    3. Algorithmische Schwellenwerte und messbare Formeln.
    4. Hochdichte Listen nicht offensichtlicher Fehlermodi („Footguns“).

---

4. Phase 1: Umgebungs- & Tool-Erkennung (Zone-1-Gatter)

Kopieren und führen Sie diesen Erkennungsschritt aus, bevor Sie Dokumentation schreiben:

• Schritt 1.1 (Umgebung & Tools untersuchen): Führen Sie das gebündelte Erkennungsskript aus:

  python3 scripts/discover_env.py
  

  (In Windows PowerShell verwenden Sie python3 scripts/discover_env.py)
  • Überprüfen Sie die Ausgabe auf erkanntes Betriebssystem, verfügbare CLI-Binärdateien (git, docker, python, usw.) und aktive MCP-Server.
  • Wenn der Kandidaten-Skill einen externen Dienst beinhaltet (z. B. Figma, GitHub, Postgres), prüfen Sie, ob ein passendes MCP-Tool oder CLI in der Umgebung vorhanden ist.

---

5. Phase 2: Stille Arbeitsbereichserkennung & OMSC-Triage

• Schritt 2.1 (Stiller Kontext-Lesevorgang): Untersuchen Sie die Konfigurationsdateien des aktiven Repositorys (package.json, pyproject.toml, Cargo.toml, .env.example, Git-Verlauf).
  • Harte Regel: Fragen Sie den Benutzer niemals nach einer Sprache, einem Framework oder einem Tool, das durch Lesen von Dateien im Arbeitsbereich ermittelt werden kann.
• Schritt 2.2 (QA-Checkpoints, obligatorisch in jeder Phase): Befolgen Sie references/qa_checkpoints.md. Die alleinige Phase-2-Triage reicht nicht aus. Präsentieren Sie an jedem Checkpoint eine 5-zeilige Entscheidungszusammenfassung, stellen Sie höchstens 2 Fragen mit einer (Empfohlenen) Standardeinstellung und zeichnen Sie sie auf:

  python3 scripts/record_qa.py evals/qa-checkpoints.json --checkpoint teardown-domain --summary