AGENT SKILL

build-music-assets

Build staged instrumental and supplied-lyric tracks through the independent MUSIC pipeline with exact lyric rights, native provenance, full-track listening and separate runtime promotion.

License 许可
MIT
最近更新
2026-11-08
Stars
★ 4
Forks
3

01 前言 Front Matter

name
build-music-assets
engines
[ "AGNOSTIC" ]
description
Build staged instrumental and supplied-lyric tracks through the independent MUSIC pipeline with exact lyric rights, native provenance, full-track listening and separate runtime promotion.

02 资源文件 70

03 SKILL.md 正文

Build Music Assets

When to use

Use for instrumental and supplied-lyric music. Route sound effects/ambience to AUDIO and spoken speech/cloning to VOICE. MUSIC loads independently alongside the selected visual workflow without replacing STYLE.md.

Workflow

  1. Resolve this skill and resolve-media-pipeline.sh --modality instrumental or supplied-lyrics. Read optional MUSIC.md, shared MEDIA.md and .media/pipelines/music/PIPELINE.md. Configure only the requested missing contract. Configuration and advertised capabilities do not prove native/provider readiness.
  2. Define an hephaera-music-brief/v1 using the schema/examples. Record instrumental/song intent, purpose, caption with mood/instrumentation/structure, explicit provider, whole 10..600 second duration, variations, spatialization/loop intent, exact installation/settings and finite budgets. For supplied lyrics preserve exact UTF-8 text/order and source-backed lyricsRights; require supported language and exact per-item lyric hashes. Never write or revise lyrics automatically.
  3. Use music-pipeline.sh brief, init/revise and read-only status/doctor. Preserve task/domain/asset/version identities and rejected/failed ancestry. Setup planning is dry-run; installation, license acceptance and generation are separate authorizations. Ordinary discovery loads no model.
  4. LOCAL dispatch delegates the exact verified Bubo music request using cuda:0/bfloat16/no offload, guidance 1, 1..8 steps, nonnegative int32 seeds and the shared approval/attempt root. Planning LM, automatic lyrics, reference audio, stems, mastering/editing, normalization and fallback are disabled or unsupported. Current-task prompt and lyric generation permission are required. CLOUD uses actual provenance import; unavailable unattended execution never selects LOCAL.
  5. validate rechecks exact native ancestry, build/catalogue identities, complete 48000Hz stereo output measurements, actual music/conditioning settings, disabled planning/normalization and disclosed cleanup. Keep raw amplitudes and threshold failures. Metadata proves neither acoustic lyric fidelity nor musical quality; missing authoritative analysis stays ineligible.
  6. Record actual complete-track human listening for intended instrumental/vocal content, brief, artifacts and head/tail; songs require every supplied line reviewed. Intended loops require a separate actual seam verdict. Bind the complete current output set, fingerprint, human source, reviewer and reasons. An instrumental cannot satisfy a song; old/synthetic evidence is not current acceptance.
  7. Hand off through the compatible selected-engine owner using actual playback, load/dispose, spatialization/loop and format/budget evidence. Record separate current-task distribution permission and rehash its source plus lyric-rights sources. Generation-only MUSIC requires no invented style or engine.
  8. Promote only after current technical/content/runtime evidence and separate explicit exact-output/target authorization. Shared no-overwrite copying/recovery retains intents and failures. Missing permission/readiness/evidence keeps outputs staged; source delivery grants no asset promotion.

Output

  • Immutable briefs/versions with exact lyrics, source rights, provider and native identities.
  • Staged candidates, technical reports and actual complete-track/line/loop review.
  • Separately reviewed target handoff and explicitly authorized promotion receipt when requested.

Guardrails

  • Preserve one physical approval-bound native ledger across domains/tasks/workspaces; never replenish an existing candidate/revision allowance.
  • Preserve original tracks and lyrics. Do not infer generation/distribution permission from license metadata or historical approval.
  • Do not fabricate human verdicts, CUDA readiness, allocator/driver measurements or quality claims from hashes.
  • Stop an unavailable selected path; no silent provider, device, precision, backend or workflow fallback.

04 同仓库更多 Skills

TimothyMeadows
TimothyMeadows/Hephaera

verify-web3-game-lifecycle

Verify a game's selected Web3 asset, wallet, ownership and trading lifecycle with contract properties, canonical recovery, actual target evidence and separate release readiness.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

verify-onchain-game-assets

Verify exact on-chain game collection ownership and quantities at canonical blocks, reconcile inventory events, and design honest match admission. Use for ERC721/ERC1155 inventory, reorg recovery, reservations, or transfer-during-match rules.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

plan-web3-game-assets

Define an opt-in Ethereum, Base or Immutable game-asset lifecycle, including token identity, supply, rights, custody, game eligibility and chain-specific dependencies.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

integrate-game-wallets

Integrate explicit player-wallet connection, scoped SIWE authentication, authority invalidation and reviewed target-specific handoff without application-held player keys.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

integrate-game-asset-trading

Integrate explicitly selected game asset settlement with exact unsigned intents, scoped approvals, idempotent operations and canonical receipt reconciliation. Use for NFT listing, buying, cancellation, retries or marketplace integration.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

build-evm-game-contracts

Author and verify host-owned EVM game collections and explicit mint, burn, craft or admin rules with pinned Solidity tooling. Use for contract source and deployment candidates; deployment and player signing require separate authorization.

★ 4