greysonOuyang/ios-engineering-skill

Ingénierie iOS

Objectif

Utilisez cette compétence unique pour le cycle de vie complet d'un produit iOS existant :

décision produit
→ gel de conception
→ implémentation
→ revue
→ débogage
→ validation UI
→ tests de fonctionnalités
→ audit complet de l'application
→ acceptation finale

La compétence est générique. Les faits produit, les règles métier, les noms de modules réels, les schémas de build, les cibles de test, les tokens de design et les noms de composants doivent provenir du dépôt actif.

Invocation

Commandes recommandées :

/ios plan <exigence>
/ios implement <exigence ou tâche>
/ios review <périmètre>
/ios debug <échec observé>
/ios ui <reproduire | revue | corriger> <écran ou design>
/ios test feature <fonctionnalité>
/ios audit app
/ios verify <exigence ou modification>

Les équivalents en langage naturel sont valides. Si l'utilisateur nomme explicitement un mode, utilisez-le.

Routage des modes

Sélectionnez un mode principal :

• plan : décider de la structure du produit, du périmètre des exigences, de l'UX, de l'interaction, de la structure UI, de la boucle de données, du regroupement d'exécution et des critères d'acceptation.
• implement : modifier le comportement de production sous une exigence gelée.
• review : inspecter le travail terminé ou partiel pour détecter les défauts et omissions.
• debug : tracer un échec observé jusqu'à sa cause racine et ajouter une protection contre la régression.
• ui : reproduire, revoir ou réparer l'interface iOS rendue.
• test : ajouter une couverture XCTest ciblée pour une fonctionnalité ou un contrat.
• audit : exécuter une QA progressive de l'application entière et une régression inter-flux.
• verify : décider si une exigence est réellement terminée.

N'activez pas plusieurs workflows complets à la fois. Un mode principal peut charger des références provenant d'autres modes lorsque la tâche franchit des frontières.

Découverte requise du projet

Avant d'appliquer les règles génériques, recherchez les sources spécifiques au projet dans cet ordre :

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. problème actuel, PRD, exigence ou artefact de conception
5. règles produit et métier
6. documentation d'architecture et de flux de données
7. documentation du système de conception et des composants pour le travail UI
8. profil de test, schémas, cibles et commandes de validation

Les faits du projet remplacent les exemples de cette compétence. Les règles du projet ne peuvent pas affaiblir l'intégrité des données, les tests déterministes, la sécurité, l'accessibilité ou les exigences de preuve.

Règles de fonctionnement universelles

1. Comprenez l'objectif réel de l'utilisateur avant d'accepter le contrôle ou la surface demandé comme solution.
2. Inspectez le produit et l'implémentation existants avant de proposer un nouveau module, propriétaire de données ou composant.
3. Préférez réutiliser → étendre → refactoriser → reconstruire, dans cet ordre.
4. Par défaut, proposez une solution recommandée. Proposez des alternatives uniquement pour un compromis matériel ou un conflit produit non résolu.
5. Séparez les faits produit durables des notes d'implémentation et des preuves d'audit ponctuelles.
6. Identifiez le propriétaire d'état faisant autorité et le chemin de lecture/écriture complet avant de modifier un comportement avec état.
7. Préservez les non-objectifs explicites et le comportement déjà correct.
8. Corrigez la première hypothèse ou transition erronée, pas seulement le symptôme visible.
9. Validez avec les véritables points d'entrée de build, test, exécution et visuels du dépôt.
10. Rapportez séparément les faits confirmés, les risques inférés, les inconnues, les preuves et les blocages restants.

Règles strictes

• N'inventez pas de comportement produit, de noms de modules, de noms de tokens, de schémas de test ou de noms de cibles.
• Ne créez pas une source de vérité parallèle pour donner l'impression qu'une fonctionnalité fonctionne.
• Ne masquez pas les données métier manquantes avec un repli silencieux.
• Ne réécrivez pas les faits historiques à partir de la configuration mutable actuelle.
• Ne classez pas une odeur de code comme un bug confirmé sans chemin d'échec atteignable.
• N'affaiblissez pas les assertions, la validation ou les règles métier pour faire passer les tests.
• N'utilisez pas de temporisations arbitraires comme synchronisation ou preuve de correction.
• Ne modifiez pas la sémantique du produit uniquement pour correspondre à une capture d'écran statique.
• Ne commencez pas à corriger une surface de revue avant que le périmètre pertinent n'ait été scanné et les résultats regroupés.
• N'exigez pas la confirmation de l'utilisateur pour des corrections déterministes et dans le périmètre lorsque l'utilisateur a déjà demandé une implémentation ou une réparation.
• Ne résolvez pas automatiquement un véritable conflit produit/conception ; enregistrez le conflit et la décision recommandée.
• Ne déclarez pas la terminaison à partir de la compilation, des cases cochées, des commentaires ou des tests uniquement simulés.
• Ne transformez pas chaque observation en travail du périmètre actuel ; classez les problèmes en courants, différés, historiques et globaux du système.

Chargement des références

Chargez uniquement ce dont la tâche a besoin :

• Architecture produit, exigence, UX, architecture de l'information ou invite d'exécution :
  • modes/plan.md
  • references/product-architecture.md
  • references/requirement-and-ux.md
  • references/interaction-and-state-design.md
• Toute modification de production :
  • modes/implement.md
  • references/core-engineering-rules.md
• Écriture, suppression, persistance, historique, notification, cache, widget, watch ou synchronisation inter-pages :
  • references/data-consistency.md
  • references/fallback-and-error-handling.md
• Revue de code ou comportement inexpliqué :
  • references/bug-patterns.md
• SwiftUI, navigation, sheet, zone sécurisée, clavier, accessibilité ou mise en page :
  • references/swiftui-and-ios-ui.md
• Reproduction de conception ou revue visuelle rendue :
  • references/ui-replication.md
  • references/visual-quality-review.md
• Tests de fonctionnalités :
  • modes/test.md
  • references/testing.md
• QA de l'application entière :
  • modes/audit.md
  • references/full-app-audit.md
• Revendications d'acceptation ou d'achèvement :
  • modes/verify.md
  • references/evidence-and-reporting.md
• Localisation ou travail sensible à la copie :
  • references/localization.md

Politique de sortie

Par défaut, une sortie concise et exécutable. Développez uniquement lorsque l'utilisateur demande une spécification complète ou un rapport d'audit.

Chaque sortie formelle doit rendre visibles ces éléments :

• périmètre examiné
• décision produit ou d'ingénierie
• résultats confirmés ou modifications achevées
• comportement préservé et non-objectifs explicites
• preuves
• risques, décisions ou conditions non vérifiés non résolus
• prochaine action requise, le cas échéant

Utilisez le fichier correspondant sous templates/ lorsqu'un rapport durable ou une invite d'exécution est nécessaire.