実装に入る前に型や関数の形、モジュール構成を複数案から設計し、選んだ設計を実装中も基準にして、形が合わなければ設計から見直すスキルです。
- 機能実装前に型や構成を設計したいとき
- 複数の設計案を比較したいとき
- 実装中の回避策が増え設計を見直したいとき
直前のやり取り以降に起きた作業や未対応項目を、成果物に基づく短い無音スライド動画にまとめ、動画の下に対応待ちの呼び出しを示します。
Catch the user up like /ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /ketchup-video.
実行スコア 未検証
インストール方法を見る/ketchupのように直近の作業状況を伝える際、要約文や静止画の代わりに短い無音動画を作ります。対象期間は、この呼び出しの直前にユーザーが書いたメッセージ以降です。スクリーンショット、録画、差分、データなど実際の成果物を使い、最大10枚のスライドで、完了・実行中・失敗・未確認の状態を示します。各スライドは一つの要点に絞り、同じ図を変化させながら、矢印や強調、動きで変更点を伝えます。動画の下には対応待ちの呼び出しをテキストで並べます。
会話を追えていなかった間の作業を、文章だけでなく視覚的に把握したいときに向いています。変更の前後や複数の選択肢、PRの状態などを成果物に基づいて確認したい場合にも使えます。
/ketchup-videoで、直近の作業を動画でまとめてください」動画は無音の横長形式でレンダリングします。作業リポジトリの外で動画を作成・レンダリングすることが、参照先の/ketchupにある読み取り専用ルールの例外として記載されています。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Follow /ketchup, but show what happened in a short silent video instead of its summary and visuals. Its window starts at the last message the user wrote before /ketchup-video, not before any earlier /ketchup. Writing and rendering the video, outside the repo, is the one exception to its read-only rule. The reply is ketchup's opening sentence, the embedded video, one line naming any work left that you can do yourself, and the action items. When the video shows a call's options, call each option by the name the video gives it. If the render fails, say so in one line and give only the calls.
Use the screenshots, recordings, diffs, and data the work produced, not the chat's prose about them. Before you draw, write the one sentence the user should leave with and one line per slide. Drop each slide that does not change what the user knows. Use at most 10 slides, and fewer is better. Neither note goes in the reply.
Each slide makes one point. Build the slides on one picture and change it from slide to slide, rather than cut to an unrelated one. A color or shape means the same thing on every slide. Show the work in pictures, such as how a system works, a PR stack with each PR's state, a before and after of a fix, or options side by side. Point at what changed with arrows, highlights, and motion. A slide is never a bullet list, a status list, a table, or boxes with nothing connecting them.
Keep text to the minimum. Put each label on the thing it names, in plain words a person would say, not tags like "Tests: pass". Never caption what a picture shows, and never give a fact twice, across slides or in the text under them.
Show what came of each thing the user asked for, and whether it is done, still running, failed, or not checked. Never show something done that still waits on the user. Show any bug found and fixed on the way. If a visible change has no screenshot, say so on its slide and name what changed on screen. Draw only from facts you have. Never invent a number, and never draw a screen you did not capture.
Render one silent landscape video, such as an mp4, with motion between slides. Every frame is the slide itself, edge to edge. Make the frames from the slides, never by recording a screen. Hold each slide long enough to read its words, at least one second for each three words it adds. Words inside a screenshot do not count. Before you embed the video, look at one frame from each slide in the rendered file, and count the words it adds against its hold in that file. Fix any slide you cannot read in that time, render again, and check again.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
実装に入る前に型や関数の形、モジュール構成を複数案から設計し、選んだ設計を実装中も基準にして、形が合わなければ設計から見直すスキルです。
同じ依頼に複数の案を並行して作り、基準に沿って比較したうえで、最良案に他案の優れた部分を統合し、成果物を検証します。
利用者の仕事の進め方や好みを整理し、エージェントが従う個人用の「-mode」スキルを作成・更新します。
ベンチマークの速度差を報告する前に、ボトルネック、条件、誤り、再現性、実際に処理が行われたかを証拠に基づいて点検します。
変更差分の外にある影響先や見落としやすい破損リスクを調べ、実際のコードを動かして安全性の根拠を確かめます。
直前の返答を、専門用語を避けた短く自然な言葉に言い換えます。説明が難しく感じるときや、要点を人同士の会話のように伝え直したいときに使えます。