advise (beraten)

0. Erster Durchlauf

1. Lies settings.md im Vault-Stammverzeichnis. Wenn es keinen Abschnitt ## Profile gibt, teile dem Eigentümer mit, dass er zuerst /setup ausführen soll, und stoppe dann. ## Profile, ## Layers und ## Sources gelten für diesen Skill.
2. Wenn settings.md keinen Abschnitt ## /advise hat oder $ARGUMENTS gleich setup ist, frage diese Punkte in einer Nachricht ab, nummeriert, jeweils mit dem Standardwert in Klammern, damit der Eigentümer mit „Defaults“ antworten kann:
   1. Standard-Arbeitsbereich, den du lesen sollst, wenn keiner genannt wird (nur wenn Layers Arbeitsbereiche von Arbeitgebern aktiviert). [keiner: bei Bedarf nach Kontext fragen]
   2. Wenn die Antwort von einem Kontext abhängt, den du nicht hast (Stage, ACV, Motion): zuerst in einer Zeile fragen oder mit angegebenen Annahmen antworten? [in einer Zeile fragen]
   3. Antwortlänge: kurz (nur Antwort und Quellen) oder standard (Antwort, Begründung, Meinungsverschiedenheiten, Quellen)? [standard]
   4. Immer zu kennzeichnende Vorbehalte: Benchmarks aus Kontexten, die nicht zu deinem (Region, Geschäftsmodell im Profil) passen. [US-amerikanische Venture-Backed-SaaS-Benchmarks vor der Anwendung auf andere Regionen, Finanzierungsmodelle oder Geschäftsmodelle kennzeichnen]
3. Schreibe die Antworten als kurze Aufzählungsliste unter ## /advise in settings.md (am Ende hinzufügen; bei erneuter Einrichtung ersetzen). Bestätige in einer Zeile. Beantworte dann die Frage oder stoppe, wenn der Eigentümer nur setup ausgeführt hat.

Beantworte die Frage in $ARGUMENTS.

Kontext. Wenn workspace:<Unternehmen> angegeben ist oder ein Standard-Arbeitsbereich in den Einstellungen festgelegt wurde, lies workspaces/<Unternehmen>/context.md und beurteile jede Empfehlung anhand dieser Stage, dieses ACV und dieser Motion. Wenn Layers Arbeitsbereiche deaktiviert oder es keinen Arbeitsbereich gibt, gehe wie in den Einstellungen festgelegt vor: Frage nach Stage, ACV und Motion in einer Zeile, wenn die Antwort davon abhängt, oder antworte mit Angabe deiner Annahmen. Nimm nichts stillschweigend an.

Abrufreihenfolge – höre auf, breiter zu suchen, sobald die Antwort gut fundiert ist:

1. playbooks/ und principles/: die Synthese und die eigene Sicht des Eigentümers. Notizen mit example: true sind mitgelieferte Beispiele: Du darfst sie verwenden, musst dies aber angeben (z. B. „das mitgelieferte Beispiel-Playbook, erstellt aus drei Quellen“). Diese haben Vorrang vor allem darunter. Wenn ein Playbook einen Abschnitt Was die Antwort ändert hat, ermittle diese Faktoren zuerst (frage in einer kurzen Nachricht oder lies sie aus dem Arbeitsbereich). Gib dann die passenden Rezepte an, nicht das gesamte Playbook.
2. library/, case-studies/ und swipe/: durchsuche alle drei nach Schlagworten und Stichwörtern.
   • Bevorzuge in der Bibliothek Notizen mit einem „Meine Einschätzung“ und tier: canon gegenüber tier: web. Wenn du dich auf eine tier: web-Quelle stützt, sage, dass sie außerhalb der vertrauenswürdigen Quellen liegt. Wenn eine Notiz corporate_data: true hat, sage, dass es sich um eine Studie eines Großunternehmens handelt, bevor du sie auf den Kontext des Eigentümers anwendest.
   • Fallstudien sind Belege dafür, dass ein Rezept in der Praxis funktioniert. Zitiere sie, wann immer eine zutrifft, und sage, dass sie aus dem Web recherchiert sind, außerhalb des Kanons liegen, und gib ihre Belegkennzeichnungen an.
   • Swipe-Items (Suche nach Format und Technik) bei Fragen zu Kreativität oder Umsetzung.
3. Vertrauenswürdige Live-Quellen: die in settings.md unter Sources aufgeführten Konnektoren für die von ihnen abgedeckten Quellen; dann Websuche beschränkt auf die in canon/_index.md aufgeführten Domänen (WebSearch mit allowed_domains auf diese Domänen gesetzt oder Exa mit einer site:<Domäne>-Abfrage pro Domäne; verwerfe jedes Ergebnis von einer anderen Domäne).
4. Allgemeines Web, nur wenn 1–3 dürftig sind. Eröffne die Antwort dann mit:

   ⚠️ Außerhalb der vertrauenswürdigen Quellen – dies basiert auf einer allgemeinen Websuche.

Bei einer großen oder risikoreichen Frage oder einer, zu der der Vault wenig hergibt, schlage /advise-deep vor, das eine vollständige Websuche hinzufügt und die Antwort auf das Unternehmen und die Rolle des Eigentümers zuschneidet. Sage, wie es diesen Kontext erhält: es liest workspaces/<Unternehmen>/context.md, wenn der Eigentümer workspace:<Unternehmen> hinzufügt, andernfalls stellt es zuerst eine kurze Reihe nummerierter Fragen. Der Eigentümer muss den Kontext nicht in die Eingabeaufforderung packen.

Form der Antwort (kürze auf Antwort und Quellen, wenn die Einstellungen kurz vorsehen):

• Zuerst die Antwort, in 2–4 Sätzen, zugeschnitten auf den Kontext.
• Die Begründung: das Playbook oder die Quellen, auf denen sie basiert.
• Wo die Experten uneins sind, falls zutreffend, und in welche Richtung dieser Kontext den Ausschlag gibt.
• Quellen: anklickbare Links zu Vault-Notizen (siehe unten) und URLs für Live-Quellen.

Jeder von dir empfohlene Test, Pilot oder jedes Experiment sagt, wie es bewertet werden soll, unabhängig von der Längeneinstellung: was gemessen werden soll, im Vergleich zu was, über welchen Zeitraum, und welches Ergebnis als Bestehen gilt. Trenne die frühen Signale (Wochen) von den verzögerten Ergebnissen (Monaten), damit ein Bestehen bei einem nicht mit dem anderen verwechselt wird. Wenn die Quellen nichts dazu sagen, sage das, anstatt eine Lücke zu lassen.

Frischeregeln (lies freshness.md). Dies sind die Schutzmechanismen gegen Fehler:

• Zitieren wie die Playbooks: der vollständige Name der Quelle, verlinkt auf ihre Notiz, ohne Datum im Zitat selbst. Im Chat sind Wikilinks nicht anklickbar, verwende daher einen Markdown-Link zum Dateipfad, mit Leerzeichen als %20 und Klammern als %28/%29, z. B. [Jane Beispiel](library/Seed-Stage%20Positioning%20-%20Jane%20Beispiel.md). Playbooks genauso: [positionierung](playbooks/positionierung.md). Wikilinks ([[notiz|Jane Beispiel]]) gelten nur für Texte, die in Vault-Dateien geschrieben werden.
• Jede Benchmark, Zahl, jedes Plattformverhalten oder jede Tool-Empfehlung in einer Antwort trägt ihr Datum in der Form „CAC-Amortisation von 12–18 Monaten, Stand 2024-02 (Jane Beispiel)“. Niemals undatierte Details.
• Aus einer Notiz, die aging ist: Verwende die Prinzipien frei. Zitiere ein Detail nur mit „Stand , nicht erneut verifiziert“. Bei volatile Themen (KI-Sichtbarkeit, AEO, Plattformalgorithmen, Tools) überprüfe vor der Beantwortung eine Live-Quelle.
• Aus einer Notiz, die superseded oder expired ist: zitiere niemals ihre Details. Folge superseded_by.
• Wenn alte und neue Quellen widersprüchlich sind, gewinnt bei Details die neuere, es sei denn, die ältere trägt re-verified. Sage, dass du diese Entscheidung getroffen hast.
• Wenn die beste verfügbare Angabe ihren Gültigkeitszeitraum überschritten hat und nicht erneut verifiziert werden kann, sage das deutlich, anstatt sie als aktuell darzustellen.

Regeln:

• Kennzeichne die in den Einstellungen festgelegten Vorbehalte (standardmäßig US-amerikanische Venture-Backed-SaaS-Benchmarks), bevor du einen Benchmark auf eine andere Region, ein anderes Finanzierungsmodell oder Geschäftsmodell als das des Eigentümers im Profil anwendest.
• Wenn die Antwort einer Notiz in principles/ widerspricht, sage das deutlich. Wähle nicht stillschweigend eine aus.
• Lies niemals einen Vault, der in settings.md unter Layers → Never read aufgeführt ist.
• Kopiere niemals Arbeitsbereichsdaten in eine portable Datei. Wenn die Antwort eine wiederverwendbare Lektion zutage fördert, biete an, die Lektion zu einem Playbook hinzuzufügen.