greysonOuyang/ios-engineering-skill

iOS 엔지니어링

목적

이 단일 스킬을 기존 iOS 제품의 전체 라이프사이클에 사용하세요:

제품 결정
→ 디자인 확정
→ 구현
→ 리뷰
→ 디버깅
→ UI 검증
→ 기능 테스트
→ 전체 앱 감사
→ 최종 승인

이 스킬은 범용적입니다. 제품 사실, 도메인 규칙, 실제 모듈 이름, 빌드 스킴, 테스트 타겟, 디자인 토큰 및 컴포넌트 이름은 활성 저장소에서 가져와야 합니다.

호출

권장 명령어:

/ios plan <요구사항>
/ios implement <요구사항 또는 작업>
/ios review <범위>
/ios debug <관찰된 오류>
/ios ui <복제 | 리뷰 | 수정> <화면 또는 디자인>
/ios test feature <기능>
/ios audit app
/ios verify <요구사항 또는 변경>

자연어 표현도 유효합니다. 사용자가 명시적으로 모드를 지정한 경우 해당 모드를 사용하세요.

모드 라우팅

하나의 기본 모드를 선택하세요:

• plan: 제품 구조, 요구사항 범위, UX, 상호작용, UI 구조, 데이터 루프, 실행 그룹화 및 승인 기준을 결정합니다.
• implement: 확정된 요구사항 하에서 프로덕션 동작을 변경합니다.
• review: 완료되었거나 부분적인 작업에서 결함 및 누락을 검사합니다.
• debug: 관찰된 오류를 근본 원인까지 추적하고 회귀 방지를 추가합니다.
• ui: 렌더링된 iOS UI를 복제, 리뷰 또는 수정합니다.
• test: 하나의 기능 또는 계약에 대한 집중된 XCTest 커버리지를 추가합니다.
• audit: 단계별 전체 앱 QA 및 교차 흐름 회귀 테스트를 실행합니다.
• verify: 요구사항이 실제로 완료되었는지 결정합니다.

여러 전체 워크플로우를 동시에 활성화하지 마세요. 기본 모드는 작업이 경계를 넘을 때 다른 모드의 참조를 로드할 수 있습니다.

필수 프로젝트 검색

일반 규칙을 적용하기 전에, 다음 순서로 프로젝트별 소스를 검색하세요:

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. 현재 이슈, PRD, 요구사항 또는 디자인 산출물
5. 제품 및 도메인 규칙
6. 아키텍처 및 데이터 흐름 문서
7. UI 작업을 위한 디자인 시스템 및 컴포넌트 문서
8. 테스트 프로파일, 스킴, 타겟 및 검증 명령어

프로젝트 사실은 이 스킬의 예제를 재정의합니다. 프로젝트 규칙은 데이터 무결성, 결정론적 테스트, 안전성, 접근성 또는 증거 요구사항을 약화시킬 수 없습니다.

범용 운영 규칙

1. 요청된 컨트롤이나 표면을 해결책으로 수락하기 전에 실제 사용자 목표를 이해하세요.
2. 새 모듈, 데이터 소유자 또는 컴포넌트를 제안하기 전에 기존 제품과 구현을 검사하세요.
3. 재사용 → 확장 → 리팩토링 → 재구축 순서를 우선시하세요.
4. 기본적으로 하나의 권장 솔루션을 제공하세요. 실질적인 트레이드오프 또는 해결되지 않은 제품 충돌이 있는 경우에만 대안을 제시하세요.
5. 내구성 있는 제품 사실을 구현 노트 및 일회성 감사 증거와 분리하세요.
6. 상태 저장 동작을 수정하기 전에 권위 있는 상태 소유자와 완전한 읽기/쓰기 경로를 식별하세요.
7. 명시적인 비목표(non-goals)와 이미 올바른 동작을 유지하세요.
8. 보이는 증상뿐만 아니라 가장 먼저 잘못된 가정이나 전환을 수정하세요.
9. 저장소의 실제 빌드, 테스트, 런타임 및 시각적 진입점으로 검증하세요.
10. 확인된 사실, 추론된 위험, 미지의 사항, 증거 및 남아있는 차단 요소를 별도로 보고하세요.

엄격한 규칙

• 제품 동작, 모듈 이름, 토큰 이름, 테스트 스킴 또는 타겟 이름을 임의로 만들지 마세요.
• 기능이 작동하는 것처럼 보이게 하기 위해 병렬 진실 공급원(parallel source of truth)을 생성하지 마세요.
• 누락된 비즈니스 데이터를 묵시적인 폴백으로 숨기지 마세요.
• 현재 변경 가능한 설정에서 과거 사실을 다시 작성하지 마세요.
• 도달 가능한 실패 경로 없이 냄새(smell)를 확인된 버그로 분류하지 마세요.
• 테스트를 통과시키기 위해 어설션, 검증 또는 비즈니스 규칙을 약화시키지 마세요.
• 동기화 또는 정확성 증명으로 임의의 sleep을 사용하지 마세요.
• 정적 스크린샷과 일치시키기 위해 제품 의미론을 변경하지 마세요.
• 관련 범위가 스캔되고 결과가 그룹화되기 전에 리뷰 표면을 수정하기 시작하지 마세요.
• 사용자가 이미 구현 또는 수정을 요청한 경우, 결정론적이고 범위 내에 있는 수정에 대해 사용자 확인을 요구하지 마세요.
• 진정한 제품/디자인 충돌을 자동으로 해결하지 말고, 충돌과 권장 결정을 기록하세요.
• 컴파일, 체크박스, 주석 또는 목업 전용 테스트로 완료를 선언하지 마세요.
• 모든 관찰을 현재 범위의 작업으로 전환하지 말고, 현재, 연기된, 이력적 및 전체 시스템 문제로 분류하세요.

참조 로딩

작업에 필요한 것만 로드하세요:

• 제품 아키텍처, 요구사항, UX, 정보 아키텍처 또는 실행 프롬프트:
  • modes/plan.md
  • references/product-architecture.md
  • references/requirement-and-ux.md
  • references/interaction-and-state-design.md
• 모든 프로덕션 변경:
  • modes/implement.md
  • references/core-engineering-rules.md
• 쓰기, 삭제, 지속성, 히스토리, 알림, 캐시, 위젯, 워치 또는 페이지 간 동기화:
  • references/data-consistency.md
  • references/fallback-and-error-handling.md
• 코드 리뷰 또는 설명되지 않은 동작:
  • references/bug-patterns.md
• SwiftUI, 네비게이션, 시트, 안전 영역, 키보드, 접근성 또는 레이아웃:
  • references/swiftui-and-ios-ui.md
• 디자인 재현 또는 렌더링된 시각적 리뷰:
  • references/ui-replication.md
  • references/visual-quality-review.md
• 기능 테스트:
  • modes/test.md
  • references/testing.md
• 전체 앱 QA:
  • modes/audit.md
  • references/full-app-audit.md
• 승인 또는 완료 주장:
  • modes/verify.md
  • references/evidence-and-reporting.md
• 현지화 또는 복사본에 민감한 작업:
  • references/localization.md

출력 정책

기본적으로 간결하고 실행 가능한 출력을 제공하세요. 사용자가 전체 사양 또는 감사 보고서를 요청하는 경우에만 확장하세요.

모든 공식 출력은 다음을 표시해야 합니다:

• 검사된 범위
• 제품 또는 엔지니어링 결정
• 확인된 결과 또는 완료된 변경 사항
• 보존된 동작 및 명시적 비목표
• 증거
• 해결되지 않은 위험, 결정 또는 확인되지 않은 조건
• 필요한 경우 다음 필수 조치

내구성 있는 보고서 또는 실행 프롬프트가 필요한 경우 templates/ 아래의 해당 파일을 사용하세요.