YuShenLiu06/yushen-skills

Von der Anforderung zur Abnahme

1. Wiederholen und Bestätigen

Wiederholen Sie die Benutzerziele, Nicht-Ziele, beobachtbaren Abnahmekriterien, Risiken und Budgetbeschränkungen. Nach der Bestätigung gehen Sie zur Implementierung über; bei bereits klarer Bestätigung können Sie diese übernehmen, ohne erneut um Autorisierung zu bitten. Fragen Sie nur nach, um Lücken zu schließen, die die Implementierung tatsächlich beeinflussen. Dieser Prozess erweitert nicht die Berechtigungen für Tools, Kosten, Push-Vorgänge, Merges oder Deployments.

2. Der Koordinator teilt direkt auf

• Der Koordinator gibt direkt funktionale Grenzen, Abhängigkeiten, Schnittstellen, Verantwortliche und Abnahmepunkte vor, ohne eine weitere Aufteilungsebene hinzuzufügen. Unabhängige Aufgaben werden parallel bearbeitet, abhängige Aufgaben folgen den Schnittstellen und der Reihenfolge.
• Eine unabhängig testbare, rückrollbare Funktion entspricht einem unabhängigen Worktree, Branch und einem echten PR. Festlegen des Zielbranches sowie der base/head SHA; verschiedene Entwickler teilen sich kein Arbeitsverzeichnis und verwenden keine Branches anderer Aufgaben.
• Die endgültige Anzahl von additions + deletions eines einzelnen Funktions-PRs sollte 1000 Zeilen nicht überschreiten, einschließlich Tests, Dokumentation und generierter Dateien. Überschreitet dies, teilen Sie zuerst angemessen auf; wenn eine Aufteilung nicht möglich ist, erläutern Sie den Grund und den Umfang, verstecken Sie keine generierten Dateien und teilen Sie keine halbe Funktion auf.
• Ein Batch mit mehreren Funktionen protokolliert die Sub-PR-URLs, Abhängigkeiten und unabhängigen Abnahmepunkte. Kann nach den bereits unterstützten gestapelten PRs oder Integrationsbranches des Projekts organisiert werden; überprüfen Sie die tatsächlichen Fähigkeiten. Aufgaben-IDs im Dokument können nicht echte PRs ersetzen.

3. Entwickler führen tatsächlich durch und weisen Selbstevidenz nach

• Der Entwickler schließt die Implementierung, Selbstprüfung und Durchlauf wichtiger Benutzerpfade ab, bevor er die unabhängige Überprüfung einreicht; er übergibt nicht die Hauptaufgabe der Durchlaufverifikation und Screenshots an den Prüfer.
• Protokollieren Sie die genaue SHA, Befehle, Umgebung, tatsächliche Ergebnisse, nicht getestete Elemente und Risiken. Bei Bugs geben Sie die Reproduktion vor der Behebung und das Ergebnis nach der Behebung auf demselben Pfad an. Berichten Sie getrennt über Build-, Mock- und echte Dienstabnahme.
• Bei UI-Änderungen geben Sie Screenshots der entscheidenden Schritte und Ergebnisse des tatsächlichen Laufs. Fügen Sie Screenshots als PR-Kommentare oder Anhänge hinzu, nicht im Code-Branch. Überprüfen Sie zuerst die unterstützten Parameter des Upload-Tools; bei Problemen melden Sie die Blockade, erfinden Sie keine Anhang-URLs.
• Bei Backend-Berechtigungen, Daten oder finanziellen Handlungen geben Sie entsprechende API-/Datennachweise. Verwenden Sie isolierte Umgebungen und synthetische Daten für Tests; geben Sie keine Anmeldedaten oder personenbezogenen Daten preis.
• Bei Änderungen von Regeln oder Dokumentation ohne UI erfinden Sie keine Screenshots; überprüfen Sie lediglich den Umfang, Links, Konsistenz der Regeln und das Diff. Containerüberprüfungen verwenden autorisierte isolierte Umgebungen; nehmen Sie keine nicht autorisierten Änderungen auf dem persönlichen Rechner des Benutzers vor.
• PRs verwenden die Vier-Sektionen-Vorlage; jeder Nachweis ist mit dem tatsächlichen Commit verknüpft.

4. Code- und Sicherheitsüberprüfungen getrennt

• Bevorzugen Sie die Wiederverwendung bereits im Repository konfigurierter automatischer Code- und Sicherheitsüberprüfungen; überprüfen Sie jeweils den Fertigstellungsstatus, die abgedeckte SHA und ungelöste Funde. Fügen Sie keine redundanten Überprüfungen hinzu und lösen Sie keine manuellen Auslösungen erneut aus.
• Wenn nicht konfiguriert, nicht ausgelöst oder die Ziel-SHA nicht abgedeckt ist, melden Sie die Lücke; behandeln Sie diese gemäß autorisierten Alternativplänen; wenn keine alternative Autorisierung vorliegt, holen Sie eine Entscheidung ein. Kein Kommentar bedeutet nicht, dass die Überprüfung abgeschlossen ist.
• Lesen Sie bei Bedarf die installierten Skripte yushen-code-quality-review für die Codequalität und yushen-security-review für die Sicherheit. Der Pfad richtet sich nach der tatsächlichen Installation; fehlen sie oder werden sie nicht gelesen, erklären Sie dies.
• Überprüfungen stellen nur fundierte Probleme dar; bei externen Implementierungen können Sie vergleichen und Vorschläge machen, aber ändern, migrieren oder Abhängigkeiten hinzufügen nur nach Zustimmung des Benutzers.

5. Maximal drei Iterationen zur Konvergenz

Eine Iteration besteht aus: Überprüfungsfeedback → Behebung oder fundierter Umgang → Verifikation. Code- und Sicherheitsüberprüfungen werden zusammen gezählt, insgesamt maximal drei Iterationen; ein Wechsel des Agenten, Modells, Wiederholungen, Restacks oder Wiedereröffnung desselben Arbeits-PRs setzt nicht zurück.

Die erste Iteration überprüft das gesamte Diff in Bezug auf die Anforderungen; die zweite und dritte Iteration überprüfen das neue Diff, die Schließung bereits vorhandener Probleme und die betroffenen Regressionen. Verwenden Sie stabile Problem-IDs, um Funde mit derselben Ursache zusammenzuführen, und protokollieren Sie Position, Nachweis, erste Iteration, Status, Behebungs-SHA und Verifikation. Falschmeldungen werden mit Belegen erklärt; machen Sie keine sinnlosen Änderungen, um Kommentare zu entfernen. Markieren Sie nichts als gelöst, ohne es erneut überprüft zu haben.

Wenn ein Problem nach zwei effektiven Iterationen keine Fortschritte zeigt, kann es vorzeitig eskaliert werden. Wenn in der dritten Iteration noch ungelöste Probleme bestehen, stoppen Sie die automatische Konvergenz, übergeben Sie die Evidenz an den Koordinator, überdenken Sie den Plan und fordern Sie eine Entscheidung an; senken Sie nicht die Hürde, führen Sie nicht automatisch durch oder mergen Sie nicht.

6. Kombinierte Versionsprüfung

Der Koordinator überprüft das endgültige notwendige CI, die Konfliktauflösung, den geteilten Zustand und die kombinierten Benutzerpfade und protokolliert die SHA jedes Sub-PRs sowie die SHA des kombinierten Kandidaten. Das Bestehen einzelner Ebenen bedeutet nicht das Bestehen der kombinierten Version. Nach Rebase, Konfliktauflösung oder Implementierungsänderungen aktualisieren Sie die SHA-Zuordnung und fügen betroffene Regressionen hinzu; alte Belege können nicht die Ergebnisse der aktuellen Version vortäuschen.

7. Menschliche Abnahme

Bereitstellung der Kandidaten-SHA, des lauffähigen Artefakts, der kürzesten Testschritte, der erwarteten Ergebnisse und der verbleibenden Risiken. Der Benutzer testet persönlich und bestätigt klar die entsprechende Version, bevor gemäß der tatsächlichen Autorisierung gemergt wird. Nach Codeänderungen wird der betroffene Teil erneut bestätigt; automatisierte Tests und Bot-Genehmigungen ersetzen nicht die persönliche Abnahme. Veröffentlichungen und Deployments erfolgen gemäß ihren jeweiligen Berechtigungen.

Bei der Lieferung von Installern, Desktopanwendungen oder anderen tatsächlich veröffentlichten Artefakten lesen Sie bei Bedarf das installierte yushen-release-acceptance-Skript, überprüfen den vollständigen Pfad von heruntergeladener Datei bis zur Nutzung und unterscheiden Sie plattformbezogene Schlussfolgerungen von Vorschau-Einschränkungen. Bei reinen Text- oder kleineren internen Änderungen muss nicht der gesamte Veröffentlichungs-Abnahmeprozess durchgeführt werden.

Modell- und Kostenstrategie

Wählen Sie das Modell basierend auf der konfigurierbaren Aufgabenkomplexität, dem Risiko, dem Budget und den verfügbaren Fähigkeiten: Für deterministische Überprüfungen priorisieren Sie Skripte; für klar lokalisierte Implementierungen priorisieren Sie die kostengünstige Stufe; für komplexe Diagnosen, Designs und risikoreiche Entscheidungen wählen Sie die leistungsfähige Stufe; für das Zusammenstellen von Belegen verwenden Sie die kostengünstigere Stufe. Geben Sie zu Beginn die ausgewählte Rolle, die Kostengrenze und die Upgrade-Bedingungen an; betrachten Sie ein bestimmtes Modell nicht als standardmäßig in öffentlichen Umgebungen verfügbar.

Schließen Sie zuerst Umgebungsfehler und fehlenden Kontext aus, bevor Sie über ein Upgrade entscheiden. Bei Budgetüberschreitung, erhöhten kostenpflichtigen Aufrufen oder Überschreitung der autorisierten Fähigkeiten holen Sie erst die entsprechende Entscheidung ein; wiederholen Sie nicht unendlich. Am Ende eines Batches verwenden Sie bei Bedarf die Nacharbeit-Zusammenfassung; Regeländerungen durchlaufen den normalen Abnahmeprozess.

Integration von Projektregeln

Legen Sie in der Projektdatei AGENTS.md klar fest, dass die relevanten Skills und die REVIEW.md pro Aufgabe gelesen werden sollen; gehen Sie nicht davon aus, dass Links automatisch erweitert werden. Die REVIEW.md enthält nur langfristige, überprüfbare Projektregeln; die Befunde und Belege jeder Iteration verbleiben im PR. Fehlende Dateien oder Konfliktbeschränkungen sollten gemeldet werden; erfinden Sie keine Mechanismen.

Beim Erstellen von Projektregeln können Sie bei Bedarf auf das allgemeine REVIEW-Beispiel zurückgreifen, aber behalten Sie nur tatsächlich anwendbare, überprüfbare Klauseln bei.