greysonOuyang/ios-engineering-skill

iOSエンジニアリング

目的

既存のiOSプロダクトの完全なライフサイクルにこの単一のスキルを使用します：

プロダクト意思決定
→ 設計凍結
→ 実装
→ レビュー
→ デバッグ
→ UI検証
→ 機能テスト
→ アプリ全体監査
→ 最終受入

このスキルは汎用的です。プロダクトの事実、ドメインルール、実際のモジュール名、ビルドスキーム、テストターゲット、デザイントークン、コンポーネント名はアクティブなリポジトリから取得する必要があります。

呼び出し

推奨コマンド：

/ios plan <要件>
/ios implement <要件またはタスク>
/ios review <スコープ>
/ios debug <観測された障害>
/ios ui <replicate | review | fix> <画面またはデザイン>
/ios test feature <機能>
/ios audit app
/ios verify <要件または変更>

自然言語による同等表現も有効です。ユーザーが明示的にモードを指定した場合は、そのモードを使用します。

モードルーティング

1つのプライマリモードを選択します：

• plan: プロダクト構造、要件範囲、UX、インタラクション、UI構造、データループ、実行グループ化、受入基準を決定します。
• implement: 凍結された要件の下でプロダクション動作を変更します。
• review: 完了した作業または部分的な作業に欠陥や省略がないか検査します。
• debug: 観測された障害を根本原因まで追跡し、回帰防止を追加します。
• ui: レンダリングされたiOS UIを複製、レビュー、または修正します。
• test: 1つの機能または契約に焦点を当てたXCTestカバレッジを追加します。
• audit: 段階的なアプリ全体のQAとクロスフロー回帰テストを実行します。
• verify: 要件が実際に完了したかどうかを判断します。

複数の完全なワークフローを同時に起動しないでください。タスクが境界をまたぐ場合、プライマリモードは他のモードからリファレンスを読み込むことがあります。

必要なプロジェクト発見

汎用ルールを適用する前に、プロジェクト固有のソースを次の順序で検索します：

1. .agent/project-profile.md
2. docs/project/ios-engineering-profile.md
3. docs/ENGINEERING-SKILL-PROFILE.md
4. 現在のIssue、PRD、要件、または設計成果物
5. プロダクトおよびドメインルール
6. アーキテクチャおよびデータフローのドキュメント
7. UI作業のためのデザインシステムおよびコンポーネントドキュメント
8. テストプロファイル、スキーム、ターゲット、検証コマンド

プロジェクトの事実は、このスキル内の例よりも優先されます。プロジェクトルールは、データ整合性、決定論的テスト、安全性、アクセシビリティ、エビデンス要件を弱めることはできません。

普遍的な運用ルール

1. 提案されたコントロールやサーフェスをそのまま解決策として受け入れる前に、実際のユーザーゴールを理解します。
2. 新しいモジュール、データオーナー、コンポーネントを提案する前に、既存のプロダクトと実装を検査します。
3. 再利用 → 拡張 → リファクタリング → 再構築 の順序を優先します。
4. デフォルトでは1つの推奨ソリューションを提示します。材料となるトレードオフや未解決のプロダクト競合がある場合のみ代替案を提供します。
5. 耐久性のあるプロダクト事実を、実装ノートや1回限りの監査エビデンスから分離します。
6. ステートフルな動作を変更する前に、信頼できる状態オーナーと完全な読み取り/書き込みパスを特定します。
7. 明示的な非ゴールとすでに正しい動作を保持します。
8. 目に見える症状だけでなく、最も早い誤った仮定または遷移を修正します。
9. リポジトリの実際のビルド、テスト、ランタイム、ビジュアルエントリポイントで検証します。
10. 確認された事実、推測されるリスク、未知の事項、エビデンス、残っているブロッカーを別々に報告します。

ハードルール

• プロダクトの動作、モジュール名、トークン名、テストスキーム、ターゲット名を勝手に作り出さない。
• 機能を動作しているように見せるために、並列の真実源を作成しない。
• サイレントフォールバックで不足しているビジネスデータを隠さない。
• 現在の可変設定から履歴的事実を書き換えない。
• 到達可能な障害パスなしに、スメルを確定バグとして分類しない。
• テストを通すためにアサーション、バリデーション、ビジネスルールを弱めない。
• 同期や正しさの証明として任意の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/ 下の該当ファイルを使用します。