Fähigkeit: Vages Thema in Artikelgliederung verwandeln

Verwandeln Sie ein breites oder halb ausgearbeitetes Thema in eine unverwechselbare, recherchierbare Artikelgliederung, ohne den Artikel für den Benutzer zu verfassen. Beginnen Sie mit der vorhandenen Arbeit und Wissensbasis des Benutzers, identifizieren Sie wiederkehrende Fragen in relevanten Communities, wählen Sie eine fokussierte Leserfrage aus und erstellen Sie ein abschnittsweises Forschungsgerüst.

Wann verwenden

Verwenden Sie diese Fähigkeit, wenn der Benutzer:

ein vages Thema hat und Hilfe bei der Umwandlung in einen Artikel wünscht;
nach Forschungsfragen, einer Gliederung oder einem Standpunkt fragt;
manuell schreiben möchte und möchte, dass der Agent die Arbeit später verfeinert;
darum bittet, ein neues Thema mit vorhandenen Wiki-Seiten, Projekten oder Implementierungsarbeiten zu verbinden.

Nicht verwenden für:

das sofortige Verfassen des fertigen Artikels;
generisches Brainstorming ohne Recherche oder Quellenarbeit;
die Bearbeitung eines vorhandenen Entwurfs, bei dem These und Struktur bereits klar sind.

Kern-Denkmodell

Verwenden Sie diese Sequenz:

Vages Thema
  ↓
Vorhandene Arbeit und Wissen
  ↓
Wiederkehrende externe Fragen
  ↓
Fokussiertes Leserproblem
  ↓
Unverwechselbare These
  ↓
Konkreter Mechanismus oder Designobjekt
  ↓
Abschnittsbehauptungen und Forschungsfragen
  ↓
Gegenargumente und Beweislücken
  ↓
Wiederverwendbare Gliederung im angeforderten Arbeitsbereich

Das Ziel ist nicht, die Zukunft vorherzusagen oder ein Feld zusammenzufassen. Das Ziel ist, die stärkste Schnittmenge zu finden zwischen:

dem, was der Benutzer tatsächlich gebaut, beobachtet oder durchdacht hat;
dem, was ein spezifischer technischer Leser verstehen oder entscheiden muss;
dem, worüber aktuelle Praktiker aktiv diskutieren;
dem, was durch Primärquellen und konkrete Beispiele gestützt werden kann.

Verwenden Sie die Gliederungssequenz aus [[outlining-an-article|Einen Artikel gliedern]]:

Thema → Brainstorming → Gruppieren → Formen → Ein Satz pro Abschnitt → Entwurf

Für einen technischen Substack-Artikel fügen Sie die Rechercheebene vor dem Entwurf ein:

Thema → Vorhandene Arbeit → Wiederkehrende Fragen → Fokussierter Blickwinkel
→ Brainstorming → Gruppieren → Geschichtsform → Abschnittsbehauptungen → Recherche → Entwurf

Vorgehen

1. Definieren Sie die Schreibrandbedingung

Stellen Sie vor der Recherche Folgendes fest:

beabsichtigter Leser;
Artikeltyp: Technischer Essay, Feldleitfaden, Architekturnotiz, konträres Argument oder Fallstudie;
ob der Benutzer eine Gliederung oder fertigen Prosa wünscht;
wo die Gliederung gespeichert werden soll;
den vorhandenen Projekt-, Implementierungs- oder Wiki-Kontext des Benutzers.

Standardmäßig: technisches Publikum, manuelle Recherche und Verfassen, nur Gliederung, spätere Verfeinerung.

Abschlussprüfung: Schreiben Sie einen Satz, der den Leser und die Aufgabe des Artikels beschreibt.

2. Untersuchen Sie zuerst die vorhandene Arbeit des Benutzers

Lesen Sie die referenzierten Dateien vollständig genug, um Folgendes zu identifizieren:

explizite Thesen;
konkrete Reisen oder Beispiele;
Architekturgrenzen;
Fehlerfälle;
Bewertungskriterien;
Abwägungen;
ungelöste Fragen;
die Sprache, die der Benutzer bereits verwendet.

Wenn der Benutzer ein Wiki oder Verzeichnis referenziert, durchsuchen Sie es nach überlappenden Konzepten, bevor Sie eine neue Rahmung erfinden. Lesen Sie die relevantesten Konzept-, Quell-, Themen-, Notiz- und Projektseiten.

Bevorzugen Sie Ideen, die auf der eigenen Arbeit des Benutzers basieren. Eine konkrete Implementierung, fehlgeschlagene Evaluierung, Designentscheidung oder ungelöster Abwägung ist in der Regel wertvoller als eine generische Trendbehauptung.

Abschlussprüfung: Listen Sie 3–8 wiederverwendbare Prinzipien aus dem Material des Benutzers auf.

3. Recherchieren Sie wiederkehrende Praktikerfragen

Verwenden Sie Websuche nach aktuellen Diskussionen in Ingenieurs-Communities und primären technischen Quellen. Durchsuchen Sie gegebenenfalls mehrere Oberflächen:

Protokoll-Repositories und GitHub Issues/Diskussionen;
offizielle Implementierungsbeispiele;
Engineering-Blogs und Dokumentationen;
Reddit oder andere Praktiker-Communities;
technische Foren oder Konferenzmaterialien.

Suchen Sie nach Fragen, nicht nur nach Themennamen. Beispiele:

[Thema] GitHub Issue Autorität
[Thema] Implementierungsproblem
[Thema] Engineering-Diskussion Fehler
[Thema] Protokolleinschränkungen
[Thema] Produktionserfahrungen

Notieren Sie wiederkehrende Fragen unter Kategorien wie:

Identität und Autorität;
Zustand und Transaktionen;
Interoperabilität;
Daten- und Kontextgrenzen;
Sicherheit und Missbrauch;
Evaluierung und Beobachtbarkeit;
Produkt und Betriebsmodell.

Behaupten Sie keine statistische Beliebtheit, es sei denn, ein systematischer Datensatz stützt sie. Verwenden Sie Formulierungen wie „wiederkehrende Fragen in den gesampelten Diskussionen“, wenn die Recherche qualitativ ist.

Abschlussprüfung: Erstellen Sie 10–25 wiederkehrende Fragen, gruppiert nach Thema, mit repräsentativen Quellen.

4. Wählen Sie die beste Artikel-Frage

Bewerten Sie Kandidatenfragen anhand von:

Test	Frage
Leserwert	Hilft sie einem spezifischen Leser bei einer Design- oder Produktentscheidung?
Benutzerautorität	Hat der Benutzer eigene Arbeit oder eine entwickelte Meinung dazu?
Beweise	Kann die Behauptung durch Primärquellen und Beispiele gestützt werden?
Spezifität	Ist sie enger gefasst als das Gesamtthema?
Originalität	Schafft sie einen Standpunkt anstatt einer Übersicht?
Haltbarkeit	Bleibt sie nach dem aktuellen Hype nützlich?
Serienpotential	Kann sie zu Folgeartikeln führen?

Wählen Sie eine Hauptfrage und höchstens zwei Alternativen aus. Erklären Sie, warum der Gewinner stärker ist.

Gute Frageform:

Wie sollte [spezifischer Entwickler] [spezifisches System] entwerfen, wenn [neue Bedingung]?

Vermeiden Sie:

Wie wird [große Technologie] [gesamte Branche] verändern?

Abschlussprüfung: Geben Sie die ausgewählte Leserfrage an und warum sie gewinnt.

5. Leiten Sie die These aus der Arbeit des Benutzers ab

Verwenden Sie diese Vorlage:

Die gängige Ansicht ist:
Die Arbeit des Benutzers legt nahe:
Diese Ansicht ist unvollständig, weil:
Das nützlichere Modell ist:
Die praktische Konsequenz für Entwickler ist:
Der stärkste Einwand ist:

Die These sollte eine argumentierbare Behauptung sein, kein Themenlabel.

Beispiele für nützliche Transformationen:

„Agentischer E-Commerce“ → „Der Händler-Agent ist ein begrenztes Ergebnisauflösungssystem, kein Chatbot.“
„Enterprise Agents“ → „Die regulierte Einheit ist das Aktionssystem, nicht das Modell.“
„Agentengedächtnis“ → „Das Gedächtnis ist eine Steuerungsebene der Anwendung, nicht nur ein Modellmerkmal.“

Abschlussprüfung: Schreiben Sie eine Ein-Satz-These und eine 30-Sekunden-Erklärung.

6. Benennen oder definieren Sie einen konkreten Mechanismus

Geben Sie dem Artikel ein Designobjekt, das die These nützlich macht. Beispiele:

Reisevertrag;
Autoritätsgrenze;
Evaluierungsumgebung;
Kontextbudget;
Fähigkeitsoberfläche;
Entscheidungsablauf;
Ergebnisbuch;
Interventionsschleife.

Erfinden Sie kein Jargon nur, um originell zu klingen. Recherchieren Sie, ob der Begriff bereits existiert, identifizieren Sie angrenzende Terminologie und kennzeichnen Sie ihn gegebenenfalls als Arbeitstitel.

Abschlussprüfung: Definieren Sie den Mechanismus in 1–3 Sätzen und zeigen Sie ein kleines Beispiel.

7. Formen Sie den Artikel als Geschichte

Erstellen Sie keinen Katalog von Themen. Geben Sie dem Leser einen Grund, von einem Abschnitt zum nächsten weiterzulesen.

Verwenden Sie diesen Standard-Geschichtsfluss:

Eröffnungsproblem oder Szenario — zeigen Sie eine konkrete Situation, bevor Sie das Thema erklären.
Spannung — enthüllen Sie, warum die offensichtliche Lösung scheitert oder unvollständig ist.
These — geben Sie die Hauptbehauptung klar an.
Mechanismus — führen Sie das Modell, die Architektur oder das Designobjekt ein, das das Problem erklärt.
Anwendung — gehen Sie Schritt für Schritt durch, wie der Mechanismus die Praxis ändert.
Leitplanken oder Abwägungen — zeigen Sie, was schiefgehen kann und wo Grenzen liegen.
Beweise und Evaluierung — erklären Sie, wie ein Entwickler weiß, dass der Ansatz funktioniert.
Implikation — zeigen Sie, was sich für die Arbeit oder Branche des Lesers ändert.
Offenes Ende — schließen Sie mit einer Frage oder ungelösten Spannung, nicht mit einer Zusammenfassung.

Schreiben Sie für jeden Abschnitt einen Satz, bevor Sie Absätze schreiben:

Abschnitt:
Behauptung, die dieser Abschnitt aufstellt:
Beispiel oder Beweis:
Frage, die der Leser jetzt hat:
Wie der nächste Abschnitt sie beantwortet:

Der nächste Abschnitt sollte in der Regel eine Frage beantworten, die der vorherige Abschnitt aufgeworfen hat. Entfernen Sie Abschnitte, die die Geschichte nicht voranbringen.

Abschlussprüfung: Die Gliederung kann von oben nach unten als eine Kette von Fragen und Antworten gelesen werden, nicht nur als eine Liste von Themen.

8. Brainstormen, gruppieren und reduzieren

Bevor Sie die Gliederung finalisieren:

Brainstormen Sie jede relevante Idee, jedes Beispiel, jede Quelle, jeden Einwand und jede persönliche Beobachtung.
Durchsuchen Sie vorhandenes Material im Wiki, in Notizen, Highlights und Projektdateien.
Gruppieren Sie verwandte Ideen und entfernen Sie Material, das den ausgewählten Blickwinkel nicht unterstützt.
Wählen Sie eine Form aus dem obigen Geschichtsfluss oder einer anderen geeigneten Struktur.
Schreiben Sie einen Satz pro Abschnitt und überprüfen Sie die Übergänge.
Behalten Sie ungelöste Ideen in einer geparkten Liste, anstatt sie in den Artikel zu zwingen.

Gehen Sie nicht direkt vom Thema zur Prosa. Die Gliederung ist die Brücke zwischen rohem Denken und dem Entwurf.

Abschlussprüfung: Jede behaltene Idee gehört zu einem Abschnitt, und jeder Abschnitt hat eine Hauptbehauptung.

9. Fügen Sie Forschungsfragen und Beweislücken hinzu

Geben Sie für jeden behaltenen Abschnitt an:

Forschungsfragen, die der Benutzer beantworten muss;
zu findende Beweise;
wahrscheinliches Gegenargument;
was die These ändern würde;
ein konkretes Beispiel, Diagramm oder Fall.

Schreiben Sie keine Fragen, die lediglich interessant sind. Jede Frage muss helfen, die Behauptung des Abschnitts zu untermauern, herauszufordern oder zu qualifizieren.

Abschlussprüfung: Jeder Abschnitt hat 2–5 beantwortbare Forschungsfragen und mindestens ein Beweisziel.

10. Fügen Sie Gegenargumente und Beweislücken hinzu

Erstellen Sie keine einseitige Trendnarration. Fügen Sie 4–8 ernsthafte Einwände hinzu. Für jeden erstellen Sie:

Behauptung:
Beweise dafür:
Beweise dagegen:
Was würde meine Meinung ändern:
Implikation für die These:

Kennzeichnen Sie Behauptungen als Tatsache, Prognose, Interpretation oder Meinung. Identifizieren Sie, welche Behauptungen vor der Veröffentlichung Primärbeweise benötigen.

Abschlussprüfung: Listen Sie die schwächste ungestützte Behauptung des Artikels und die Quelle auf, die zum Testen benötigt wird.

11. Erstellen Sie das Gliederungsartefakt

Wenn der Benutzer nach einer Datei fragt, erstellen Sie sie am angeforderten Ort. Für Substack-Entwürfe verwenden Sie:

substack/drafts/<aussagekraeftiger-titel>.md

Verwenden Sie Frontmatter:

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: outline
working_title: "..."
---

Die Datei sollte die Arbeitsthese, den Leser, die ausgewählte Frage, die Recherchedisziplin, die Abschnittsgliederung, Fragen, Gegenargumente und eine Quellenliste enthalten. Schreiben Sie keine fertige Artikelprosa, es sei denn, es wird ausdrücklich darum gebeten.

Aktualisieren Sie nicht wiki/index.md oder wiki/log.md für einen Substack-Entwurf, es sei denn, der Benutzer bittet ausdrücklich darum. Ändern Sie nicht raw/.

Abschlussprüfung: Die Datei existiert, enthält die vollständige Gliederung und sagt dem Benutzer klar, was er als Nächstes recherchieren soll.

12. Berichten Sie das Ergebnis

Geben Sie einen kurzen Bericht ab, der Folgendes enthält:

die ausgewählte Rahmung;
warum sie ausgewählt wurde;
die stärkste Überschneidung mit der vorhandenen Arbeit des Benutzers;
wo die Gliederung gespeichert wurde;
was der Benutzer als Nächstes recherchieren und schreiben sollte;
alle Einschränkungen der Recherche, insbesondere wenn „am häufigsten“ aus einer qualitativen Stichprobe abgeleitet wurde.

Forschungs- und Quellendisziplin

Verwenden Sie primäre technische Dokumentation für Protokoll- und Implementierungsbehauptungen.
Verwenden Sie Community-Diskussionen, um Fragen und Fehlermodi zu entdecken, nicht als unbestrittenen Beweis für marktweites Verhalten.
Trennen Sie Protokollfähigkeit, Implementierungsverhalten, Benutzervertrauen und Marktakzeptanz.
Bevorzugen Sie konkrete Beispiele, Abläufe, Evaluierungsfälle und Fehlerberichte gegenüber generischen Prognosen.
Zitieren Sie internetbasierte Tatsachenbehauptungen in der endgültigen Antwort, wenn Websuche verwendet wurde.
Präsentieren Sie qualitative Suchergebnisse nicht als statistisch repräsentativ.

Häufige Fehlermodi

Mit dem Branchenthema beginnen anstatt mit dem stärksten Beweis des Benutzers.
Eine Protokollübersicht ohne Argument erstellen.
Einen Agenten als Analyseeinheit behandeln, wenn die eigentliche Einheit eine Reise, ein Workflow oder ein Aktionssystem ist.
Den Artikel schreiben, bevor die Frage des Lesers definiert wurde.
Eine Modellfähigkeit mit einer Produktionsgarantie verwechseln.
Eine API oder ein Protokoll als Beweis für sichere Interoperabilität behandeln.
Forschungsfragen stellen, die die Schlussfolgerung des Artikels nicht ändern können.
Unsicherheit hinter Phrasen wie „der Markt bewegt sich in Richtung“ verstecken.
Beeindruckend klingende Terminologie schaffen, ohne die angrenzende Literatur zu überprüfen.
Polierte Prosa verfassen, wenn der Benutzer gebeten hat, manuell zu recherchieren und zu schreiben.

Überprüfungs-Checkliste

Vor dem Abschluss:

aman-sharma-nine/agent-skills

Was ist agent-skills?

In Ihrer bevorzugten KI fragen

Dokumentation