TongyiDai/feishu-okr-drafter

Feishu-OKR-Entwurf (飞书 OKR 草稿)

Ziele und Grenzen

Mehrere Arbeitsquellen zu strukturierten, diskutierbaren, messbaren und ausgerichteten Feishu-OKRs verarbeiten und diese nach ausdrücklicher Benutzerfreigabe als Entwurf schreiben, dabei die entsprechenden Mitarbeiter @-erwähnen. Die API dient der Beschleunigung; Feishu-Seiten, historische Dokumente, Screenshots, vom Benutzer eingefügte Inhalte und Arbeitszusammenfassungen sind ebenfalls gültige Eingaben. Standardmäßig werden nur Entwürfe erstellt und beurteilt, es werden keine OKRs erstellt, veröffentlicht oder bestehende geändert.

Drei Grundregeln:

• Keine Zielwerte, Baselines, Fristen, Verantwortlichen, Geschäftsergebnisse oder Ausrichtungsobjekte ohne Grundlage ergänzen; fehlende Informationen als [Bestätigung ausstehend] schreiben.
• Erstellung von Entwurf, Schreiben, Speichern und Veröffentlichen getrennt melden; ohne Rücklese-Nachweis keine Fertigstellung erklären.
• Bei sensiblen Umsatz-, Kosten-, Kunden-, Personal- oder Strategiedaten bevorzugt bestätigte Verhältnisse, Intervalle, Fertigstellungsraten oder anonymisierte Ausdrücke verwenden und Teile, die separate Kommunikation erfordern, kennzeichnen.

Arbeitsablauf

1. Aufgabenmodus bestimmen

Identifizieren, was der Benutzer tun möchte:

1. Aus Arbeitsnotizen einen neuen Entwurf erstellen.
2. Vorhandene O/KRs umschreiben.
3. Qualität und Ausrichtungsbeziehungen prüfen.
4. Entwurf in Feishu schreiben.
5. Im Zyklus Ziele, KRs, Gewichtungen oder Fristen anpassen.

Ohne explizite Schreibabsicht im schreibgeschützten und Entwurfsmodus bleiben.

2. Kontext und Datenquellen aufbauen

Zuerst die aktuellen Versionsbeschreibungen von lark-shared und lark-okr lesen. Beim Lesen von Feishu-Inhalten eine Identitäts-, Mandanten- und Berechtigungsprüfung durchführen:

lark-cli auth status --json --verify
lark-cli contact +get-user --as user

In Umgebungen, die auth status --json --verify unterstützen, muss identity=user, verified=true bestätigt werden. Wenn die aktuelle CLI-Build kein auth-Unterkommando hat, kann auf contact +get-user --as user zur Identifizierung des aktuellen Benutzers zurückgegriffen werden. Um im Entwurfsmodus zu bleiben, kann task +get-my-tasks --as user verwendet werden, um zu belegen, dass der Benutzerkontext lesbar ist. Vor dem tatsächlichen Schreiben von OKRs oder @-Erwähnungen von Mitarbeitern muss der Zielbenutzer und -mandant dennoch bestätigt werden.

Die verfügbaren Datenquellen in der folgenden Reihenfolge auswählen. "Schnittstelle nicht verfügbar" darf nicht als Aufgabenendpunkt betrachtet werden:

1. API/CLI-Pfad: Wenn die Berechtigungen es erlauben, Zyklen, O/KRs, Indikatoren, Fortschritte und Ausrichtungsbeziehungen per API in großen Mengen lesen.
2. Feishu-Seitenpfad: Wenn die API fehlt, der Scope unzureichend ist oder der Speicherstatus der Seite bestätigt werden muss, control-in-app-browser verwenden. Vorrangig die aktuell vom Benutzer geöffnete OKR-Seite übernehmen. Wenn keine Seite verfügbar ist, nur ein einziges Mal eine klare Navigation zum Feishu-OKR-Eingang durchführen. Basierend auf der sichtbaren Seite lesen, keine URLs, Feldreihenfolgen oder Schaltflächenbedeutungen erraten.
3. Benutzermaterial-Pfad: Vom Benutzer bereitgestellten Text, Screenshots, Dokumente, Besprechungsnotizen, Leistungszusammenfassungen, H1-Selbstbewertungen und Arbeitsrückblicke lesen.
4. Feishu-Dokumentenpfad: Nach OKR-Erstellungs-, Schreib-, Ausrichtungs-, Ausfüllhilfs- und Positionsbeispieldokumenten suchen und diese lesen, die im aktuellen Mandanten zugänglich sind.

Auch bei erfolgreicher API den kritischen Status mit der Seite oder dem Originaltext abgleichen; auch bei erfolgreichem Seitenzugriff die Seitenfakten beibehalten und keine Beweise verwerfen, nur weil keine API-ID gebildet werden kann.

Bei Bedarf abrufen:

• Zielzyklus des aktuellen Benutzers: okr +cycle-list;
• O/KRs unter einem Zyklus: okr +cycle-detail;
• Indikatoren von O: objective.indicators list, key_result.indicators list;
• Ausrichtungsbeziehungen von O: objective.alignments list;
• Zugehörige Fortschrittsaufzeichnungen: okr +progress-list;
• Zugehörige Feishu-Dokumente: Suche nach OKR, 制定, 撰写, 对齐, 填写助手, vorrangig die im aktuellen Mandanten zugänglichen Richtlinien und Beispiele lesen.

Die Zyklusbestimmung erfolgt primär anhand der Überschneidung von Start-/Enddatum mit dem aktuellen Datum, dann anhand des Zyklusstatus. Wenn der Benutzer keine explizite Anforderung hat, wird der Jahreszyklus nicht als aktueller Standardzyklus betrachtet.

Wenn der OKR-spezifische Scope fehlt, blinde Wiederholungen stoppen und den fehlenden Scope sowie die Auswirkungen erläutern. Es kann weiterhin ein Entwurf mit markierten Kontextgrenzen basierend auf den vom Benutzer bereitgestellten Arbeitsmaterialien und den mit Berechtigung lesbaren Feishu-Dokumenten generiert werden.

2.1 Verwendung historischer Materialien

Historische OKRs sind eine wichtige Referenz. Mindestens den letzten abgeschlossenen Zyklus prüfen, wenn möglich auch frühere Zyklen, Fortschrittsaufzeichnungen, Bewertungen, Kommentare, Leistungszusammenfassungen und H1-Selbstbewertungen.

Historische Inhalte in vier Kategorien einteilen:

• Abgeschlossene Fakten: Als Baseline, Nachweis von Fähigkeiten oder Fallbelege, nicht als neue KRs unverändert übernehmen.
• Unvollständige oder wiederkehrende hohe Prioritäten: Als Kandidaten für die Hauptthemen des aktuellen Zyklus behandeln und die Phasenergebnisse neu definieren.
• Wiederholtes Feedback von Vorgesetzten oder Kollegen: In ergebnisorientierte Qualitäts-, Kollaborations- oder Mechanismen- Ergebnissen umwandeln.
• Bereits vorhandene, aber noch nicht skalierte Fähigkeiten: In skalierte, standardisierte, von anderen eigenständig ausführbare oder kommerzielle Ergebnisse umwandeln.

Ein kurzes Quellenverzeichnis erstellen: Fakt → Quelle → Zeit → Wirkung auf neue O/KRs → Noch zu bestätigen?. Vergangene Erfolge von zukünftigen Zusagen trennen.

2.2 Lesen der vier Arten von OKR-Beziehungskontexten

Vor dem Schreiben der OKRs für den aktuellen Zyklus stets die folgenden vier Beziehungen prüfen; bei fehlender API durch die Feishu-OKR-Seite, Screenshots, vom Benutzer eingefügte Inhalte oder zugängliche Dokumente ergänzen:

1. Abschluss des eigenen vorherigen Zyklus: Zielwerte, Fortschritt, Bewertungen, Kommentare und tatsächliche Ergebnisse von O/KRs Punkt für Punkt prüfen. Unterscheiden zwischen abgeschlossen, teilweise abgeschlossen, nicht abgeschlossen, Zieländerungen und fehlenden Nachweisen; nur unerledigte Angelegenheiten oder neue Phasenergebnisse, die für den aktuellen Zyklus noch relevant sind, einbringen.
2. Eigene @-Erwähnungen im aktuellen Zyklus: Sammeln, in welchen O/KRs man @-erwähnt wurde, von wem, welche Kollaborationserwartungen bestehen, Lieferzeitpunkte und Verantwortungsgrenzen. Diese als Kandidaten für Hauptverantwortung, Mitarbeiter, zu klärende Punkte oder informative @-Erwähnungen kategorisieren; @-Erwähnungen nicht automatisch als Zusage verstehen.
3. Eigene @-Erwähnungen anderer im vorherigen Zyklus: Zurückblicken, wen der Benutzer @-erwähnt hat, welche O/KRs, Kollaborationsinhalte und ob der Kreislauf abgeschlossen wurde. Identifizieren von anhaltenden Abhängigkeiten, wiederholtem Nachfragen bei denselben Personen, Kollaborationsfehlpassungen und Beziehungen, die zu Mechanismen verfestigt werden können; im aktuellen Zyklus nur noch gültige Kollaborationsbeziehungen beibehalten.
4. OKRs des direkten Vorgesetzten: Identität des direkten Vorgesetzten bestätigen, aktuellen Zyklus, O/KR-Reihenfolge, Schlüsselergebnisse, Indikatordefinitionen und Kollaborationsgrenzen. Beurteilen, ob das persönliche O eine Übernahme, Unterstützung, horizontale Kollaboration oder eine unabhängige Hauptlinie ist; wenn die OKRs des Vorgesetzten fehlen, der Zyklus unklar oder die Identität nicht verifizierbar ist, Grenzen markieren und nicht selbst ableiten.

Ein Beziehungsverzeichnis erstellen: Beziehungstyp → Quellobjekt → O/KR → Andere/Mitarbeiter → Fakt oder Erwartung → Behandlung im aktuellen Zyklus → Bereits bestätigt?. Die vier Informationsarten separat als "Historische Ergebnisse", "Kollaborationseingaben", "Kollaborationsrückblick" und "Vertikale Übernahme" verwenden, um eine Vermischung zu einer einzigen To-do-Liste zu vermeiden.

3. Minimale notwendige Eingaben sammeln

Mindestens bestätigen: Zyklus, Rolle oder Verantwortungsbereich, zu erreichende Geschäftsergebnisse, bekannte Baseline, Zielwert oder Beurteilungskriterien, Hauptkollaborationspartner, Einschränkungen und sensible Informationen.

Wenn bereits OKRs des Vorgesetzten oder Teams vorhanden sind, zuerst identifizieren:

• Welche O's müssen übernommen werden?
• Welche KRs sind gleichrangige Kollaboration?
• Welche Arbeit liegt in der Hauptverantwortung des Benutzers, welche ist Unterstützung?
• Überschneidet oder widerspricht die vorgeschlagene Arbeit des Benutzers bestehenden O's?

Wenn ein direkter Vorgesetzter existiert, sind dessen OKRs für den aktuellen Zyklus die primäre Referenz für die vertikale Übernahme; Team-OKRs, gleichrangige OKRs und @-Erwähnungen dienen zur Ergänzung des Übernahmeumfangs und der Kollaborationsgrenzen. Sowohl @-Erwähnungen, eigene @-Erwähnungen anderer als auch "scheint relevant" können nur Kandidatenbeziehungen bilden; erst wenn Inhalt, Hauptverantwortung, Zyklus und beidseitige Bestätigung zusammen vorliegen, wird es als "ausgerichtet" gemeldet.

Bei fehlenden wichtigen Eingaben mit möglichst wenigen Fragen ergänzen; wenn immer noch nicht bestätigt, weiterhin Ergebnisse liefern, aber die Unsicherheit explizit in [Bestätigung ausstehend] setzen.

4. Entwurf erstellen

Schreibweise von O

• Auf hochpriorisierte, wertvolle Arbeit konzentrieren, alltägliche Aufgabenverpflichtungen vermeiden; 3–5 O's empfohlen, bei engem Arbeitsbereich weniger erlaubt.
• Richtung, erwarteten Wert und Zeitrahmen klar beschreiben; angemessene Granularität beibehalten, Vermeidung von Slogans oder Aufgabenlisten.
• Eine gewisse Herausforderung beibehalten, "weitermachen" nicht als Ziel ausgeben.
• Langfristige Aufgaben in Phasenergebnisse des aktuellen Zyklus aufteilen.
• Geschäftsvokabular verwenden, das der Leser beim ersten Lesen versteht; bereits bestätigte Fachbegriffe der Organisation übernehmen.

Wenn der Benutzer mehrere Projekte oder Kampagnen auf einmal auflistet, zuerst nach Geschäftsergebnissen clustern, dann die Anzahl der O's bestimmen. Projektnamen gehen normalerweise in die KR, den Implementierungspfad oder die Nachweisspalte; nur wenn sie eine unabhängige Ergebnislinie darstellen, werden sie zu einem eigenen O. Häufige Clusterrichtungen umfassen: Kunden-/Geschäftsergebnisse, End-to-End-Prozesseffizienz, Produktisierung und Skalierung, Organisationsmechanismen und Einfluss.

Schreibweise von KR

• Pro O 3–5 KRs empfohlen, die jeweils verschiedene Schlüsselunterstützungsperspektiven abdecken.
• Zuerst das Ergebnis und den Status schreiben, dann den notwendigen Implementierungspfad ergänzen; reine Formulierungen wie "erledigen, verantworten, vorantreiben, nachverfolgen" vermeiden.
• Objektive, beobachtbare qualitative oder quantitative Beurteilungskriterien angeben; bei "verbessern, optimieren, verstärken" den Startpunkt, Endpunkt oder die Abnahmebedingung ergänzen.
• Zeitpunkte innerhalb des Zyklus angeben; bei unbekanntem Zielwert [Zielwert bestätigen ausstehend] setzen.
• Bei Kollaborationsbedarf Hauptverantwortung, Mitarbeiter und Verantwortungsgrenzen klar angeben; Hauptkollaborateure in der Regel nicht mehr als 4 Personen.
• Wenn die KR-Richtung erklärt werden muss, kurze Untertitel verwenden, z.B. 【Kundenwert】, 【Prozesseffizienz】, um mehrere Hauptlinien nicht in eine zu vermischen.

Eine KR vorzugsweise nach folgender Struktur organisieren:

【Schlüsselaspekt】Durch [notwendigen Pfad] bis [Zeitpunkt] [beobachtbares Ergebnis/Zielwert] erreichen, verantwortet von [Hauptverantwortlicher], kollaboriert mit @ [Mitarbeiter].

Bei zu langem Pfad kürzen; Ergebnis, Zeit und Abnahmebedingung müssen erhalten bleiben.

5. Qualitätsprüfung durchführen

Jedes O und jede KR einzeln prüfen und die Probleme in "blockiert Veröffentlichung" und "Optimierung empfohlen" einteilen. Detaillierte Regeln siehe references/okr-writing-principles.md.

Schwerpunkte der Prüfung:

• Ist O hochpriorisiert, klar, angemessen herausfordernd und auf den aktuellen Zyklus ausgerichtet?
• Unterstützt KR O direkt? Beschreibt es ein Ergebnis? Ist es messbar, erreichbar und zeitlich begrenzt?
• Überschneiden, fehlen oder widersprechen sich KRs gegenseitig?
• Haben Zielwert, Baseline, Datum und Verantwortlicher eine Quelle?
• Gibt es vertikale Übernahme, horizontale Kollaboration, klare Hauptverantwortung und tatsächliche Ausrichtungsobjekte?
• Wurden Abschlussgrad des vorherigen Zyklus, @-Erwähnungen im aktuellen Zyklus, @-Erwähnungen anderer im vorherigen Zyklus und OKRs des direkten Vorgesetzten abgeglichen?
• Stimmen Zielreihenfolge, Fachbegriffe, Datenschutz und sensible Informationsdefinitionen überein?
• Werden Punkte, Fortschritt, Gewichtung und Zielwerte nicht verwechselt?

6. Entwurf ausgeben

In der folgenden Reihenfolge liefern:

1. Zyklus und Kontext: Welche Zyklen, übergeordnete O's, Dokumente und Benutzereingaben verwendet wurden; Lesegrenzen angeben.
2. OKR-Entwurf: Unter jedem O die KRs, Ergebniskriterien, Zeit, Hauptverantwortung, Kollaborationspartner und Quellennachweise auflisten.
3. Historische Übernahme: Welche historischen Fakten zur Baseline wurden, welche Angelegenheiten fortgeführt werden, welche Ergebnisse zu skalierbaren oder replizierbaren Ergebnissen erhoben wurden.
4. Beziehungs- und Übernahmeliste: Abschlussgrad des vorherigen Zyklus, @-Erwähnungen im aktuellen Zyklus, @-Erwähnungen anderer im vorherigen Zyklus, Übernahme vom direkten Vorgesetzten, empfohlene @-Erwähnungen, Konflikte und zu besprechende Punkte.
5. Qualitätsdiagnose: Blockierende Punkte, empfohlene Optimierungen, noch nicht verifizierte Annahmen.
6. Bestätigungen ausstehend: Nur Punkte auflisten, die die Zielbedeutung, die Ergebniskriterien oder das systemische Schreiben ändern würden.

Es ist verboten, mit einer scheinbar vollständigen Zahlenreihe Unsicherheiten zu vertuschen. Qualitätsurteile sollten erklären, "warum diese KR beweist, dass O erreicht wurde".

7. In Feishu schreiben

Nur bei ausdrücklicher Aufforderung des Benutzers zum Schreiben oder Speichern Schreiboperationen ausführen. Vor dem Schreiben:

1. Erneut aktuellen Benutzer, Mandant, Zyklus, Zielzuordnung und vollständigen Entwurf bestätigen;
2. Eine "Schreib- und @-Liste" erstellen: Für jedes O/KR den Mitarbeiter, @-Grund, Hauptverantwortungsgrenze, Quelle und Verifikationsstatus;
3. Für jeden Namen oder jede E-Mail einzeln lark-cli contact +search-user verwenden, um sie in open_id aufzulösen. Bei mehreren Kandidaten, mandantenübergreifenden Ergebnissen oder unzureichenden Identitätsinformationen diese @-Erwähnung pausieren und um Bestätigung bitten, nicht schätzen;
4. Zuerst mit --dry-run prüfen;
5. Für normalen Text und @ vorzugsweise den Stil simple verwenden; wenn die genaue Position von @ erforderlich ist, das mention-Element von richtext verwenden;
6. Für das Erstellen mehrerer neuer O/KRs vorzugsweise okr +batch-create verwenden, für einzelne O oder KRs okr +create; die mention auf das entsprechende O/KR schreiben, um zu vermeiden, dass alle in einem Ziel konzentriert @-erwähnt werden;
7. Keine Punktzahl automatisch für "Entwurf" setzen; Punkte nur bei ausdrücklicher Aufforderung des Benutzers zur Bewertung behandeln;
8. Nach dem Schreiben die Zyklusdetails erneut lesen und Anzahl, Text, Reihenfolge, Gewichtung, Fristen, mentions und Speicher-/Veröffentlichungsstatus der O/KRs abgleichen;
9. Wenn der Rücklesevorgang unvollständig ist, mentions nicht angekommen sind oder die Systemsemantik zu einer direkten Veröffentlichung führen könnte, stoppen, den Benutzer informieren und nicht weiter fortfahren.

Entscheidungskriterien für Schreiben und @-Erwähnung

• Wenn der Benutzer nur "Entwurf erstellen, generieren, optimieren" sagt, nur lokalen Entwurf und Liste mit @-Empfehlungen ausgeben.
• Wenn der Benutzer explizit "Schreiben, in Feishu speichern, für mich ausfüllen" sagt, kann ein Entwurf erstellt werden; wenn der Benutzer gleichzeitig explizit "@-Erwähne jemanden" sagt oder das Beziehungsverzeichnis bereits verifizierte Mitarbeiter enthält, werden mentions geschrieben.
• mention ist die echte Benutzer-ID, kein @Name-String im Text. Im API-Pfad wird mention: ["ou_xxx"] in das entsprechende O/KR eingefügt; im Seitenpfad die Benutzerauswahl verwenden und den echten Benutzer-Tag auf der Seite zurücklesen.
• @-Erwähnungen von Hauptverantwortlichen, Mitarbeitern und direktem Vorgesetzten müssen jeweils den Grund angeben. Kandidatenbeziehungen, die nur aufgrund von "relevant" oder "wurde @-erwähnt" entstanden sind, gehen zuerst in die Bestätigungs-Ausstehend-Liste.
• Schreibergebnisse separat melden: Erstellt/Gespeichert, @-Erwähnt, Nicht @-Erwähnt und Grund, Nicht veröffentlicht. Wenn für einen Punkt kein Rücklese-Nachweis vorliegt, als noch zu verifizieren behalten.

Wenn die API das Schreiben nicht zulässt, kann auf der angemeldeten Feishu-OKR-Seite "OKR in großen Mengen einfügen" oder die Seitenbearbeitungssteuerelemente zum Speichern des Entwurfs verwendet werden. Der Seitenpfad muss die folgende Reihenfolge einhalten:

1. Zuerst aktuellen Benutzer, Zyklus und Seitentitel bestätigen;
2. Nach dem Einfügen von O/KR die Parse-Vorschau prüfen und Anzahl und Hierarchie der O/KRs bestätigen; wenn Masseneinfügen keine echten @-Erwähnungen erzeugen kann, mit Seitenbearbeitungssteuerelementen Mitarbeiter einzeln auswählen;
3. Für jedes O/KR, das @-erwähnt werden muss, die Benutzerauswahl auf der Seite verwenden, angezeigten Namen und Abteilung abgleichen, um die Eingabe von einfachem Text @Name zu vermeiden;
4. Nur Speichern bestätigen, nicht Veröffentlichen klicken;
5. Zur endgültigen Seite zurückkehren, "Gespeichert", O/KR-Text und echte Benutzer-Tags prüfen und bestätigen, dass jedes Ziel immer noch die Schaltfläche "Veröffentlichen" hat;
6. Wenn Seiten-Popups geschlossen werden, Speicherhinweise fehlen, @-Tags nicht erscheinen oder die Feldanzahl abnormal ist, die Seite erneut lesen und keinen Speichererfolg erklären.

Ausrichtungsbeziehungen wirken nur auf Objective. Vor dem Erstellen einer Ausrichtung bestätigen, dass die beiden Ziele unterschiedlichen Zielen angehören, die Zyklen zeitlich überlappen und tatsächlich eine Übernahme- oder Kollaborationsbeziehung besteht; nicht "relevant" direkt als "bereits ausgerichtet" schreiben. Vollständiger Prozess siehe references/okr-alignment-review.md.

Referenz-Routing

• Schreibprinzipien, O/KR-Diagnose und Gegenbeispiele: Lesen references/okr-writing-principles.md.
• Ausrichtung und Konfliktbehandlung vor, während und nach Besprechungen: Lesen references/okr-alignment-review.md.
• Feishu-OKR-Entitäten, Lesen, Schreiben, Berechtigungen und Rücklesen: Lesen references/feishu-okr-operations.md.