greysonOuyang/ios-engineering-skill

Ingeniería iOS

Propósito

Usa esta única habilidad para el ciclo de vida completo de un producto iOS existente:

decisión de producto
→ congelación de diseño
→ implementación
→ revisión
→ depuración
→ validación de UI
→ pruebas de funcionalidad
→ auditoría de toda la aplicación
→ aceptación final

La habilidad es genérica. Los hechos del producto, las reglas de dominio, los nombres de módulos reales, los esquemas de compilación, los objetivos de prueba, los tokens de diseño y los nombres de componentes deben provenir del repositorio activo.

Invocación

Comandos preferidos:

/ios plan <requisito>
/ios implement <requisito o tarea>
/ios review <alcance>
/ios debug <fallo observado>
/ios ui <replicar | revisar | reparar> <pantalla o diseño>
/ios test feature <funcionalidad>
/ios audit app
/ios verify <requisito o cambio>

Los equivalentes en lenguaje natural son válidos. Si el usuario nombra explícitamente un modo, úsalo.

Enrutamiento de modos

Selecciona un modo primario:

• plan: decidir estructura del producto, alcance de requisitos, UX, interacción, estructura de UI, bucle de datos, agrupación de ejecución y criterios de aceptación.
• implement: cambiar el comportamiento de producción bajo un requisito congelado.
• review: inspeccionar trabajo completado o parcial en busca de defectos y omisiones.
• debug: rastrear un fallo observado hasta su causa raíz y añadir protección contra regresión.
• ui: replicar, revisar o reparar la UI renderizada de iOS.
• test: añadir cobertura XCTest enfocada para una funcionalidad o contrato.
• audit: ejecutar QA de toda la aplicación por etapas y regresión de flujos cruzados.
• verify: decidir si un requisito está realmente completo.

No actives varios flujos de trabajo completos a la vez. Un modo primario puede cargar referencias de otros modos cuando la tarea cruza límites.

Descubrimiento requerido del proyecto

Antes de aplicar reglas genéricas, busca fuentes específicas del proyecto en este orden:

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. issue, PRD, requisito o artefacto de diseño actual
5. reglas del producto y de dominio
6. documentación de arquitectura y flujo de datos
7. documentación del sistema de diseño y componentes para trabajo de UI
8. perfil de pruebas, esquemas, objetivos y comandos de validación

Los hechos del proyecto anulan los ejemplos de esta habilidad. Las reglas del proyecto no pueden debilitar la integridad de los datos, las pruebas deterministas, la seguridad, la accesibilidad ni los requisitos de evidencia.

Reglas operativas universales

1. Comprender el objetivo real del usuario antes de aceptar el control o la superficie solicitada como solución.
2. Inspeccionar el producto y la implementación existentes antes de proponer un nuevo módulo, propietario de datos o componente.
3. Preferir reutilizar → extender → refactorizar → reconstruir, en ese orden.
4. Por defecto, una solución recomendada. Ofrecer alternativas solo para un compromiso material o conflicto de producto no resuelto.
5. Separar los hechos duraderos del producto de las notas de implementación y la evidencia de auditoría única.
6. Identificar el propietario del estado autorizado y la ruta completa de lectura/escritura antes de modificar el comportamiento con estado.
7. Preservar los no objetivos explícitos y el comportamiento ya correcto.
8. Reparar la suposición o transición incorrecta más temprana, no solo el síntoma visible.
9. Validar con los puntos de entrada reales de compilación, prueba, ejecución y visuales del repositorio.
10. Informar por separado hechos confirmados, riesgos inferidos, incógnitas, evidencia y bloqueadores restantes.

Reglas estrictas

• No inventar comportamiento del producto, nombres de módulos, nombres de tokens, esquemas de prueba ni nombres de objetivos.
• No crear una fuente de verdad paralela para que una funcionalidad parezca funcionar.
• No ocultar datos empresariales faltantes con un respaldo silencioso.
• No reescribir hechos históricos a partir de la configuración mutable actual.
• No clasificar un indicio como un error confirmado sin una ruta de fallo alcanzable.
• No debilitar afirmaciones, validaciones ni reglas de negocio para que las pruebas pasen.
• No usar pausas arbitrarias como sincronización o prueba de corrección.
• No alterar la semántica del producto solo para que coincida con una captura de pantalla estática.
• No comenzar a reparar una superficie de revisión antes de que se haya escaneado el alcance relevante y se hayan agrupado los hallazgos.
• No requerir confirmación del usuario para correcciones deterministas dentro del alcance cuando el usuario ya solicitó implementación o reparación.
• No resolver automáticamente un conflicto genuino de producto/diseño; registrar el conflicto y la decisión recomendada.
• No declarar finalización a partir de compilación, casillas marcadas, comentarios o pruebas solo simuladas.
• No convertir cada observación en trabajo del alcance actual; clasificar problemas actuales, diferidos, históricos y del sistema global.

Carga de referencias

Cargar solo lo que la tarea necesita:

• Arquitectura del producto, requisito, UX, arquitectura de la información o indicación de ejecución:
  • modes/plan.md
  • references/product-architecture.md
  • references/requirement-and-ux.md
  • references/interaction-and-state-design.md
• Cualquier cambio de producción:
  • modes/implement.md
  • references/core-engineering-rules.md
• Escritura, eliminación, persistencia, historial, notificación, caché, widget, watch o sincronización entre páginas:
  • references/data-consistency.md
  • references/fallback-and-error-handling.md
• Revisión de código o comportamiento inexplicable:
  • references/bug-patterns.md
• SwiftUI, navegación, sheet, área segura, teclado, accesibilidad o diseño:
  • references/swiftui-and-ios-ui.md
• Reproducción de diseño o revisión visual renderizada:
  • references/ui-replication.md
  • references/visual-quality-review.md
• Pruebas de funcionalidad:
  • modes/test.md
  • references/testing.md
• QA de toda la aplicación:
  • modes/audit.md
  • references/full-app-audit.md
• Afirmaciones de aceptación o finalización:
  • modes/verify.md
  • references/evidence-and-reporting.md
• Localización o trabajo sensible a copia:
  • references/localization.md

Política de salida

Por defecto, salida concisa y ejecutable. Expandir solo cuando el usuario solicite una especificación completa o informe de auditoría.

Cada salida formal debe hacer visibles estos elementos:

• alcance examinado
• decisión de producto o ingeniería
• hallazgos confirmados o cambios completados
• comportamiento preservado y no objetivos explícitos
• evidencia
• riesgos, decisiones o condiciones no verificadas no resueltas
• próxima acción requerida, si la hay

Usar el archivo correspondiente en templates/ cuando se necesite un informe duradero o una indicación de ejecución.