tollens-ai/quality-strategy-skills

Qualitätsstrategie-Fähigkeiten (Quality Strategy Skills)

Claude Code-Fähigkeiten, die Sie interviewen, um eine Software-Qualitätsstrategie zu erstellen – wer zählt für Ihr Projekt, was sie schätzen, wo Sie exponiert sind und was Sie dagegen tun – plus die Teststrategie und Tooling-Strategie, die dies in Aktion umsetzen. Wenn der Großteil Ihres Codes von Agenten geschrieben wird, die nicht wissen, was Qualität für Ihr Projekt bedeutet, ist eine explizite Strategie das, was sie davon abhält, selbstbewusst in die falsche Richtung zu liefern.

Basiert auf Edmund Pringles Qualitätsframework: Qualität ist Wert für jemanden, der zählt; Testen ist Investigation, um herauszufinden, was tatsächlich wahr ist; Risiko ist Gefahr für die Qualität. Für Einzelentwickler, kleine Teams, Engineering-Führungskräfte – und jeden, in dessen Codebasis jetzt Agenten arbeiten. Sie brauchen kein Repository: Die Ausführung in der Ideenphase ist eine erstklassige Anwendung.

Status: Alpha. Mit einer ersten Welle von Testern geteilt. Die Fähigkeiten funktionieren und wurden intensiv gegen simulierte Benutzer getestet, aber die praktische Anwendung ist begrenzt. Erwarten Sie Kanten, sagen Sie uns, wo es falsch läuft (Feedback), und lesen Sie zuerst Bekannte Einschränkungen – wir verstecken die Lücken nicht.

Installation

Dies ist ein Claude Code-Plugin:

/plugin marketplace add tollens-ai/quality-strategy-skills
/plugin install quality-strategy@tollens

Starten Sie dann in jedem Projekt mit /quality-strategy. Die Ausgabe erfolgt in quality/strategy.md im Projektstammverzeichnis. (Fähigkeiten sind auch mit Namensraum verfügbar, z. B. /quality-strategy:test-strategy, falls ein bloßer Name mit einem anderen Plugin kollidiert.)

Neue Versionen erscheinen regelmäßig – führen Sie claude plugin update quality-strategy aus, um sie zu erhalten; CHANGELOG.md sagt, was sich geändert hat.

Der typische Ablauf

1. /quality-strategy – das Hauptevent. Ein strukturiertes Interview erstellt quality/strategy.md, endet mit einer integrierten Überprüfung und verweist Sie auf die Folgeschritte.
2. /test-strategy – wandelt die Strategie in einen Untersuchungsplan um: was herauszufinden ist, in welcher Reihenfolge, aufgeteilt zwischen Menschen und Agenten.
3. /tooling-strategy – wenn die Dokumente Dinge aufgedeckt haben, die Sie noch nicht messen oder beurteilen können (häufig, und ein Befund, kein Fehlschlag): ein priorisierter Bauplan für die fehlenden Orakel und Instrumente. Die Schritte 2 und 3 tauschen, wenn die Risikokarte größtenteils blind ist – die Fähigkeiten empfehlen die Reihenfolge selbst; Sie können jederzeit widersprechen.
4. /strategy-variants (optional) – eine Einseiter- oder kundensichere Version zum Verteilen.
5. /quality-artefacts (optional) – beschreiben Sie die Ansicht, die Sie wünschen („eine tweetbare Zusammenfassung des Qualitätsstands“, „ein Dashboard der Zahlungsrisiken für mein Standup“) und es entwirft ein maßgeschneidertes, in sich geschlossenes SVG/HTML-Artefakt aus Ihrer Strategie – ehrlich zu Unbekannten, erstellt zum Screenshoten und Teilen. Ausgearbeitete Beispiele in examples/fernly/quality/artefacts/.

Wie die Fähigkeiten zusammenpassen

Fünf Fähigkeiten, die Sie starten (fett); der Rest sind Prüfungen und Audits, die die Strategien für Sie aufrufen, während sie laufen (gestrichelte Pfeile – jede funktioniert auch eigenständig). Details zu den einzelnen Fähigkeiten: docs/SKILLS.md.

flowchart TD
    QS["<b>/quality-strategy</b><br/>das 7-Schritte-Interview – HIER STARTEN"]
    OA["/oracle-adequacy<br/><i>Können die Aussagen über 'wo wir stehen'<br/>tatsächlich beurteilt werden?</i>"]
    CC["/contradiction-check<br/><i>interne Konsistenz,<br/>jede Schrittgrenze</i>"]
    OD["/operational-distillation<br/><i>TL;DR + Triage-Rubrik<br/>oben im Dokument</i>"]
    QSR["/quality-strategy-review<br/><i>das abschließende Audit</i>"]
    SDOC[/"quality/strategy.md"/]
    TS["<b>/test-strategy</b><br/>der Untersuchungsplan"]
    TA["/tooling-adequacy<br/><i>Kann jeder Lernbedarf<br/>tatsächlich beantwortet werden?</i>"]
    TSR["/test-strategy-review<br/><i>das abschließende Audit</i>"]
    TDOC[/"quality/test-strategy.md"/]
    TOOL["<b>/tooling-strategy</b><br/>der Orakel-/Instrumenten-Bauplan"]
    ODOC[/"quality/tooling-strategy.md"/]
    SV["<b>/strategy-variants</b><br/>zielgruppengerechte Varianten"]
    VDOC[/"Einseiter ·<br/>kundensichere Version"/]
    QA["<b>/quality-artefacts</b><br/>maßgeschneiderte teilbare Visualisierungen"]
    ADOC[/"quality/artefacts/<br/>*.svg · *.html"/]
    BUILD(["Baue die Orakel<br/>& Instrumente"])

    QS -.-> OA
    QS -.-> CC
    QS -.-> OD
    QS -.-> QSR
    QS --> SDOC

    SDOC -->|"Risikokarte größtenteils<br/>beantwortbar"| TS
    SDOC -->|"Risikokarte größtenteils blind –<br/>Unbekannte + Orakellücken"| TOOL
    SDOC -->|"Benötige etwas<br/>zum Verteilen"| SV
    SDOC -->|"Benötige etwas auf einen Blick –<br/>beschreibe die gewünschte Ansicht"| QA

    TS -.-> TA
    TS -.-> TSR
    TS --> TDOC
    TDOC -->|"Blockierte Lernbedarfe –<br/>die geschärfte Nachfrage"| TOOL

    TOOL --> ODOC
    ODOC --> BUILD
    BUILD -.->|"Unbekannte werden erkennbar –<br/>aktualisiere die Risikokarte,<br/>entsperre die Lernbedarfe"| SDOC

    SV --> VDOC
    QA --> ADOC

    classDef sub fill:#f6f6f6,stroke:#aaaaaa,color:#444444
    class OA,CC,OD,QSR,TA,TSR sub
    classDef doc fill:#fdf6e3,stroke:#b58900,color:#333333
    class SDOC,TDOC,ODOC,VDOC,ADOC doc

Die Form folgt den vier Fragen des Pakets – Wie sieht gut aus? Wie wissen wir es? Ist es gut? Wie machen wir es gut? – und einer Regel: Sie können nur untersuchen, was Sie beurteilen können, daher entscheidet der Zustand Ihrer Risikokarte, ob der Untersuchungsplan oder der Bauplan zuerst kommt.

Was Sie erwarten können

• Sie interviewen Sie. Ihre Qualitätsstrategie kann nicht aus Ihrem Code abgeleitet werden – wer zählt, was sie schätzen, was keine Ziele sind, würde alles falsch erraten werden. Die Fähigkeiten lesen das Repository vor, um fundierte Fragen zu stellen; alles Tragende wird gefragt, nicht angenommen.
• Sie halten die Messlatte hoch. Sie überspringen Ihre Nicht-Ziele nicht oder reduzieren die Strenge, weil eine Aufgabe klein erscheint – diese Weigerung ist der Punkt. Sie passen ihre Formulierung an Sie an und bieten eine klar gekennzeichnete Startschätzung an, wenn Sie nicht weiterwissen.
• Sie erstellen lebende Dokumente, die dazu gedacht sind, gelesen, aktualisiert und an Entscheidungspunkten verwendet zu werden – nicht einmal geschrieben und abgeheftet.
• Es erfordert echtes Denken. Planen Sie ein bis zwei Arbeitstage kognitive Zeit ein, verteilt auf mehrere Sitzungen – die Fähigkeiten sind für Pausen ausgelegt und setzen sauber wieder auf. Schneller als ein paar Stunden bedeutet normalerweise, zu schnell zu antworten.
• Kein Repository erforderlich. In der Ideenphase sagt die Vorab-Lektüre ehrlich, dass sie interviewbasiert ist, anstatt Schätzungen als Scan-Ergebnisse zu verkleiden, und das Interview trägt die Last, die es immer trägt.

Bekannte Einschränkungen

• Noch keine dedizierten Dimensionen für KI / nicht-deterministische Produkte – Systeme, deren „Korrektheit“ eine Metrikverteilung ist, die driftet. Die Stakeholder-/Risiko-/Planungsmechanik hilft trotzdem; den Kern „Wie sieht gut aus und wie würden wir es wissen?“ müssten Sie selbst erstellen. Unser wichtigster Forschungspunkt (ROADMAP.md).
• Hauptsächlich in Simulation validiert. Gegen viele simulierte Benutzer stresstestiert und adversariell überprüft; begrenzte praktische Anwendung. Vorläufige Entscheidungen werden in OPEN-QUESTIONS.md mit dem festgehalten, was unsere Meinung ändern würde.
• /tooling-strategy ist die neueste Fähigkeit mit der geringsten Kilometerleistung – erwarten Sie dort rauere Kanten.
• Rhythmus ist Einheitsgröße. Jeder Durchlauf erhält die gleiche gründliche Behandlung, unabhängig von der Projektgröße; eine leichtere Ansicht derselben Strenge ist auf der Roadmap, eine niedrigere Messlatte nicht.
• Einzel-Release-Tiefe. Die Tiefenanalyse deckt jeweils ein Release ab; führen Sie sie im Revisionsmodus erneut aus, wenn der Kontext des nächsten Releases real ist.

Woher das kommt

Dies ist die erste Open-Source-Veröffentlichung von Tollens – einem Engineering-Management-Berater, der das implizite Gespür dafür, was „gut“ für Ihr Projekt bedeutet und wie gut Sie tatsächlich sind, in eine explizite, lebendige Karte verwandelt, von der sowohl Menschen als auch KI-Agenten ausgehen können. Das Paket ist ein funktionierender Vorgeschmack, eigenständig, kein Konto erforderlich – aber es sind eigenständige Fähigkeiten, kein Ende-zu-Ende-Workflow: Die Einbindung der Dokumente in Ihren Teamprozess liegt bei Ihnen. Das vollständige Tollens-Produkt (in Entwicklung) ist die Ende-zu-Ende-Version – Agenten, die jeden Schritt unterstützen, Feedbackschleifen, Nachweise und Berichterstattung, Release-Confidence-Bewertung.

Einfach ausgedrückt: Dieses Paket ist die Karte mit dem „Sie sind hier“-Pfeil. Tollens ist das Navi – Schritt-für-Schritt für die gesamte Reise, Neuberechnung bei Abweichung, mit einer ETA, der Sie vertrauen können.

Was wo ist

• docs/SKILLS.md – Referenz pro Fähigkeit, einschließlich geplanter Fähigkeiten.
• ROADMAP.md – was als nächstes kommt (Schlagzeile: Qualitätsdimensionen für KI / nicht-deterministische Produkte).
• examples/fernly/ – ein vollständiges ausgearbeitetes Beispiel an einem fiktiven Projekt: vollständige Strategie, Teststrategie und drei generierte Artefakte. Die Antworten eines Projekts, keine Vorlage – siehe seine README.
• PHILOSOPHY.md – das Rückgrat; warum die Fähigkeiten tun, was sie tun.
• OPEN-QUESTIONS.md – Designentscheidungen, die unter Unsicherheit getroffen wurden, und was unsere Meinung ändern würde.
• skills/ – die Fähigkeiten selbst.

Feedback

Sagen Sie uns, wo es falsch läuft: eröffnen Sie ein Issue. Die wertvollsten Berichte sind konkret – was Sie ausgeführt haben, was es produziert hat, was Sie stattdessen erwartet haben. Besonders erwünscht: Dimensionen, die das Interview verpasst hat (oder unnötig aufgeworfen hat), Stellen, an denen es angenommen hat, was es hätte fragen sollen, und jede bekannte Einschränkung, die stärker zubeißt als beschrieben.

Credits

Das Qualitätsframework stammt von Edmund Pringle, destilliert in ein Open-Source-Qualitätsgehirn, auf das dieses Paket direkt zurückgreift; seine Blog-Serie ist die beste erzählerische Lektüre zu diesem Thema. Das Framework basiert auf der kontextgesteuerten Testtradition (Bach, Bolton, Weinberg). Implementierung der Fähigkeiten durch Yanqing Cheng. Erstellt mit Claude Code.

Lizenz

Lizenziert unter entweder MIT oder Apache-2.0 nach Ihrer Wahl. Sofern Sie nicht ausdrücklich etwas anderes erklären, wird jeder von Ihnen absichtlich zur Aufnahme in diese Arbeit eingereichte Beitrag, wie in der Apache-2.0-Lizenz definiert, wie oben dual lizenziert, ohne zusätzliche Bedingungen.