greysonOuyang/ios-engineering-skill

iOS Engineering

Zweck

Verwenden Sie diesen einzelnen Skill für den gesamten Lebenszyklus eines bestehenden iOS-Produkts:

Produktentscheidung
→ Design-Freeze
→ Implementierung
→ Review
→ Debugging
→ UI-Validierung
→ Feature-Tests
→ App-weites Audit
→ finale Abnahme

Der Skill ist generisch. Produktfakten, Domain-Regeln, echte Modulnamen, Build-Schemes, Test-Targets, Design-Tokens und Komponentennamen müssen aus dem aktiven Repository stammen.

Aufruf

Bevorzugte Befehle:

/ios plan <Anforderung>
/ios implement <Anforderung oder Aufgabe>
/ios review <Umfang>
/ios debug <beobachteter Fehler>
/ios ui <replizieren | review | fix> <Bildschirm oder Design>
/ios test feature <Feature>
/ios audit app
/ios verify <Änderung oder Anforderung>

Natürlichsprachliche Entsprechungen sind gültig. Wenn der Benutzer explizit einen Modus nennt, verwenden Sie diesen.

Modus-Routing

Wählen Sie einen primären Modus:

• plan: Produktstruktur, Anforderungsumfang, UX, Interaktion, UI-Struktur, Datenfluss, Ausführungsgruppierung und Abnahmekriterien festlegen.
• implement: Produktionsverhalten unter einer eingefrorenen Anforderung ändern.
• review: Abgeschlossene oder teilweise Arbeit auf Defekte und Auslassungen prüfen.
• debug: Einen beobachteten Fehler bis zur Ursache zurückverfolgen und Regressionsschutz hinzufügen.
• ui: Gerenderte iOS-Benutzeroberfläche replizieren, überprüfen oder reparieren.
• test: Gezielte XCTest-Abdeckung für ein Feature oder einen Vertrag hinzufügen.
• audit: Gestaffelte app-weite Qualitätssicherung und abteilungsübergreifende Regression durchführen.
• verify: Entscheiden, ob eine Anforderung tatsächlich vollständig ist.

Aktivieren Sie nicht mehrere vollständige Workflows gleichzeitig. Ein primärer Modus kann Referenzen aus anderen Modi laden, wenn die Aufgabe Grenzen überschreitet.

Erforderliche Projekterkundung

Bevor generische Regeln angewendet werden, suchen Sie nach projektspezifischen Quellen in dieser Reihenfolge:

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. aktuelles Issue, PRD, Anforderung oder Design-Artefakt
5. Produkt- und Domain-Regeln
6. Architektur- und Datenfluss-Dokumentation
7. Design-System- und Komponenten-Dokumentation für UI-Arbeiten
8. Test-Profil, Schemes, Targets und Validierungsbefehle

Projektfakten überschreiben Beispiele in diesem Skill. Projektregeln dürfen Datenintegrität, deterministisches Testen, Sicherheit, Barrierefreiheit oder Evidenzanforderungen nicht schwächen.

Universelle Betriebsregeln

1. Verstehen Sie das tatsächliche Benutzerziel, bevor Sie das angeforderte Steuerelement oder die Oberfläche als Lösung akzeptieren.
2. Überprüfen Sie das vorhandene Produkt und die Implementierung, bevor Sie ein neues Modul, einen neuen Datenbesitzer oder eine neue Komponente vorschlagen.
3. Bevorzugen Sie Wiederverwendung → Erweiterung → Refactoring → Neubau, in dieser Reihenfolge.
4. Standardmäßig eine empfohlene Lösung anbieten. Alternativen nur bei einem materialen Zielkonflikt oder ungelöstem Produktkonflikt anbieten.
5. Trennen Sie dauerhafte Produktfakten von Implementierungshinweisen und einmaligen Audit-Nachweisen.
6. Identifizieren Sie den autoritativen Zustandsbesitzer und den vollständigen Lese-/Schreibpfad, bevor Sie zustandsbehaftetes Verhalten ändern.
7. Bewahren Sie explizite Nicht-Ziele und bereits korrektes Verhalten.
8. Beheben Sie die früheste falsche Annahme oder den Übergang, nicht nur das sichtbare Symptom.
9. Validieren Sie mit den tatsächlichen Build-, Test-, Laufzeit- und visuellen Einstiegspunkten des Repositorys.
10. Melden Sie bestätigte Fakten, abgeleitete Risiken, Unbekanntes, Nachweise und verbleibende Blockaden getrennt.

Harte Regeln

• Erfinden Sie keine Produktverhalten, Modulnamen, Token-Namen, Test-Schemes oder Target-Namen.
• Erstellen Sie keine parallele Informationsquelle, um ein Feature scheinbar funktionieren zu lassen.
• Verstecken Sie keine fehlenden Geschäftsdaten mit stillem Fallback.
• Überschreiben Sie keine historischen Fakten aus der aktuellen veränderlichen Konfiguration.
• Klassifizieren Sie keinen Geruch als bestätigten Fehler ohne einen erreichbaren Fehlerpfad.
• Schwächen Sie keine Behauptungen, Validierungen oder Geschäftsregeln, um Tests bestehen zu lassen.
• Verwenden Sie keine willkürlichen Wartezeiten als Synchronisation oder Korrektheitsbeweis.
• Ändern Sie keine Produktsemantik nur, um einem statischen Screenshot zu entsprechen.
• Beginnen Sie nicht mit der Behebung einer Review-Oberfläche, bevor der relevante Umfang gescannt und die Ergebnisse gruppiert wurden.
• Fordern Sie keine Benutzerbestätigung für deterministische, zum Umfang gehörende Korrekturen an, wenn der Benutzer bereits Implementierung oder Reparatur angefordert hat.
• Lösen Sie keinen echten Produkt-/Design-Konflikt automatisch auf; dokumentieren Sie den Konflikt und die empfohlene Entscheidung.
• Erklären Sie keine Vollständigkeit aufgrund von Kompilierung, abgehakten Kästchen, Kommentaren oder reinen Mock-Tests.
• Machen Sie nicht jede Beobachtung zu aktueller Arbeit; klassifizieren Sie aktuelle, aufgeschobene, historische und globale Systemprobleme.

Referenzladung

Laden Sie nur das, was die Aufgabe benötigt:

• Produktarchitektur, Anforderung, UX, Informationsarchitektur oder Ausführungsprompt:
  • modes/plan.md
  • references/product-architecture.md
  • references/requirement-and-ux.md
  • references/interaction-and-state-design.md
• Jede Produktionsänderung:
  • modes/implement.md
  • references/core-engineering-rules.md
• Schreiben, Löschen, Persistenz, Verlauf, Benachrichtigung, Cache, Widget, Watch oder seitenübergreifende Synchronisation:
  • references/data-consistency.md
  • references/fallback-and-error-handling.md
• Code-Review oder unerklärliches Verhalten:
  • references/bug-patterns.md
• SwiftUI, Navigation, Sheet, Safe Area, Tastatur, Barrierefreiheit oder Layout:
  • references/swiftui-and-ios-ui.md
• Design-Nachbildung oder gerenderte visuelle Überprüfung:
  • references/ui-replication.md
  • references/visual-quality-review.md
• Feature-Tests:
  • modes/test.md
  • references/testing.md
• App-weite Qualitätssicherung:
  • modes/audit.md
  • references/full-app-audit.md
• Abnahme oder Vollständigkeitsbehauptungen:
  • modes/verify.md
  • references/evidence-and-reporting.md
• Lokalisierung oder kopiersensitive Arbeit:
  • references/localization.md

Ausgaberichtlinie

Standardmäßig präzise, ausführbare Ausgabe. Nur erweitern, wenn der Benutzer nach einer vollständigen Spezifikation oder einem Audit-Bericht fragt.

Jede formale Ausgabe muss diese sichtbar machen:

• untersuchter Umfang
• Produkt- oder Engineering-Entscheidung
• bestätigte Erkenntnisse oder abgeschlossene Änderungen
• beibehaltenes Verhalten und explizite Nicht-Ziele
• Nachweise
• ungelöste Risiken, Entscheidungen oder unverifizierte Bedingungen
• nächste erforderliche Aktion, falls vorhanden

Verwenden Sie die passende Datei unter templates/, wenn ein dauerhafter Bericht oder Ausführungsprompt benötigt wird.