Menu
AKARI Video（現行 Theia スタック）のタスク契約が要求する検証はしご（L0 / L1 / L2）を実行するときに発動する。タスクの受け入れ条件が「verify 層: L0」「L0+L1」等を指定しているとき、各層で実際に何を・どう叩くかを確認するために読む。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
analyze-project が作る分析レポート（interpretation.json + analysis-report.html）を一次証拠として読み、方針・素材計画・実行をチャットの明示承認で確定したうえで edit.json v0 とオーバーレイ HTML へ落とすスキル。複数素材の編集計画、素材ゼロからの生成計画（質問対話 → plan.json の仮枠タイムライン確定）、分析結果からカットや BGM・SFX・B ロールを決める依頼で使う。
原稿テキストから VOICEVOX（ローカル・ゼロ円の既製声）または fal Qwen3-TTS（自声クローン）でナレーション音声を生成し、edit.json の audio.narration[] へ書き込むスキル。ナレーションを作ってほしいと頼まれたとき、仮ナレ（下書き試聴）が欲しいとき、声プロファイルを新規に作りたいとき、または既存のナレーションをエンジンや声で差し替えたいときに使う。
review.json の open チケット（annotation）を edit.json への実対応 → edit-lint → チケット更新まで型どおりに執行するスキル。「a-0002 と a-0003 に対応して」「open チケット全部に対応して」で発動する。状態機械（open → addressed + response 必須・resolved 不可侵・黙殺禁止）を bin/respond.mjs が原子的に守る QA ループの消費側。
動画素材 1 本から 720p プロキシ、ローカル既定の文字起こし（Mac は macOS SpeechAnalyzer / 共通は whisper.cpp・クラウドは承認制）、視認済みキーフレーム、編集イベント、人物関連トラックを作り、analysis.json v0 にまとめるスキル。新しい撮影素材を取り込むとき、素材単体の編集前分析を頼まれたとき、または edit-plan の前処理として素材ごとの分析が必要なときに使う。
プロジェクト内の素材群（analysis.json）と周辺プロジェクト文脈（intake.json・edit.json・planning/・README・過去 PJ）を読み合わせて interpretation.json（解釈層）を作り、事実 + 素材の読みに限定した読み取り専用の分析レポートを描画するスキル。複数素材プロジェクトの内容を素材横断で把握したいとき、analyze-footage が素材ごとの分析を終えたあとの統合、方向性を決める前に一次情報の欠落（取材質問）を洗い出したいときに使う。edit-plan は方針決めの前提としてこのスキルの出力を読む。
承認済み edit.json と edit-lint PASS を入力に、最終 MP4 の計画、明示承認、ローカル書き出し、ffprobe 検証、キーフレーム視認を完了する。編集が承認済みで、納品用動画の書き出しや最終レンダーを求められたときに使う。
Baseado na classificação ocupacional SOC
| name | verify |
| description | AKARI Video（現行 Theia スタック）のタスク契約が要求する検証はしご（L0 / L1 / L2）を実行するときに発動する。タスクの受け入れ条件が「verify 層: L0」「L0+L1」等を指定しているとき、各層で実際に何を・どう叩くかを確認するために読む。 |
Language: Respond in the user's language — 対話・質問・承認確認・レポートはユーザーの使用言語に合わせる（例: 英語で話しかけられたら英語で応答する）。
タスク契約テンプレート（内部リポ tasks/_template/task.md）が参照する対応表の実体。
発明した定義ではなく、直近タスクの report.md / task.md の実運用から帰納したもの（帰納元は末尾「根拠」節）。
| 層 | 定義 | 判定者 | 現行スタックでの実例 |
|---|---|---|---|
| L0 | 静的・機械的検証。exit code だけで合否が決まる。実機起動・人間の目を要さない | エージェント単独 | ほぼ全タスクで必須の最下層 |
| L1 | 実機観測（自動化）。Electron を実際に起動し、CDP/Playwright で操作・スクショ・性能実測を行う。人間の主観判断を要さず、スクリプトで再現可能 | エージェント単独（スクリプト） | 2026-07-15/16 の shell 系タスクはほぼ全て L0+L1 |
| L2 | 自動化・スクリプトでは判定し切れない層（主観的な視覚品質判断・実配布物でのオーナー最終確認） | 人間（オーナー） | 現行 Theia スタックでは実例なし（下記「L2 について」参照） |
現行 Theia スタックでの実体は apps/shell の npm scripts:
cd apps/shell
PYTHON=/usr/bin/python3 npm install --no-workspaces # 初回・依存更新時のみ
npm run build:ext # tsc -b（6 拡張の型検査 + コンパイル）
npm run lint # eslint "extensions/*/src/**/*.{ts,tsx}"
build:ext と lint が exit 0 = L0 合格の最低ライン。CI（.github/workflows/ci.yml）はこの 2 つを push/PR で自動実行するnpm run build（= build:ext && theia build --mode production）は、フロントエンド/バックエンド/electron のバンドル生成まで含むより厳密な L0 として個々のタスク契約が課すことがある（例: shell-sb-surfaces / shell-sc-project / shell-sd-partner / governance-sanitize）。ただし CI には載せていない（後述「地雷」参照）。タスクで build まで求められたら手元で PYTHON=/usr/bin/python3 npm install --no-workspaces 後、electron の postinstall が npm 11 の allow-scripts ゲートでスキップされて theia build が ENOENT .../electron/dist/version で落ちる点に注意し、echo "<electron のバージョン>" > apps/shell/node_modules/electron/dist/version で回避すること（npm run package/実機起動が要る L1 では、この回避では不十分 — 下記参照）packages/* 配下に触るタスクは各 package.json の build/test スクリプトが L0 の実体になる（waveplan-2026-07-15-sbcd-e5.md §検収ゲート）npm install は electron / @theia/ffmpeg / drivelist / keytar / node-pty 等 11 パッケージの install script を既定でスキップする（npm warn allow-scripts ...）。build:ext / lint は素の TypeScript / eslint 実行であり、これらのネイティブモジュールを必要としないためスキップされたままで問題なく通る（実測済み）。実機を起動する L1 以降で初めて効いてくるPYTHON= を指定せず npm install すると、drivelist の node-gyp rebuild が Homebrew Python 3.14 の pyexpat ABI 不整合（Symbol not found: _XML_SetAllocTrackerActivationThreshold）で失敗し、install 自体が止まる。PYTHON=/usr/bin/python3（Apple 純正 Python）を必ず指定することapps/shell/package-lock.json は意図的に .gitignore 済み（apps/shell/.gitignore 内 package-lock.json）。npm ci は使えない。再現性は Node バージョン固定 + --no-workspaces で確保する（後者が無いとリポ root へ依存が hoist され、実行時間が約 2 倍・依存解決範囲が変わることを実測済み）|| true を付ける現行スタックの L1 は「GUI スクショ必須」という形でほぼ全タスクに課されている
（preview-streaming / shell-s4-tabs / preview-open-repair / project-diff-repair /
shell-s12-preview-tab / shell-sc-repair / shell-strip-menu-repair 等）。
以下は shell-s4-tabs（report.md §6-2）と preview-streaming（report.md §2）で確立・実証済みの再現手順。
cd apps/shell
PYTHON=/usr/bin/python3 npm install --no-workspaces
# electron の postinstall は allow-scripts ゲートでスキップされているため、
# 既存キャッシュから手動展開する（既にダウンロード済みの環境が前提）:
ditto -x -k ~/Library/Caches/electron/<hash>/electron-v<version>-darwin-<arch>.zip \
node_modules/electron/dist
echo "<version>" > node_modules/electron/dist/version
npm run build
templates/project-default/ を作業用一時ディレクトリへコピー（元ファイルは無改変）。検証対象の素材（動画等）が要るタスクは、この中に ffmpeg 等で実素材を生成する（例: preview-streaming は 4K/120 秒/836MB の MP4 を ffmpeg -f lavfi ... で生成し実測に使用。検証後は rm -rf で完全削除しコミットしない）theia start CLI や Playwright の _electron.launch() は不使用 — 後者は argv 解釈に既知不具合があるため）:
node_modules/electron/dist/Electron.app/Contents/MacOS/Electron \
<apps/shell 絶対パス> <隔離ワークスペース絶対パス> \
--remote-debugging-port=<port> --user-data-dir=<隔離ディレクトリ> --no-sandbox
THEIA_CONFIG_DIR=<隔離ディレクトリ> を環境変数で渡し、通常の開発設定と衝突させないplaywright-core を検証用スクラッチディレクトリにのみ npm install（リポジトリ本体には追加しない）し、
chromium.connectOverCDP('http://127.0.0.1:<port>') でアタッチするWebviewWidget は外側 webview.localhost オリジンの iframe → 内側 active-frame という二重入れ子構成を取り、素朴な page.frames() 探索では実コンテンツに届かないことがある。CDP の Page.getFrameTree と Runtime.executionContextCreated イベントの auxData.frameId を突き合わせ、実際の内側 execution context を特定してから Runtime.evaluate で DOM 状態（readyState / currentTime / data-* 属性等）を直接読む自作クライアントが必要になる場合がある（preview-streaming report.md §2 参照）Page.captureScreenshot または Playwright の screenshot API。保存先は検証対象拡張の evidence/<機能名>/*.png、1 枚 500KB 以下が目安ps -o %cpu -p <pid> を 1 秒間隔でサンプリングし GPU/renderer/main プロセスを分離して記録。タイミングは操作前後の CDP イベント/DOM 状態変化で実測（例: readyState>=3 到達までのミリ秒）window.theia.container 経由で Inversify DI コンテナから直接サービスを呼び出し、フロントエンドのガードをバイパスしてもバックエンドが独立して拒否する（多重防御）ことを確認するのも有効（preview-streaming report.md の配信境界検証を参照）ps aux で確認した実 PID を指定して kill（pkill -f のような広いパターンマッチは使わない）。隔離ワークスペース・巨大な生成素材は検証後に完全削除しコミットしないnode_modules: apps/shell/extensions/<ext>/node_modules/ に @theia/* 等が残っていると、apps/shell/node_modules/@theia/core との二重解決で FrontendApplicationConfigProvider のようなモジュール単位シングルトンが分裂し、フロントエンドがプリロード画面のまま無限に止まる（dual-package hazard）。実機起動前に find apps/shell/extensions/*/node_modules -maxdepth 0 を確認し、あれば削除してから apps/shell/ 直下でクリーンリビルドするpackage.json の main フィールドどおり lib/backend/electron-main.js を使う。lib/backend/main.js を直接指定すると BrowserWindow が生成されず /json/list が空のままになる__dirname は開発時と異なる（app.asar/lib/backend 等）。apps/shell 外への相対パス探索を持つ機能は、electron-builder --dir 出力を ELECTRON_RUN_AS_NODE=1 + cwd=/ で実行して検証すること（package-runtime-assets task.md 参照）。開発時 (npm start) だけでの確認は不十分現行 Theia スタックへ移行した直近タスク群（2026-07-15/16、S-A〜S-D・S4/S6/S12・ preview-streaming・preview-open-repair・project-diff-repair・package-runtime-assets・ shell-sc-repair・shell-strip-menu-repair 等）で、L2 が受け入れ条件として課された実例は 一件もない。 いずれも「verify 層: L0 + L1（実機 GUI スクショ必須）」の範囲で完結しており、 自動化された実機観測（L1）が実質的な最高層として運用されている。
L2 は旧 Tauri 実装期の verify スキルで使われていた概念で、当時の実例（帰納元）:
2026-07-15-preview-band-artifact: L2 = 実機での不具合再現・修正確認。加えて「オーナーが実機で帯の消失を確認」というオーナー自身の目視が最終ゲートに使われた2026-07-15-vlog-mvp-edit: 「L2（実機アプリ）未実施」— L1（実書き出し・ffprobe 検証）は完了したが、実機アプリでの目視（プレビュー側の合成が理屈どおりに見えるか）は L2 として区別され、範囲外とされた2026-07-15-decision-cards-runtime: 「実機（Tauri / companion 拡張 webview）での目視は本タスク範囲外（L2 非対象）」— headless Chrome での自動 DOM 検証（L1 相当）と、実アプリ webview での体感確認（L2）を明確に分けているこれらに共通するのは、L2 = 自動化・スクリプトでは判定し切れない層という一線であり、
「実素材を使うかどうか」では区別されない（L1 でも preview-streaming の 836MB 4K 実撮素材のように
実素材を使うことが普通にある）。したがって現行スタックでの L2 は次のように定義する
（現行スタックでの実例が無いため外挿であることを明記する）:
L2 = パッケージ配布物（
electron-builder出力）での実運用シナリオを、視覚的な質感・ 使用感など自動化スクリプトでは判定不能な観点についてオーナー自身が確認し、handoff に記録する層。
上記に当てはまらない限り、現行スタックのタスクは L0+L1 で完結させる（実際の運用がそうなっている）。
ci-and-verify-skill）自身がこの例apps/shell/extensions/** や packages/preview-engine 等、GUI・実行時挙動に影響するコード変更を含むタスクの既定。2026-07-15/16 の shell 系タスクはほぼ全てここに属する対応表・手順は非公開の内部タスク記録（akari-video-internal）の report.md / task.md から帰納したもの
である。内部タスク記録そのものは本リポには置かない方針（docs/design-2026-07-13-agent-native-architecture.md
§3 と同様の扱い）。検証手順そのもの（コマンド・観測対象・既知の地雷）は上記「L0」「L1」節に実行可能な形で
記載済みであり、以下は帰納元タスクの識別のみを示す（すべて非公開）: