audit
免费プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない(codex-review / cross-review を使う)。
中文简介正在准备中。当前显示原文说明。
AVFoundation (AVPlayer / AVPlayerLayer / AVPlayerItemVideoOutput / AVAsset) の落とし穴・文書化されていない実装挙動・debugging チェックリストを集約した reference skill。
Swift / Objective-C で AVPlayer を使った動画再生 / seek / scrub / frame stepping を実装・debug するときに発火。VLCKit ではなく **AVFoundation 系** の問題に特化。
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
AVPlayer / AVPlayerLayer / AVPlayerItemVideoOutput / AVAsset まわりの 公式仕様だけでは 読み取れない実装挙動 と debug 手順 を集約する skill。Apple Developer Documentation を引いても載っていない「やってみないと分からない」落とし穴が中心。
以下のいずれかに該当したら本 skill を必ず一度通す:
ユーザーが見ている現象 (= 映像 / UI / 音声) を 直接観測 する手段を、修正コードを書く 前に必ず通す。log の数値 (= playback clock / cached currentTime) だけでは「ユーザーが見て いる frame」と乖離していることが頻繁にある。
具体的:
AVPlayerLayer の表示 frame 更新タイミングを観測AVPlayerItemVideoOutput.copyPixelBuffer(forItemTime:itemTimeForDisplay:) の itemTimeForDisplay を log に出して、AVPlayer の playback clock との乖離を測るAVFoundation 系の問題に当たったら、最低限以下を WebFetch で取得 / 確認する:
https://developer.apple.com/documentation/avfoundation/...)経験則 / Stack Overflow ベースで進めると、Apple が後から仕様を変えた時に振り回される。
AVPlayer.seek(to:tolerance:) の I-frame 着地は 実装依存landedMinusTarget=21ms (= ジャスト)、
別 click では landedMinusTarget=-712ms (= 0.7 秒ズレ) と挙動が分かれたAVPlayerItemVideoOutput.copyPixelBuffer の itemTimeForDisplay は GOP 由来forItemTime で要求した時刻に対して、itemTimeForDisplay は 「forItemTime 以前で
取得可能な最も近い frame の時刻」 を返すitemTimeForDisplay=4551.233s
(= 着地点 -280ms = GOP 内の前 I-frame) が返ることがあるAVPlayer.currentTime() と「実際に画面に表示されている frame の時刻」は
別物。click seek が「動かなかったように見える」原因はここに集約することが多いAVPlayer.currentTime() は Main thread から呼ぶと deadlock しうるavPlayer.currentTime() を呼ぶと MediaToolbox 内部の
pthread_mutex に詰まって UI 完全停止addPeriodicTimeObserver の closure 内で cached value を保持し、Main thread
からは cached を参照するAVFoundationVideoPlayer.swift の
currentTime プロパティ周辺コメント参照AVPlayerItemVideoOutput が attach されて
いると AVPlayer pipeline が frame display を駆動する mode になるc845249 で確認)AVPlayerItem.status / AVPlayer.timeControlStatus 等の KVO callback、
AVPlayer.seek(to:completionHandler:) の completion は 任意スレッド で fire するTask { @MainActor [weak self] in ... } で MainActor へ hop するaddPeriodicTimeObserver(forInterval:queue:using:) で queue: .main を指定した
closure は確実に main thread で fire する → MainActor.assumeIsolated で hop なし可addPeriodicTimeObserver は seek 中も fire するcompletionCachedAgeMs で測ること)automaticallyWaitsToMinimizeStalling = true (default) の挙動rate=0 で待機 → buffer 戻り → resumefalse に設定しても改善しない事例も観測されている (VLCMultiVideoPlayer issue 332 Step 2)映像 / 再生問題が出たら、修正コードを書く前に以下を確認する:
display field を log に出している?: AVPlayerItemVideoOutput.copyPixelBuffer
の itemTimeForDisplay を log に追加。current (= playback clock) と乖離しているかユーザー報告: 「シークバーを click すると一瞬戻ってから同じ位置で再生される」
landedMinusTarget=0ms)AVPlayerLayer が表示する frame は GOP 内の前 I-frame (= display=4551.233s、
着地 4551.513s から -280ms 前)display field が出ていたが、私 (Claude) は最後まで見落としたAVPlayer.currentTime と「実表示 frame」は別物itemTimeForDisplay の意味は最初から分かったVLCMultiVideoPlayer リポジトリ(旧配置 ~/src/my-products/apps/vlc-multi-video-player/ は 2026-07-03 時点でこのマシンに存在しない。参照する前に mdfind -name AVFoundationVideoPlayer.swift 等で所在を確認すること)
VLCMultiVideoPlayer/VideoPlayer/AVFoundationVideoPlayer.swift (= AVPlayer 実装本体)VLCMultiVideoPlayer/VideoPlayer/AVPlayerSeekDiagnostics.swift (= 計測 log)issues/pending/332-bug-high-rate-playback-frame-stutter.md (= rate ≥ 2.5x の stutter 問題)issues/done/333-bug-click-seek-perceived-no-op.md (= click seek 体感問題、本 skill の主要事例)Apple Developer Documentation:
関連 skill:
swift-vlc-player: 削除済み (= VLCKit 専用、本プロジェクトでは未使用)ios-app-developer: iOS 全般 (= AVFoundation 個別の落とし穴は本 skill 側に集約)crash-log-analyzer: AVPlayer 系 crash の解析swift-vlc-player skill を
削除して本 skill に置き換え。还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない(codex-review / cross-review を使う)。
中文简介正在准备中。当前显示原文说明。
このセッションで行った変更をコミットする。「コミットして」「commit」「/c」で発火。push はしない/クレデンシャルは混入させない。
中文简介正在准备中。当前显示原文说明。
ディレクトリ・レイヤーごとに置いた CLAUDE.md と README.md が実体 (コード・コマンド・構成) とずれていないかを点検し、裏の取れた乖離だけを直す。引数で対象のディレクトリを任意に指定できる (省略時は repo 全体)。「CLAUDE.md を refresh して」「README が古くないか見て」「claude-md-refresh」「/claude-md-refresh」で発火。issues/ の更新漏れは issue-writeback / issue-sync の担当で、この skill は扱わない。
中文简介正在准备中。当前显示原文说明。
Codex が設計・実装を担い、Claude が要件確定・成果物の検証・反復・commit/push を管理する。「codex に書かせて」「codex メインで実装」「codex-drive」で発火。大きめの機能・移植・プロトコル実装向け。余剰トークンを厚く使う運用も選べる。
中文简介正在准备中。当前显示原文说明。
タスク着手時に codex にリードしてもらうワークフロー。codex に設計/方針を主導(リード)させ、その方針に沿って Claude が実装し、実装後は codex で設計適合・実装正当性・敵対的(red team)の 3 観点でレビューする。余っている codex トークンを積極的に消費したい時に使う。「codexにリードしてもらって」「設計から codex に任せて」「タスクを codex 主導で」「codex-lead」「/codex-lead」で発火。
中文简介正在准备中。当前显示原文说明。
codex exec review を基本に、必要なら codex exec を使ってコード変更のレビューを依頼し、指摘事項を報告する。通常 / 厳しめ (--strict) / 敵対的 (--adversarial、実装を壊しにいく red team) の 3 モードを持つ。「codexでレビューして」「codex-review」「/codex-review」「敵対的にレビューして」で発火。Codex 単体での単独レビュー用途。複数エージェント並行レビューは cross-review、差分ではなくコードベース全体の監査は audit を使う。
中文简介正在准备中。当前显示原文说明。