greysonOuyang/ios-engineering-skill

Engenharia iOS

Propósito

Use esta habilidade única para o ciclo de vida completo de um produto iOS existente:

decisão do produto
→ congelamento de design
→ implementação
→ revisão
→ depuração
→ validação de UI
→ teste de funcionalidade
→ auditoria de todo o aplicativo
→ aceitação final

A habilidade é genérica. Fatos do produto, regras de domínio, nomes reais de módulos, esquemas de build, alvos de teste, tokens de design e nomes de componentes devem vir do repositório ativo.

Invocação

Comandos preferenciais:

/ios plan <requisito>
/ios implement <requisito ou tarefa>
/ios review <escopo>
/ios debug <falha observada>
/ios ui <replicar | revisar | corrigir> <tela ou design>
/ios test feature <funcionalidade>
/ios audit app
/ios verify <requisito ou alteração>

Equivalentes em linguagem natural são válidos. Se o usuário nomear explicitamente um modo, use-o.

Roteamento de modo

Selecione um modo primário:

• plan: decidir estrutura do produto, escopo do requisito, UX, interação, estrutura de UI, loop de dados, agrupamento de execução e critérios de aceitação.
• implement: alterar comportamento de produção sob um requisito congelado.
• review: inspecionar trabalho concluído ou parcial em busca de defeitos e omissões.
• debug: rastrear uma falha observada até sua causa raiz e adicionar proteção contra regressão.
• ui: replicar, revisar ou reparar UI iOS renderizada.
• test: adicionar cobertura XCTest focada para uma funcionalidade ou contrato.
• audit: executar QA de aplicativo completo em etapas e regressão de fluxo cruzado.
• verify: decidir se um requisito está realmente completo.

Não ative vários fluxos de trabalho completos ao mesmo tempo. Um modo primário pode carregar referências de outros modos quando a tarefa ultrapassa limites.

Descoberta de projeto necessária

Antes de aplicar regras genéricas, pesquise fontes específicas do projeto nesta ordem:

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. issue atual, PRD, requisito ou artefato de design
5. regras do produto e de domínio
6. documentação de arquitetura e fluxo de dados
7. documentação do sistema de design e componentes para trabalho de UI
8. perfil de teste, esquemas, alvos e comandos de validação

Fatos do projeto substituem exemplos nesta habilidade. Regras do projeto não podem enfraquecer integridade de dados, testes determinísticos, segurança, acessibilidade ou requisitos de evidência.

Regras operacionais universais

1. Entenda o objetivo real do usuário antes de aceitar o controle ou superfície solicitado como a solução.
2. Inspecione o produto e a implementação existentes antes de propor um novo módulo, proprietário de dados ou componente.
3. Prefira reutilizar → estender → refatorar → reconstruir, nessa ordem.
4. Padrão para uma solução recomendada. Ofereça alternativas apenas para uma troca material ou conflito de produto não resolvido.
5. Separe fatos duráveis do produto de notas de implementação e evidências de auditoria pontuais.
6. Identifique o proprietário autoritativo do estado e o caminho completo de leitura/escrita antes de modificar o comportamento com estado.
7. Preserve não-objetivos explícitos e comportamento já correto.
8. Corrija a suposição ou transição errada mais antiga, não apenas o sintoma visível.
9. Valide com os pontos de entrada reais de build, teste, tempo de execução e visuais do repositório.
10. Relate fatos confirmados, riscos inferidos, desconhecidos, evidências e bloqueadores restantes separadamente.

Regras rígidas

• Não invente comportamento do produto, nomes de módulos, nomes de tokens, esquemas de teste ou nomes de alvos.
• Não crie uma fonte de verdade paralela para fazer uma funcionalidade parecer funcionar.
• Não oculte dados de negócios ausentes com fallback silencioso.
• Não reescreva fatos históricos a partir da configuração mutável atual.
• Não classifique um cheiro como um bug confirmado sem um caminho de falha alcançável.
• Não enfraqueça asserções, validações ou regras de negócio para fazer testes passarem.
• Não use sleeps arbitrários como sincronização ou prova de correção.
• Não altere a semântica do produto meramente para corresponder a uma captura de tela estática.
• Não comece a corrigir uma superfície de revisão antes que o escopo relevante tenha sido varrido e os achados agrupados.
• Não exija confirmação do usuário para correções determinísticas e dentro do escopo quando o usuário já solicitou implementação ou reparo.
• Não resolva automaticamente um conflito genuíno de produto/design; registre o conflito e a decisão recomendada.
• Não declare conclusão a partir de compilação, caixas marcadas, comentários ou testes apenas com mock.
• Não transforme toda observação em trabalho do escopo atual; classifique problemas atuais, adiados, históricos e de sistema global.

Carregamento de referências

Carregue apenas o que a tarefa precisa:

• Arquitetura do produto, requisito, UX, arquitetura de informação ou prompt de execução:
  • modes/plan.md
  • references/product-architecture.md
  • references/requirement-and-ux.md
  • references/interaction-and-state-design.md
• Qualquer alteração de produção:
  • modes/implement.md
  • references/core-engineering-rules.md
• Gravação, exclusão, persistência, histórico, notificação, cache, widget, watch, ou sincronização entre páginas:
  • references/data-consistency.md
  • references/fallback-and-error-handling.md
• Revisão de código ou comportamento inexplicado:
  • references/bug-patterns.md
• SwiftUI, navegação, sheet, safe area, teclado, acessibilidade ou layout:
  • references/swiftui-and-ios-ui.md
• Reprodução de design ou revisão visual renderizada:
  • references/ui-replication.md
  • references/visual-quality-review.md
• Testes de funcionalidade:
  • modes/test.md
  • references/testing.md
• QA de aplicativo completo:
  • modes/audit.md
  • references/full-app-audit.md
• Aceitação ou alegações de conclusão:
  • modes/verify.md
  • references/evidence-and-reporting.md
• Localização ou trabalho sensível a cópia:
  • references/localization.md

Política de saída

Padrão para saída concisa e executável. Expanda apenas quando o usuário pedir uma especificação completa ou relatório de auditoria.

Cada saída formal deve tornar visível:

• escopo examinado
• decisão de produto ou engenharia
• achados confirmados ou alterações concluídas
• comportamento preservado e não-objetivos explícitos
• evidência
• riscos não resolvidos, decisões ou condições não verificadas
• próxima ação necessária, se houver

Use o arquivo correspondente em templates/ quando um relatório durável ou prompt de execução for necessário.