메뉴
iOS 実装・修正タスクで、動作や見た目を確認して「できました」と報告するときの手順。 ビルドを登録し、スクショ・録画を証拠としてゲートに受理させてから報告する。 「動作確認」「スクショで確認」「QA」「直りました」「できました」の場面で自動適用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | gate-loop |
| description | iOS 実装・修正タスクで、動作や見た目を確認して「できました」と報告するときの手順。 ビルドを登録し、スクショ・録画を証拠としてゲートに受理させてから報告する。 「動作確認」「スクショで確認」「QA」「直りました」「できました」の場面で自動適用。 |
| user-invocable | true |
ping で確認。応答がなければユーザーに claude-gate install を依頼)mcp__plugin_claude-gate_gate__*、直接接続なら mcp__gate__*)。以下では register_build 等のツール名だけで書く/mcp reconnect <サーバー名> をユーザーに依頼して再接続すればその場で一覧が更新される(セッションの開き直しは不要)。スキルを更新した場合は /reload-pluginsゲートが受理した観測だけが「確認した」の根拠になる。 受理されていないスクショ・録画をもとに「確認しました」「直りました」と報告してはならない。スクショで何かを確かめたつもりでも、シミュレータに古いビルドが残っていれば、見ているのは別物の画面である(実際に起きた事故)。ゲートはこれを ID 照合で機械的に検出する。
リポジトリのルートに gate.yaml があれば、作業前に読む。env(検証環境の前提: 依存サービス・起動引数)と worksite(作業場を開く手順: xcodegen generate 等)はここに宣言されている。無ければデフォルトのままで動く。
テスト生成物が gitignore されているか確認する(.deriveddata/ や SPM の .build/ 等)。追跡されたままだと run_check の実行が作業場を汚し、以後のビルド登録が全部 dirty になる(実際に起きた)。
作業1つにつき、最初に報告を開いて「何が動くと言うつもりか」を宣言する:
open_report(
worksitePath: <今の worktree のルート>,
title: <作業名(日本語の日常語。例「時間帯あいさつ+日付表示」)>,
behaviors: [
{ behavior: <動くと言っている動作(文で書く)>,
change_kind: <変更の種類(語彙から選ぶ)>,
check: <使う確かめ方(語彙から選ぶ)> },
...
]
)
→ reportId と、動作の番号(1始まり)が返る
変更の種類の語彙:
logic(ロジック)/ appearance(見た目)/ interaction(操作・遷移)/ motion(動き)/ data(データ)/ contract(契約)/ config(設定)/ system(連携)
確かめ方の語彙(これ以外は拒否される):
compile(コンパイル)/ unit_test(ユニットテスト)/ screenshot(スクショ)/ interaction_log(操作記録)/ ui_test(UIテスト)/ video(録画)/ launch_check(起動確認)/ device_report(実機レポート)/ human_check(人間確認)
device_report は、実機でしか検証できない動作(keychain 復元・StoreKit 課金・プッシュ通知配信・上書きアップデート E2E 等)のための確かめ方。実機で走ったアプリ自身が状態を print したセルフレポートを証拠にする(手順 3c)。シミュレータでは成立しない検証(見えないこと台帳に載っている課金・通知等)も、実機のセルフレポートなら覆える。
passline を変更する(git に記録が残る)— エージェントが勝手に変更しないinteraction。静的スクショで覆いたいからと「〜が表示される」に宣言の側を弱めない(実際に起きた過ち)。状態の表示を確かめたいなら、最初からそう書く証拠にするビルドはコミット → ビルド → 登録の順で作る。未コミットの状態からビルドすると、記録に dirty: true が残り、どのソースの証拠か曖昧になる。ループ中の試行錯誤ビルドは自由(登録しなければ記録されない)。
XcodeBuildMCP でビルドしたら、成果物のパス(structured output の data.artifacts.appPath、旧版なら get_sim_app_path)を使って:
register_build(
worksitePath: <今の worktree のルート>,
appPath: <.app のパス>,
scheme: <スキーム名>
)
→ buildId が返る。以後の証拠はこの buildId に紐づける
添付の前に、観測ファイルの中身を自分の目で確認する。 スクショに写っているのがスケルトン画面や読み込み失敗画面なら、それは対象の動作の証拠ではない(実際にあった)。確認すべき動作が画面に写っていることを確かめ、note に「何が写っているか」を書いてから添付する。
アプリの検証には環境の前提があることが多い(例: Debug ビルドはローカル API サーバー必須、--screenshot-* 起動引数で認証スキップ + 固定データ表示)。プロジェクトの README / AGENTS.md / 設定を先に確認する。
スクショ・録画・UI スナップショットを確認の根拠にするときは、必ず:
attach_evidence(
worksitePath: <同上>,
buildId: <手順2の buildId>,
kind: "screenshot" | "ui_snapshot" | "video",
file: <観測ファイルのパス>,
simulatorUdid: <観測したシミュレータの UDID>,
bundleId: <対象アプリの bundle ID>,
note: <何を観測したか>,
reportId: <手順0の reportId>,
behaviorIndex: <この観測が確かめる動作の番号(1始まり)>
)
reportId と behaviorIndex はセットで付ける(どの動作の証拠かを宣言する)。報告に属さない一時的な観測なら両方省略できるが、作業の証拠は原則すべて報告に紐づける。
ゲートはシミュレータ内の実物アプリからビルドID を計算し直し、登録した ID と照合してから受理する。
keychain 復元・StoreKit 課金・プッシュ通知配信・上書きアップデートの E2E は、シミュレータでは成立しない。実機に入れたアプリ自身に状態を print させ、その console 出力を証拠にする(check: device_report で宣言した動作向け):
アプリに自己報告を仕込む: 起動時などに、自分の Mach-O UUID と検証したい状態を print する。UUID は出所照合に使うので必ず buildUUID=<uuid> の形で出す。#dsohandle を使うのが要点 — Xcode 16+ の Debug ビルドは実コードを <App>.debug.dylib に置き、メイン実行ファイルはビルド間で不変のスタブになる。#dsohandle は「このコードが載っている image」(Debug では .debug.dylib)を指すので、ビルドごとに変わる実コードの UUID を報告できる(_dyld_get_image_header(0) でメイン実行ファイルを見ると、内容の違うビルドが同じ UUID になり古いビルドを受理してしまう):
import MachO
// dso 既定引数の #dsohandle は呼び出し元(アプリのコード)が載っている image を指す
func currentBuildUUID(dso: UnsafeRawPointer = #dsohandle) -> String {
let header = dso.assumingMemoryBound(to: mach_header_64.self)
var cursor = UnsafeRawPointer(header).advanced(by: MemoryLayout<mach_header_64>.size)
for _ in 0..<header.pointee.ncmds {
let cmd = cursor.assumingMemoryBound(to: load_command.self)
if cmd.pointee.cmd == LC_UUID {
return UUID(uuid: cursor.assumingMemoryBound(to: uuid_command.self).pointee.uuid).uuidString
}
cursor = cursor.advanced(by: Int(cmd.pointee.cmdsize))
}
return "unknown"
}
print("buildUUID=\(currentBuildUUID())")
// 続けて検証したい状態も print(例: print("[SPIKE] keychain restored: \(restored)"))
実機に入れたのと同じ .app を register_build する(ゲートが実行バイナリの LC_UUID を記録する。ここで登録した .app と実機に install した .app が同じであること)
実機でアプリを起動し、console を回収する(xcrun devicectl device process launch --console 等)。回収したテキストをファイルに保存する
device_report として添付する:
attach_evidence(
worksitePath: <同上>,
buildId: <手順2の buildId>,
kind: "device_report",
file: <回収した console テキストのパス>,
deviceUdid: <実機の UDID>,
bundleId: <対象アプリの bundle ID>,
note: <何を実機で確かめたか>,
reportId: <reportId>,
behaviorIndex: <動作の番号>
)
ゲートはレポート本文の buildUUID= 行を、登録ビルドの Mach-O UUID と照合してから受理する(実機からは .app を取れないので、中身ハッシュではなく UUID で「同じビルドか」を確かめる)。buildUUID= 行が無い・別ビルドの UUID なら拒否される。
compile / unit_test / ui_test の確かめは、自分でコマンドを回して「緑でした」と言うのではなく、ゲートに実行させて証拠化する:
run_check(
worksitePath: <同上>,
check: "unit_test", # compile / unit_test / ui_test
reportId: <手順0の reportId>,
behaviorIndex: <動作の番号>
)
checks に宣言されている必要がある(無ければ拒否されるので、人間に gate.yaml への宣言を依頼するか、正しいコマンドを調べて gate.yaml に追加してコミットする)swift test を回すのは自由(速い確かめ)。証拠にするのは run_check の実行だけ全動作に証拠を付けたら、自分で「できました」と判断せず、ゲートに判定させる:
judge(worksitePath: <同上>, reportId: <手順0の reportId>)
→ 合格 / 不合格 / 確認できず(動作ごとの理由つき)
共有(feature ブランチへの git push・下書きPR の作成 gh pr create --draft)は自由領域 — ゲートを通さずいつでもできる(前提: デフォルトブランチは GitHub 側のブランチ保護で守られている)。
submit(worksitePath: <同上>, reportId: <合格した報告>)
→ 「検証したソース(sourceSha)を受け入れた」と記録する。記録だけの状態遷移 —
git や gh のコマンドは実行しない。報告は終着(提出済み)になる
提出のあと(PR 運用): gh pr ready <ブランチ名> を実行する — hook がデーモンに「ブランチ先端の sha に一致する提出済みの報告があるか」を照会し、一致すれば通る(一致しなければ遮断され、fix が返る)。PR 番号や URL 指定では先端を解決できないのでブランチ名(または対象ブランチをチェックアウトして引数なし)で実行する。
取り込み(merge・デフォルトブランチへの push)は人間だけの操作。エージェントは gh pr merge / デフォルトブランチへの直接 push / 非ドラフトの PR 作成を行わない(hook が遮断する)。main 直運用のリポジトリでは、提出の記録までがエージェントの仕事で、push は人間がダッシュボードの「取り込み待ち」を確かめて行う。
nextSteps が次に可能な操作を示す。迷ったらそれに従うnote が付いていたら読む。「既登録」「既添付」= べき等な再呼び出しで、記録は最初の登録時の事実のまま(再実行は安全、記録は増えない)Do:
gh pr ready を hook のガード経由で行うclaude-gate confirm)claude-gate confirm を実行してよい(note には人間が何をどう確認したかを書く。判断者は常に人間)claude-gate forget は人間の CLI)Don't:
claude-gate confirm / POST /api/confirm)を実行して「確認できず」を解消する(判断は人間だけのもの。勝手な実行は監査ログに残る)gh pr merge・非ドラフトの PR 作成・デフォルトブランチへの直接 push はしない(取り込みは人間)。gh pr ready は submit で提出を記録してから — 記録なしの実行は hook が遮断する