cto-review

Überblick über den cto-review skill

Was cto-review leistet

cto-review ist ein strategischer Engineering-Review-skill, mit dem sich Architektur-, Skalierungs-, Tech-Debt-, Hiring- und Build-vs-Buy-Entscheidungen prüfen lassen, bevor daraus teure Festlegungen werden. Der cto-review skill ist um das Command-Pattern /cs:cto-review <plan> aufgebaut und stellt CTO-typische Klärungsfragen: Wo bricht das System? Welche technischen Schulden werden blockierend? Kann das Team den Plan skalieren? Und ist Kaufen rationaler als selbst bauen?

Besonders geeignet für Strategic Planning-Entscheidungen

Der cto-review skill ist am nützlichsten, wenn bereits ein konkreter Plan vorliegt – nicht nur eine vage Idee. Gute Einsatzfälle sind etwa die Freigabe einer neuen Datenbank, Planung für 10x Traffic, die Entscheidung über den Neubau eines Legacy-Systems, die Bewertung einer Plattformmigration oder die Vorbereitung eines technischen Strategie-Reviews für das Leadership-Team. Besonders relevant ist er für Strategic Planning, wenn Engineering-Entscheidungen Budget, Hiring, Zuverlässigkeit und langfristige Umsetzungsrisiken beeinflussen.

Wodurch er sich von einem generischen Prompt unterscheidet

Ein generischer AI-Prompt kann breit gefasste Architekturhinweise liefern. cto-review richtet die Diskussion dagegen auf sechs Entscheidungsfragen aus, die Skalierungsgrenzen, wöchentliche Kosten technischer Schulden, Einschränkungen beim Teamaufbau und die Total Cost of Ownership über drei Jahre sichtbar machen. Dadurch eignet sich die Struktur besser für Executive Reviews, Architekturfreigaben und Risikoanalysen vor einer verbindlichen Entscheidung als offenes Brainstorming.

Wichtige Hinweise zur Einführung

Der Repository-Pfad enthält für diesen Skill eine einzelne Datei SKILL.md, aber kein lokales README.md, metadata.json, keine Rules, Resources oder gebündelten Helper-Scripts im Skill-Ordner. Die Quelle verweist per relativer Pfade auf Analyzer-Scripts in einem größeren cto-advisor-Bereich. Prüfe deshalb, ob diese Scripts in deiner installierten Umgebung verfügbar sind, bevor du dich auf die Commands verlässt. Der Kernnutzen von cto-review liegt im Review-Framework; Automatisierung kann zusätzliche Einrichtung erfordern.

So verwendest du den cto-review skill

cto-review installieren und Repository prüfen

Installiere den Skill aus der GitHub Skill Collection mit deinem Skill Manager, zum Beispiel:

npx skills add alirezarezvani/claude-skills --skill cto-review

Öffne nach der Installation:

c-level-advisor/c-level-agents/skills/cto-review/SKILL.md

Lies diese Datei zuerst, denn sie enthält das Command, die Trigger-Bedingungen und die sechs CTO-Fragen. Prüfe außerdem das umgebende Repository, falls deine Agent-Umgebung relative Pfade beibehält, da der Skill auf Scripts außerhalb des lokalen Ordners verweist, etwa cto-advisor/scripts/tech_debt_analyzer.py und cto-advisor/scripts/team_scaling_calculator.py.

Welche Eingaben der cto-review skill braucht

Für eine starke Nutzung von cto-review solltest du einen Plan mit genügend operativen Details liefern, damit der Skill Annahmen gezielt hinterfragen kann. Nimm Folgendes auf:

• Aktuelle Skalierung: Nutzer, Requests pro Sekunde, Datenvolumen, Tenants, Regionen oder Transaktionszahlen
• Zielskalierung: erwartetes Wachstum, 10x-Szenario, Launch-Event, Enterprise-Ausbau oder Migrationsfrist
• Architektur: Services, Datastore-Entscheidungen, Queues, Abhängigkeiten, Deployment-Modell und Reliability-Ziele
• Einschränkungen: Budget, Teamgröße, Hiring-Plan, Compliance, Vendor-Limits, Deadlines und SLOs
• Zu prüfende Entscheidung: freigeben, verschieben, kaufen, bauen, neu bauen, migrieren oder ein Experiment durchführen

Schwache Eingabe: „Review our new architecture.“

Stärkere Eingabe: „Use cto-review for Strategic Planning. We are moving from a monolith on PostgreSQL to event-driven services before expanding from 50k to 500k monthly active users. Current p95 API latency is 700ms during peak, writes are concentrated on one primary DB, the team has 8 engineers and plans to hire 4 more. Review scaling cliffs, tech debt cost, team ramp risk, and whether managed event streaming is better than building our own platform.“

Praktischer Workflow mit cto-review

Beginne, indem du den Plan im Command-Stil des Skills einfügst:

/cs:cto-review <your plan>

Bitte um eine entscheidungsorientierte Ausgabe, nicht um einen allgemeinen Essay. Nützliche Ausgabeformate sind zum Beispiel:

• „List the top 5 approval blockers.“
• „Identify the first scaling cliff and the evidence needed to confirm it.“
• „Compare build vs buy over three years.“
• „Separate reversible experiments from irreversible commitments.“
• „Give the questions I should ask the engineering lead before approval.“

Wenn die erste Antwort zu spekulativ ist, ergänze fehlende Fakten, statt das Modell einfach zu bitten, es „noch einmal zu versuchen“. Der Skill ist darauf ausgelegt, einen Plan kritisch zu befragen; er wird wertvoller, je mehr reale Lastdaten, Kostenschätzungen, Staffing-Annahmen und Incident-Historie du lieferst.

Dateien und Commands, die du zuerst prüfen solltest

Die einzige bestätigte Skill-Datei ist SKILL.md. Sie enthält beispielhafte Script-Aufrufe, aber dieser konkrete Skill-Ordner enthält keine lokalen Scripts. Bevor du die Scripts in deinen Workflow aufnimmst, prüfe nach der Installation, ob diese Pfade existieren:

../../../skills/cto-advisor/scripts/tech_debt_analyzer.py

../../../skills/cto-advisor/scripts/team_scaling_calculator.py

Wenn sie fehlen, kannst du den cto-review-Leitfaden trotzdem manuell nutzen, indem du im Prompt dein eigenes Tech-Debt-Inventar und deine Annahmen zum Team-Ramp-up bereitstellst.

cto-review skill FAQ

Ist cto-review für Einsteiger geeignet?

Ja, sofern eine konkrete Engineering-Entscheidung geprüft werden soll. Es ist kein Einsteiger-Tutorial für System Design, Cloud-Architektur oder Datenbankauswahl. Ein Junior Founder oder Product Leader kann den Skill sinnvoll nutzen, indem er Geschäftsziele bereitstellt und den Agent bittet, technische Risiken in Entscheidungsfragen zu übersetzen. Die finale Bewertung sollte jedoch eine erfahrene Engineering-Person einbeziehen.

Wann sollte ich cto-review nicht verwenden?

Verwende cto-review nicht für kleine Implementierungsentscheidungen, routinemäßige Code Reviews, Ticket Grooming oder das Debugging eines eng begrenzten Fehlers. Der Skill passt auch schlecht, wenn noch gar kein Plan existiert. Nutze ihn, wenn der Preis einer falschen Entscheidung spürbar ist: Plattformmigration, teure Vendor-Entscheidung, Skalierungsinvestition, Reliability-Redesign, Hiring-Plan oder Vorschlag für einen Neubau.

Wie schneidet cto-review im Vergleich zu einem Architektur-Review-Prompt ab?

Ein Architektur-Review-Prompt prüft häufig Design Patterns, Komponenten und Tradeoffs. Der cto-review skill ergänzt Executive-Druck: Kosten technischer Schulden pro Woche, Skalierbarkeit des Teams, Ausfallschwellen und Build-vs-Buy-Ökonomie. Dadurch eignet er sich besser für Go/No-Go-Reviews als für die Erstellung einer vollständigen Referenzarchitektur von Grund auf.

Benötigt cto-review die referenzierten Scripts?

Nein. Der Kern des cto-review skill ist eine strukturierte Review-Methode in SKILL.md. Die referenzierten Scripts können die Analyse verbessern, falls sie verfügbar sind, aber der Skill kann auch rein über Prompts genutzt werden. Behandle Script-Support als optional, bis du bestätigt hast, dass die Dateien in deiner lokalen Installation existieren.

So verbesserst du den cto-review skill

cto-review-Eingaben verbessern, bevor du ein Urteil anforderst

Der häufigste Fehler ist, um ein CTO-Review ohne Zahlen zu bitten. Ergänze zumindest grobe Spannen: „current write rate is 2k/min“, „expected peak is 10x after launch“, „vendor quote is $180k/year“ oder „team has two backend engineers with no Kafka experience“. Solche Details ermöglichen cto-review, reale Skalierungsgrenzen zu erkennen, statt nur generische Risiken zu benennen.

Nach Evidenzlücken fragen, nicht nur nach Empfehlungen

Ein guter cto-review-Leitfaden sollte dir sagen, was vor einer Freigabe gemessen werden muss. Frage: „What evidence is missing?“ oder „Which assumptions need a load test, cost model, prototype, or vendor reference call?“ So wird die Ausgabe zu einem Aktionsplan und reduziert falsche Sicherheit durch plausibel klingende, aber ungeprüfte Architekturberatung.

Mit Entscheidungsgrenzen iterieren

Grenze die Entscheidung nach dem ersten Review weiter ein. Zum Beispiel: „Assume we cannot hire until Q3“, „Assume downtime must stay under 30 minutes“ oder „Assume build-vs-buy must be justified over three years.“ Solche Constraints zwingen den Skill, die Tradeoffs zu priorisieren, die für das Leadership wirklich zählen, statt jede denkbare technische Sorge aufzulisten.

Den Skill für deine Organisation erweitern

Um cto-review im Teamkontext zu verbessern, ergänze interne Checklisten für SLOs, Incident-Historie, Cloud-Kostenschwellen, freigegebene Vendors, Security-Anforderungen und Templates für Architecture Decision Records. Wenn du die referenzierten Analyzer-Scripts nutzt, dokumentiere ihre Pfade und erwarteten Eingaben in der Nähe des Skills, damit spätere Nutzer nicht an fehlenden relativen Dateien hängen bleiben.