「suno」の検索結果

End-to-end AI video production skill for agentic frameworks. Use when the user asks to make, edit, repurpose, caption, soundtrack, or export videos using HeyGen avatars, Seedance or ByteDance b-roll, OpenAI image generation and editing, AI UGC ads, Remotion, HyperFrames, screen recordings, FFmpeg, captions, ElevenLabs music, Suno, or social-video variants.

日本語の概要は準備中です。原文の説明を表示しています。

HeartMuLa: Suno-like song generation from lyrics + tags.

日本語の概要は準備中です。原文の説明を表示しています。

Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。

Claude Code の過去セッション（transcript JSONL）・設定・運用パターンを cclens と同梱スクリプトで収集し、指定された分析観点に沿って傾向分析と改善案を出す。/session-insights で明示起動されたときのみ使用する。キーワードマッチによる自動起動はしない。起動時に分析観点の指定が必須。

指定したプロジェクト（ghq 管理下の部分一致キー、または直接パス）のディレクトリでブランチを変えずに claude を detached セッション（herdr 管理下なら workspace か専用 session、それ以外は tmux）として起動する。`/project-session` の明示実行専用。

ファイル編集・コマンド実行・調査・複数ツール呼び出しを伴う作業の最終応答時に、指定の日本語Markdownテンプレ（タイトル/解釈の要約/対応内容/影響）で対応内容を報告する。複数ターンに分かれた作業の最終完了時、複数ファイル編集を含む実装完了時、調査・分析タスクの結果報告時、新規ファイル作成を伴う作業の完了時に必ず参照する。単発の質問への即答（ツール呼び出しなし、または1〜2回のRead/Bashのみ）は対象外。

Tutor the user step by step on a plan, implementation, codebase, or topic to pay down understanding debt left by AI tooling. Explicit invocation only.

日本語の概要は準備中です。原文の説明を表示しています。

ISTQB/JSTQB のテスト実装（test implementation）活動を支援するスキル。test-design が導出したテストケースを、実行できる形に具体化する。自動テストなら実行手順（テストコード・テストデータ・テストダブル）をコンパイル/構文レベルの動作確認まで、手動テストなら手順書・テストデータ・環境準備手順を作る。「テストケースを実装して」「テストコードに落として」「テスト手順書を作って」「テストデータ・モックを用意して」と依頼されたときに使う。テスト対象の検証としての実行（結果の解釈・欠陥候補整理）は test-execute の担当でここではしない。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-implement <テスト対象名> で明示的に呼び出されたときのみ使用する。

Quiz the user on a plan, implementation, or codebase to pay down understanding debt left by AI tooling. Explicit invocation only.

日本語の概要は準備中です。原文の説明を表示しています。

GitHub の PR を入力に、変更されたコードやドキュメントを mermaid の図（全体像・関数単位のシーケンス図・参照箇所起点のシーケンス図）で可視化し、短い解説を付けて Markdown ファイルに書き出す。stacked PR では、スタックの全体像と、現在の段を強調した変更の全体像を描く。`/pr-visualize` の明示起動のみ。`--comment` で PR コメントへ投稿（承認必須）。レビューの指摘は行わない。GitHub(gh) 前提。

Pull Request / Merge Request を作成するときに必ず参照する。`gh pr create`/`glab mr create` で PR/MR を作る、コミット済みの作業をレビューに出す、並列・stacked 作業の各ブランチで PR を起こす、といった場面で使う。リポジトリの pull_request_template/merge_request_template を決定論スクリプトで検出して優先し、テンプレの骨組み（見出し・チェックリスト・順序）を改変せず入力箇所を埋めるだけにする（作成前に骨組み照合ゲートで機械検証）。無ければ汎用観点で本文を構成。本文の素材は対象リポジトリの git 差分のみに限定し、他リポジトリ・他タスクの内容を混入させない。draft 既定。head が保護ブランチ（GitHub 上・origin/HEAD の既定ブランチ、main・master・develop・trunk・release 系など）のときだけ push と作成の前にユーザー承認を取り、それ以外は確認せず push して作成する。GitHub(gh) 基本、GitLab(glab) 等にも対応。

ISTQB/JSTQB のテストモニタリング&コントロール（test monitoring and control）活動のうち、モニタリングの「基盤構築」を支援するスキル。進捗・カバレッジ・失敗率・flaky 率・成果物トレーサビリティ（リスク→条件カバー率・条件→ケース化率）などのメトリクスを test-plan の完了基準と紐づけて定義し、プロジェクトの CI/ツール構成を調査した上で計測基盤（CI 設定・集計スクリプト・バッジ等）の実装を支援して test-monitoring.md と実装物を作る。「テストのメトリクスを決めたい」「CI でテスト進捗を可視化したい」「カバレッジや失敗率を計測する仕組みを作りたい」「トレーサビリティを継続計測したい」と依頼されたときに使う。**AI が継続的なモニタリングを代行することはしない（計測は基盤が行う）。集まったデータの分析・傾向判断は対象外**。単発のテスト作成依頼（単にユニットテストを書きたいだけ）も対象外。/test-monitor <テスト対象名> で明示的に呼び出されたときのみ使用する。

非対話セッション（claude-code の remote-control / CI など TTY が無く SSH 鍵パスフレーズを入力できない状況）で git push を通すスキル。remote が SSH URL で `ssh -o BatchMode=yes` による非対話 SSH 認証が実際に通る（agent の鍵・パスフレーズ無しのディスク鍵・macOS キーチェーン鍵のいずれでも可）なら素の SSH push を実行し、非対話 SSH 認証が通らず `git push` が `Permission denied (publickey)` で失敗する場合は、push を HTTPS + gh トークン（credential.helper='!gh auth git-credential'）経由へ自動フォールバックして標準入力なしで実行する。「push して」「リモートに反映して」と頼まれたが SSH 認証が使えない、push が publickey で弾かれた、remote-control から push したい、といった場面で使う。`/gh-push` で明示起動も可。GitHub(gh) 前提。

非対話セッション（claude-code の remote-control / CI など TTY が無く SSH 鍵パスフレーズを入力できない状況）で git fetch / pull を通すスキル。remote が SSH URL で `ssh -o BatchMode=yes` による非対話 SSH 認証が実際に通る（agent の鍵・パスフレーズ無しのディスク鍵・macOS キーチェーン鍵のいずれでも可）なら素の SSH fetch を実行し、非対話 SSH 認証が通らず `git fetch`/`git pull` が `Permission denied (publickey)` で失敗する場合は、取り込みを HTTPS + gh トークン（credential.helper='!gh auth git-credential'）経由へ自動フォールバックして標準入力なしで実行する。「fetch して」「pull して」「リモートの変更を取り込んで」「最新を取ってきて」と頼まれたが SSH 認証が使えない、fetch/pull が publickey で弾かれた、remote-control からリモートの更新を取り込みたい、といった場面で使う。gh-push の取り込み（incoming）版。`/gh-fetch` で明示起動も可。GitHub(gh) 前提。

GitHub Actions の CI 失敗を調査するスキル。失敗した run / PR / job の URL（例: https://github.com/OWNER/REPO/actions/runs/RUNID、…/pull/PR、…/job/JOBID）や run_id・PR 番号を貼られて「このCIが失敗している、原因を調査して」「ビルド/テストがコケた、なぜ落ちたか調べて」「workflow が failed、修正案を出して」「job のログを見て」と頼まれたら必ず使う。WebFetch では github.com のログは取れない（PreToolUse hook が差し戻し、HTML しか返らない）ため、gh（`gh run view --log-failed` / `gh run view --job` / `gh pr checks` / `gh api`）で失敗ジョブ・ステップと失敗ステップのログだけを決定論スクリプトで収集し、失敗原因を特定して修正案を提示する。GitHub Actions 以外（GitLab CI 等）や、URL がログではなくソース閲覧目的のときは対象外。GitHub(gh) 前提。`/gh-ci-investigate` で明示起動も可。

修正と再レビューを繰り返して指摘を潰し切る収束ループを求められたときに必ず使用する。「レビューを収束させて」「指摘ゼロまでレビューして」「レビューと修正を繰り返して」「レビュー対応を回して」「指摘が無くなるまで直して」など、反復レビューの意図があればスキル名や「収束」の語が無くても発火する。単発の「レビューして」(1 回のレビュー報告で足りる依頼)は diff-review の領分でこのスキルは使わない。修正対象は fix 指摘のみで、improvement(改善提案)は修正せず見送り一覧に残す。`/review-converge [--until <閾値>]` で明示起動も可。

git reset（HEAD / ブランチポインタの移動）の安全運用ルール。reset --hard は未コミット変更をどこにも残さず消せる唯一の日常操作であり、git reset を 1 つでも実行する前に必ず本スキルを参照する。「reset して」「巻き戻して」「直前のコミットを取り消して」「コミットをやり直したい」「変更を全部捨てて」「HEAD を◯◯に戻して」と依頼される、rebase-flow の失敗から backup へ復旧する、reflog から復元する、といった場面すべてが対象。決定論スクリプトで失われるもの（外れるコミット・push 済み範囲・消える未コミット変更）を判定 → 計画提示 → ユーザー承認 → safety branch 作成（arm）→ 実行 → 検証、のゲートを固定化する。plugin hooks の git-guard により arm なしの git reset は機械的にブロックされる。unstage 目的なら reset ではなく git restore --staged を使う。

ISTQB/JSTQB のテスト計画（test planning）活動を支援するスキル。テスト対象のプロダクトリスク（product risk）を発生可能性×影響度で識別・評価し、それを根拠にテストアプローチ（どこを厚くテストするか）・開始基準（entry criteria）・完了基準（exit criteria）を定めた test-plan.md を作る。「テスト計画を立てて」「テスト戦略を決めたい」「何をどこまでテストすべきか整理して」「リスクベースでテスト範囲を決めたい」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-plan <テスト対象名> で明示的に呼び出されたときのみ使用する。

git rebase / git pull --rebase を伴う操作の安全運用ルール。履歴書き換えは復旧不能な事故になり得るため、rebase 系コマンドを 1 つでも実行する前に必ず本スキルを参照する。「rebase して」「main に追従して」「ブランチを最新化して」「コミットをまとめて / 整理して」「squash して」「fixup を畳んで」「履歴をきれいにして」「force-push して」と依頼される、PR 前に履歴を整える、コンフリクト解消のために rebase する、といった場面すべてが対象。決定論スクリプトによるガードレール判定（保護ブランチ・push 済み範囲・子ブランチ・進行中操作・コンフリクト予測）→ 計画提示 → ユーザー承認 → backup ブランチ作成 → 非対話実行 → range-diff / tree 同一性による機械検証、のゲートを固定化する。plugin hooks の git-guard により backup 作成（解錠）なしの git rebase は機械的にブロックされる。

ユーザーからのファイル出力依頼（分析結果・調査レポート・ログ抜粋・要約・ドラフト・一時的なメモなど）に応えて新規ファイルを作成するときの出力先ルール。プロジェクト直下の`tmp-agents/`への出力命名規則を含む。調査結果やレポートを保存するとき、ドラフトを作るとき、ユーザー向けの一時成果物を書き出すときに必ず参照する。ただし、プロジェクト本体のソースコード作成、既存ファイルの編集、プロジェクト規定のドキュメント（docs/配下等）出力は対象外。

ISTQB/JSTQB のテスト完了（test completion）活動のうち、テスト実行結果の評価と完了基準（exit criteria）判定を支援するスキル。テスト実行ログ（test-execution-log.md）と test-plan の完了基準を突き合わせ、完了とみなせるかを判定した test-summary-report.md を作る。テスト完了時の最終レポートにも、テスト途中の中間評価にも使える。「テスト結果をまとめて」「完了基準を満たしたか判定して」「テストレポートを書いて」「今どこまでテストが進んだか評価して」と依頼されたときに使う。単発のテスト作成依頼（単にユニットテストを書きたいだけ）は対象外。/test-report <テスト対象名> で明示的に呼び出されたときのみ使用する。

PR マージ後のローカル後片付け（worktree / ブランチ / tmux セッションの削除と main の最新化）を、収集 → 計画提示 → 承認 → 実行 → 検証のゲートで定型化する。`/post-merge-cleanup [PR番号|ブランチ名]...` の明示実行専用。

プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。

Nix パッケージがバイナリキャッシュから降ってこずローカルビルドになる原因を調査する。