mcpField
H
hyperframes-cli

hyperframes-cli

github.com/ryu1845クリエイティブ・メディア016 回インストール1 週間前に更新
リポジトリ

hyperframes-cli について

hyperframes-cliは、HyperFramesプロジェクトの作成、検査、プレビュー、レンダーを行うコマンドラインワークフローです。lintやブラウザ検査、映像確認を経て、承認後に最終レンダーします。

主な機能

  1. 01プロジェクトの初期化と確認
  2. 02カタログ検索とモーションの追加
  3. 03lintとプロジェクト検査
  4. 04スナップショット取得とプレビュー
  5. 05承認済みコンポジションのレンダー

活用シーン

  1. 01新しいHyperFramesプロジェクトの作成
  2. 02編集中のコンポジション検査
  3. 03最終動画の確認とレンダー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ryu1845/hyperframes --skill hyperframes-cli

インストール後、Claude Code で/hyperframes-cliを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
beats.md
cloud.md
cloudrun.md
compare-and-batch.md
doctor-browser.md
init-and-scaffold.md
lambda.md
lint-validate-inspect.md
preview-render.md
upgrade-info-misc.md

詳細

プラグインのインストール: このスキルが HyperFrames プラグイン内にある場合は、セットアップコマンドや最新状態の確認コマンドを実行する前に、プラグインの実行ルールに従ってください。単独でインストールした場合は、以下の更新手順を使用してください。

HyperFrames CLI

プロジェクトの指示にラッパーが指定されていない限り、npx hyperframes ... としてコマンドを実行してください。ラッパーがある場合は、それに従ってください。CLI の実行には Node.js 22 以降と FFmpeg が必要です。

開発の流れ

  1. ひな形を作成: npx hyperframes init <project>(中央に配置された空白状態)。または、サイトをキャプチャします。名前付きの例から始める場合に限り、--example=<name> を指定してください。
  2. 最適な動きを見つける: 依頼にアセット、サウンド、画像、音声、または素早いビジュアル編集が含まれる場合は、計画を提案する前に /media-use を通じて解決してください。それ以外の場合は、モーションを手作業で作成する前に、すでに実現できるプリミティブがないか検索してください:npx hyperframes catalog --query "reveal a headline one line at a time"。思い描いている仕組みではなく、実現したい効果を指定してください。npx hyperframes add <name> でインストールします(/hyperframes-registry を参照)。適合するものが見つからない場合に限り、手作業で作成してください。
  3. 作成: /hyperframes-core を使用してコンポジションを作成します。プロジェクトのタイムライン上に何があるか(トラック、クリップ、開始・終了位置、再生内容)を確認するには、index.html とすべてのサブコンポジションファイルを読む代わりに、npx hyperframes timeline --json を実行してください。ネストされた行には、サブコンポジション内のローカル時間だけでなく、メインタイムライン上の絶対位置を示す absStart/absEnd と、所有元の file が含まれます。テキスト形式よりも --json を優先してください。同じ、またはそれ以上の正確さで、トークンの消費量を抑えられます。出力全体を読まずに一般的な質問に答えるワンライナーは、references/upgrade-info-misc.md を参照してください。
  4. 編集中に素早くフィードバックを得る: 最初の HTML 作成後と構造の変更後に、npx hyperframes lint を実行してください。
  5. 最終チェックを実行: npx hyperframes check を実行してください。ブラウザーを開く前に lint が再実行されます。重複する単独の lint 実行を前置しないでください。注釈付きの概要フレームと問題箇所のクロップを生成するには、--snapshots を追加してください。
  6. サブコンポジションを確認: index.html が data-composition-src をマウントする場合は、中間点のスナップショットをキャプチャし、マウントされた各シーンを確認してください。冒頭 30 秒と報告された問題発生時刻はフル解像度で確認し、コンタクトシートだけで判断せず、細部の形状、テキスト、WebGL のエッジを拡大して確認してください。
  7. 最終的な Studio プレビューを開く: npx hyperframes preview --background を実行し、URL が HTTP 200 を返すことを確認してください。タイムラインプロジェクトの URL をユーザーに渡し、修正またはレンダリングを行うか尋ねてください。レビューが終わるまで起動したままにしてください。
  8. 承認後にのみレンダリング: 反復作業中は --quality draft、最初の本番エンコードでは --quality looks(CLI のデフォルト)、最終納品では --quality delivery を使用してください。
  9. (提案された場合)プロジェクトをデスクトップアプリに渡す: レンダリングの Framey 行が hyperframes open … で終わる場合は、npx hyperframes open [dir] を提案してください。プロジェクトが HyperFrames デスクトップアプリで開かれ、Home に追加されます。Claude Code、Codex、または Grok では、アプリのチャットがこの会話を引き継ぎます。アプリがない場合は終了コード 1 で終了し、ダウンロードリンクを出力します。エージェント向けには --json を指定してください。open が、ユーザーの復帰後に一度 catch-up を実行するよう指示する場合、または何らかのコマンドがそれを示す行で終わる場合は、次の変更を行う前に npx hyperframes catch-up [dir] を実行してください。引き継ぎ後にアプリで依頼・変更された内容が一覧表示されます。古い CLI には catch-up がありません。
  10. 出力を確認: ファイルが存在し、空でないことを確認してください。レンダリング概要の 2 行目(beginframe と screenshot のどちらか、GPU、各ステージの所要時間)を読みます。Linux での screenshot と software gpu の組み合わせは低速です。ffprobe -v error -show_format -show_streams を実行し、長さ(および依頼で指定されている場合は fps)をルートの data-duration と比較してください。プレビューと同じ時刻のデコード済み出力フレームを、クローズアップも含めて目視確認してください。チェックやエンコードが成功しても、キャンバス内のピクセルが正しいとは限りません。
ターン中のプロジェクト履歴

プロジェクトへの書き込みはすべて、取り消し可能なエントリーとして記録されます。次の2つのタイミングでのみ使用し、各ステップでは使用しないでください。

  • ターンの開始時: npx hyperframes history begin --who <your-name> --label "<what you are about to do>" を実行し、続けて npx hyperframes history --since mine --who <your-name> を実行して、前回のターン以降に相手が変更した内容を確認します。相手の編集を活かし、上書きしないでください。
  • チェックに失敗した場合、または相手から悪化したと言われた場合: npx hyperframes history undo --who <your-name> を実行して、自分の最新のターンを取り消します。相手の編集はそのまま残ります。手動で元に戻さないでください。競合がある場合は終了コード 2 で終了し、両方の選択肢を表示します。

各ターンの最後に npx hyperframes history end を実行してください。これにより、自分の書き込みが「アプリ外で変更」として記録されるのを防げます。ターンが開いている間は、10分間書き込みがないと自動的に終了するまで、プロジェクトへの書き込みはすべて自分のものとして扱われます。

クリエイター編集の必須参照

  • ズーム、パンチイン/パンチアウト、リフレーム、カメラ移動、またはキーフレームアニメーションを作成または診断する前に、まず /hyperframes-keyframes を読んでください。
  • hyperframes keyframes を実行する前に、/hyperframes-keyframes を読んでください。このコマンドはアニメーションの軌跡を表示しますが、クリップのカットは診断しません。
  • カット、トリム、スプライス、並べ替え、またはソースのタイミングを編集する場合は、/hyperframes-core を読み、そこで定義されているクリップ/タイムラインの契約に従ってください。
  • 配置済みのオーディオにフェードイン/フェードアウト、クロスフェード、トラックゲイン、音量の自動化、ダッキング、ナレーション用の音量調整、または FX を適用する場合は、/hyperframes-audio を読んでください。クリップの配置や映像のタイミングも変更する場合は、core も読み込んでください。
  • アセット、サウンド、画像、音声、または視覚的な変更をすばやく行う依頼は、計画を提案する前に /media-use を参照してください。 クリエイター編集のマークアップは /hyperframes-core → references/creator-editing-recipes.md からコピーしてください。
# Fast iteration check; repeat while authoring as needed.
npx hyperframes lint

# Required final gate; includes lint.
npx hyperframes check
npx hyperframes preview --background
npx hyperframes render --quality looks --output out.mp4
test -s out.mp4
ffprobe -v error -show_format -show_streams out.mp4

check はまず lint を実行し、続いて1つのブラウザーセッションと1回のシーク処理で、実行時エラー、リクエストの失敗、レイアウト、*.motion.json のアサーション、WCAG コントラストを監査します。継続している問題は終了コードに影響します。一時的な開始時または終了時の問題は参考情報として扱われます。警告も終了判定の対象にするには --strict を使用してください。validate、inspect、layout は互換性のためにエイリアスとして残されていますが、新しい指示やスクリプトでは使用しないでください。

レンダリング前のプレビュー

最終コンポジションのプレビュー(#project/<name>)は、check に合格した後にのみ開き、組み立てられたタイムラインを確認してください。チャット内の計画とストーリーボードボード(boards/storyboard.html、形式は hyperframes-creative/references/storyboard-recipe.md を参照)は、最終動画の承認にはなりません。レンダリングには、必ず hyperframes/references/review-loop.md で定義された最終承認が必要です。

サブコンポジションのスモークテスト

静的監査では、すべてのマウント失敗を検出できるとは限りません。プロジェクトでサブコンポジションを使用する場合は、各ホストスロットについて、少なくとも1つの画面に表示された中間時点をキャプチャしてください。

npx hyperframes snapshot --at <t1>,<t2>,<t3>
# For multiple samples within one scene or interval:
npx hyperframes snapshot --composition <data-composition-id> --frames 8
npx hyperframes snapshot --range 3:5 --frames 8

スタイルが適用されていない小さなコンテンツ、キャンバスサイズのアイコン、欠落したヒーロー要素、またはタイムライン登録のタイムアウトは、レンダリングを妨げるマウント不具合として扱ってください。該当する修正については hyperframes-core/references/sub-compositions.md を参照してください。

エージェントの規約

  • 手作業でモーションを書く前に、カタログを検索してください。 npx hyperframes catalog --query "<the beat, in plain English>"。検索は完全にローカルで行われます。ホスト型のプランもアカウントもなく、クエリのテキストが外部に送信されることはありません。デフォルトでは、アイテム名、タイトル、説明、タグに共通する語彙に基づいて順位付けするため、カタログ独自の表現を使わない言い回しは見つかりません。意味に基づいて順位付けするには、--on-device を追加してください(下記のオフライン階層を参照)。

  • 動画が英語以外でも、クエリは英語で入力してください。 どちらの階層も英語のカタログをインデックス化しているため、別の文字体系でクエリを入力すると検索可能な語句がなく、結果は返されません。動きを英語で説明し、画面上のテキストは動画に必要な言語のままにしてください。No searchable words in query はまさにこの状態を意味しており、コンポーネントが不足しているわけではないため、カタログの不足として報告しないでください。

  • どの階層が回答したかを確認してください。結果が表示されたことから推測してはいけません。 --json では、エンベロープに query、tier(on-device または words)、tier_detail、dropped、unindexed、shown、total、results が含まれます。また、回答した階層でスコアが生成される場合は top_score が、階層の実行を試みたものの実行できなかった場合、または検索結果がなく、より優れた階層を使うにはまだユーザーの同意が必要な場合は warnings が含まれます。words で弱い結果が出るのは想定どおりですが、on-device で同じ結果が出るのはバグです。top_score はオンデバイスの場合のみの値で、しきい値はありません。ランカーはどのクエリに対しても、カタログ全体を何らかの順序で返すため、合否の判定ではなく手掛かりとして読み取ってください。

  • dropped と unindexed は、レジストリとオンデバイスインデックスの間で反対方向に生じるずれであり、クエリの言い換えではどちらも解決できません。 dropped は、レジストリがインストールできない順位付け済みの名前の数を示します。つまり、最も一致度の高い項目が失われています。unindexed は、インデックスからまったく見えないレジストリ内のモーション数を示します。どんなクエリでも、それらは返されません。どちらの場合も、レジストリの更新は解決策ではありません。マニフェストには 24h の TTL があり、自動的に修復されます。一方、ベクトルは別途公開されるアーティファクトであり、~/.hyperframes/catalog/ に取得されます。unindexed が 0 より大きい場合、--on-device を付けて再実行するとそのインデックスが再取得されるため、それをユーザーに案内してください。unindexed が 0 で dropped が 0 より大きい、カバレッジ過剰のみのずれでは再取得は行われません。この場合の解決策は ~/.hyperframes/catalog/ を削除することだけです。どちらの数も結果数ではなく名前の数を示すため、total を超える場合があります。

  • インストールする価値のあるものが見つからなかった場合は、そのことを伝えてください。 npx hyperframes feedback --search-miss "<the query you ran>" --wanted "<the move you needed>" --tier <the tier that answered>。このコマンドを組み立てる必要はありません。catalog --query が入力済みの状態で表示し、すべての --json 検索エンベロープには、クエリと階層が正しく設定済みの report_gap として含まれます。--wanted を入力して送信してください。クエリが外部に送信されるのはこの方法だけです。通常の catalog --query が「何も送信しない」という約束を守るため、意図的に別のコマンドになっています。結果が目的を果たさない場合は、どちらの階層でも報告してください。 オンデバイス階層を待たないでください。利用には同意が必要な 33 MB のダウンロードがあり、ほとんどのエージェントの実行では無効になっているため、待っていると結局まったく報告できなくなります。階層も報告に含まれるため、どちらの種類の不一致かを自分で判断しなくても、語彙の不一致と意味の不一致を区別できます。返されるのは、カタログにまだないモーションの一覧です。インストール数から推測するのではなく、一覧を直接確認してください。重要なのは、想像したアイテム名ではなく、実現したかった効果の表現です。この報告には評価が含まれず、評価指標にも反映されません。

  • オフライン階層を提案してください。黙って有効にしてはいけません。 初回に約 33 MB をダウンロードします(固定リビジョンに固定された、量子化済みの bge-small-en-v1.5 の ONNX ビルドとそのトークナイザー)。さらに、レジストリからカタログのベクトルも取得します。いずれも ~/.hyperframes/ にキャッシュされ、プロジェクトやパッケージには追加されません。キャッシュ後は、何も送信せずに意味に基づいて順位付けします。サイズを明確に伝えて相手の判断を仰ぎ、同意を得てから --on-device を渡してください(プロンプトを省略するには -y を付けます)。対話形式の案内が表示されるのは TTY の場合だけです。--json ではプロンプトが表示されませんが、検索結果がなかった場合は同じ確認事項が warnings に入るため、その配列を確認し、自分でユーザーに判断を仰いでください。ダウンロードの内容、なぜこのモデルなのか、何がマシンの外に送信されるのかを尋ねられた場合は、https://hyperframes.heygen.com/developers/catalog-search を案内してください。

  • エージェントや CI から呼び出す場合は、--json を優先してください。サーバーモードの render、preview、play は通常の JSON 出力を提供しません。ただし、クエリモードの例外として preview --selection --json と preview --context --json があります。

  • doctor --json は常にゼロで終了します。ペイロードに基づいて判定してください。

    npx hyperframes doctor --json | jq -e '.ok' >/dev/null
    
  • 非 TTY モードは自動的に有効になり、中央揃えの空白を生成します。名前付きの例から開始する場合に限り、--example を渡してください。TTY でフラグのみのモードを強制するには、--non-interactive を使用します。

  • 同じ検証ループ内のすべてのコマンドで、同一の HYPERFRAMES_RUN_ID を使用してください。

  • ディスク容量が不足している場合は、npx hyperframes clean を実行してください(最初に一覧を確認するには --dry-run を指定します)。このコマンドは、不要なレンダリングの残骸と、再構築されるアイドル状態のキャッシュを削除します。出力、ソース、または実行中のレンダリングが使用しているものは削除しません。一時的な QC フレームは一時ディレクトリに書き込み、そのディレクトリのうち自分が作成したものだけを削除してください。管理対象のスナップショット実行では、最新の 10 件に加えて現在のエビデンス、最新のエビデンス、レンダリング済みのエビデンスが保持されます。アクティブなキャプチャと、作成から 24 時間未満の実行は保護されます。意図的に残す前後のエビデンスは、保存期限が過ぎる前に管理対象ストレージの外へコピーしてください。.hyperframes を丸ごと削除しないでください。プロジェクトの履歴もそこに保存されています。

  • 対応する警告、変数、CI 条件でレンダリングを制限する必要がある場合は、--strict、--strict-all、--strict-variables を使用してください。

  • shader_unbounded_cosine_pow では、pow(1 - cosine, exponent) の前にコサインを [0, 1] にクランプしてください。下限のみを設定する max では不十分です。ソースの修正と、影響を受ける GPU でのプレビュー/エクスポート検証については、/hyperframes-animation → adapters/three.md を参照してください。リントで認識されるのは静的なシェーダー式のみであり、ソフトウェアレンダリングではハードウェア固有の無効なピクセルを検出できない場合があります。

  • JSON のパスではホームディレクトリが $HOME に置き換えられます。この置き換えを元に戻そうとしないでください。

  • ホスト型クラウドプロジェクトが 200 MB のアップロード制限に近づいた場合、または超えた場合は、cloud render --dry-run --json を実行し、references/cloud.md にある .hyperframesignore の調査手順に従ってください。ファイルサイズが大きいという理由だけでアセットを除外しないでください。

  • チェックに合格したという理由だけでレンダリングを実行しないでください。最後のプレビューで一旦停止し、承認を待ってください。

Studio が指示する編集

ユーザーが「この要素」または現在の選択内容に言及した場合は、推測せずに Studio に問い合わせてください。

npx hyperframes preview --context --json --context-fields selection

selection.target.hfId が利用できる場合はそれを使用し、利用できない場合はセレクターとソースファイルを使用してください。結果が no-selection を報告した場合は、要素をクリックしてから再実行するようユーザーに依頼してください。必要なコンテキスト部分のみを要求してください。計算済みスタイルまたは編集可能なテキストのメタデータが必要な場合に限り、--context-detail full を使用してください。動作の詳細と失敗コードについては、references/preview-render.md を参照してください。

レンダリングの選択肢

用途コマンド
ローカルで素早く反復npx hyperframes render --quality draft
最初の本番エンコードnpx hyperframes render --quality looks --output out.mp4
最終的なローカル納品npx hyperframes render --quality delivery --output out.mp4
再現可能なコンテナレンダリングnpx hyperframes render --docker --strict --output out.mp4
ローカルの変数駆動型バッチレンダリングnpx hyperframes render --batch rows.json --output "renders/{name}.mp4"
HeyGen ホスト型のインフラ不要レンダリングnpx hyperframes cloud render
セルフマネージドの分散 AWS レンダリングnpx hyperframes lambda render <project> --width 1920 --height 1080 --wait
セルフマネージドの分散 GCP レンダリングnpx hyperframes cloudrun render <project> --width 1920 --height 1080 --wait
レンダリングを開始したプロセスが終了すると、レンダリングも停止するため、Ctrl-C を押したりターミナルを閉じたりしても、Chrome が起動したままになることはありません。コマンドがタイムアウトしたり終了したりしたときに、ツールがプロセスグループ全体を終了させる場合、長時間のレンダリングも一緒に停止します。そのようなレンダリングは、HYPERFRAMES_RENDER_DETACHED=1 を指定して独自のプロセスグループで開始します。たとえば、次のようにします(macOS と Linux で動作します)。その後、コマンドの終了を待つのではなく、ログと出力ファイルを確認します。

bash -c 'set -m; HYPERFRAMES_RENDER_DETACHED=1 npx hyperframes render --output out.mp4 < /dev/null > render.log 2>&1 &'

スキルの帰属情報は自動的に設定されるため、上記の例に --skill は必要ありません。ワークフローでスキャフォールドされたプロジェクト(hyperframes init --skill=<workflow>)では、所有するスキルが hyperframes.json に記録され、その後のすべてのレンダリングで匿名テレメトリに引き継がれます。再レンダリング、npm run render、--batch のいずれも対象です。ワークフロー経由で作成されていないプロジェクトにスキル情報を設定する場合に限り、--skill=<slug> を明示的に指定してください(最初のレンダリング時に情報が保存されます)。

ユーザーがローカルの Chrome、FFmpeg、AWS を使わずにホスト型レンダリングを希望する場合は、クラウドレンダリングを使用してください。AWS の所有権が要件の場合に限り Lambda を使用してください。GCP の所有権が要件の場合に限り Cloud Run を使用してください。クラウドでの処理を実行する前に、該当するリファレンスを読んでください。

レンダリングの成功を確認したら、テレメトリが無効になっている場合、またはユーザーがオプトアウトしている場合を除き、フィードバックレポートを 1 件送信してください。

npx hyperframes feedback --rating <0-10> --comment "<specific result or friction>"

問題なく実行できた場合のフィードバックは簡潔にしてください。バグや不便があった場合は、送信前に再現パケットを作成してください。症状の要約だけを送信してはいけません。再実行可能なコマンド(プロジェクトディレクトリからの相対パスを使用してください。フィードバックは公開チャンネルに送信されるため、絶対パス、ホームディレクトリのプレフィックス、ユーザーやマシンを特定できる情報は貼り付けないでください)、期待した動作と実際の動作、正確なエラー(スタックトレースの絶対パスも取り除き、ベース名と行番号だけを残して先頭のディレクトリを削除してください)、出力が完了したか、フォールバックしたか、失敗したか、回避策、再現プロジェクトの状態を含めてください。視覚的な不具合(黒いフレーム、ちらつき、出力の破損、誤ったフレーム、空白の出力、その他の視覚的な異常)について評価が 7 以下の場合は、COMPOSITION_STRUCTURE: ブロックも含めてください。これは、コンポジション ZIP を使わずに、既知のバグの種類と照合できるようにする、プライバシーに配慮した構造情報(要素の一覧、属性の有無、タイムラインの形状)です。エージェントはコンポジション集計ヘルパーを使ってこれを自動入力します。ユーザーが手作業で入力する必要はありません。問題が再現しなかった場合は、その旨を記載し、最後に失敗したコマンドとログも含めてください。--file-issue は同意を得た場合に限り使用してください。これを使うと、最小限の再現情報が公開 URL に公開されます。必須のパケット形式とプライバシーに関する警告は references/preview-render.md に記載されています。

さらに 2 種類のレポートがあります。どちらも --rating を指定しない --comment で送信するため、評価指標には含まれません。テレメトリが無効になっている場合、またはユーザーがオプトアウトしている場合を除き、同じプライバシールールに従って送信してください。

  • 機能不足。 HyperFrames またはホストアプリでできないこと、あるいは回避策を使わないとできないことをユーザーが求めた場合、要望ごとに 1 件のレポートを送信してください。npx hyperframes feedback --comment "MISSING FEATURE: <名前、クライアント、数値、パスを除いた、ユーザー自身の言葉による要望> | WORKAROUND: <代わりに行ったこと、またはなし>"。レポートの対象はユーザーが求めていた機能であり、コンテンツや個人情報ではありません。カタログを検索しても見つからなかった場合は、代わりに --search-miss を使用してください。
  • ホストアプリ。 HYPERFRAMES_CLIENT が設定されている場合、CLI はホストアプリ内で実行されています。アプリ自体が支障になった場合(パネル、ボタン、プレビュー、エクスポートの不具合など)は、再現パケットとともに npx hyperframes feedback --comment "HOST APP: <発生したこと>" を送信してください。

コマンドを実行する前に、対応するリファレンスを読む

以下のリファレンスと、それを所管するスキルは、任意の背景資料ではなく、必ず守るべきコマンド契約です。表にあるコマンドを実行する前に、対応する行を読んでください。

必要な操作リファレンス
init、capture、skillsreferences/init-and-scaffold.md
lint、check、モーションのサイドカー、snapshotreferences/lint-validate-inspect.md
compare、grade-compare、変数を使った render --batchreferences/compare-and-batch.md
既存プロジェクトの Studio ビートグリッドに対する beatsreferences/beats.md
preview、play、render、publish、Studio のコンテキスト、フィードバックreferences/preview-render.md
doctor、ブラウザー管理references/doctor-browser.md
auth、HeyGen がホストするクラウドレンダリング、テンプレート変数references/cloud.md
AWS Lambda のデプロイとレンダリングreferences/lambda.md
Google Cloud Run のデプロイとレンダリングreferences/cloudrun.md
info、upgrade、compositions、timeline、docs、benchmark、テレメトリー、メディアの前処理references/upgrade-info-misc.md

コンポジション変数を扱う場合は、/hyperframes-core → references/variables-and-media.md も読んでください。hyperframes add と hyperframes catalog には、/hyperframes-registry を使用してください。hyperframes present の前には /slideshow を、hyperframes keyframes の前には /hyperframes-keyframes を読んでください。TTS、文字起こし、字幕、背景除去の選択には、/media-use を使用してください。

専門コマンドは、それぞれを所管するワークフローで意図的に説明されています。

npx hyperframes present <project-dir> --port 3004 --no-open
npx hyperframes beats <project-dir> --json
npx hyperframes keyframes <project-dir> --json
npx hyperframes media-treatment --capabilities
npx hyperframes figma asset KEY:10-20

present は、プレゼンターと視聴者の同期に対応した、ナビゲーション可能なデッキを提供します。beats は、references/beats.md で定義されている、単独で使う Studio ビートグリッドユーティリティです。keyframes は、シークに安全なアニメーションとモーションパスの診断情報を表示します。media-treatment は、ローカル映像に対する決定論的なルックを検出、適用、解除します。概要には --capabilities、1 つのファミリーには --capability <name> から始めてください。依頼された処理に対応するルックの選択は /media-use が所管します。figma は asset、tokens、component サブコマンドを使って REST API 経由でインポートし、FIGMA_TOKEN が必要です。モーションとシェーダーのインポートには REST エンドポイントがなく、エージェント専用のため、これらは /figma が所管します。

実行してはいけないコマンド

hyperframes --help にある 2 つの項目はオーサリングのワークフローには含まれておらず、これらを使おうとするとターンを無駄にします。

  • events は、スキルが自身の呼び出しを報告するために使用するテレメトリーエンドポイントです。バンドルされたスクリプトから呼び出すのが理想的です。匿名イベントを送信し、渡された内容に関係なく 0 で終了します。テレメトリーを読み返すためのものではなく、エージェントが手動で呼び出す必要はありません。
  • validate、inspect、layout は、古いスクリプトのために残されている非推奨のエイリアスです。現在も保守されているのは check で、このスキルのすべてのリファレンスが前提としているコマンドです。

ハーネスの残り使用量

動画ワークフローの開始時と、下書きの作成後やレンダリング前などの節目に、npx hyperframes usage --json を実行してください。引き継ぎ時に新たに読み取る場合は、それを開始時の読み取りとして扱えます。--harness claude-code、--harness codex、または --harness grok を指定すると、明示的に選択できます。

既知の結果には、status: "known"、harness、planTier、session、weekly、spend が含まれます。利用可能な各ウィンドウには usedPercent、remainingPercent、resetsAt が含まれ、利用できないウィンドウは null です。planTier は、利用可能な場合は読みやすい形式のサブスクリプションプラン名、そうでない場合は null です。Claude Code は、共有されている5時間と週間のウィンドウを報告します。Enterprise などの従量課金プランにはどちらのウィンドウもなく、代わりに請求期間の利用上限に対する使用済み割合を示す spend が報告されます。この場合、resetsAt は null です。Codex は、利用可能な場合に共有セッションと週間のウィンドウを報告します。Grok は、付属する週間の利用枠を報告し、session は null です。spend を報告するのは Claude Code のみで、他では null です。利用可能なウィンドウがない場合、結果は status: "unknown"、reason: "no_usage_windows" になります。

不明な結果には status: "unknown" と、トークンを含まない reason が含まれます。ログイン情報が見つからない、期限切れ、未対応、曖昧、または読み取り不能な場合や、プロバイダーからの応答を利用できない場合は、不明として返されます。利用枠を推測せず、不明な状態として伝えてください。このコマンドは既存の認証情報を読み取りますが、更新や書き換えは行わず、トークンやテレメトリも出力しません。利用状況はスナップショットであり、利用枠を確保したり、次の動画のコストを見積もったりするものではありません。スコープとワークフローの選択はユーザーに委ねてください。

コメント