Update to NewsTune Studio

{
  "description": "Use when a user asks to inspect, find, create, continue, or schedule a NewsTune podcast; turn project progress or source material into an episode; monitor generation; make ChatGPT/Codex an ongoing podcast production partner; or replies to a pending NewsTune charge preview with a bare approval such as 'I approve', 'yes', or '同意扣除 20 credits'. Uses OAuth-connected tools, one exact approval for a private multi-episode batch, sequential durable generation, and direct episode-page links.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 369
    },
    {
      "relative_path": "references/tools.md",
      "size_in_bytes": 11508
    }
  ],
  "name": "newstune-agent-api",
  "skill_md_contents": "---\nname: newstune-agent-api\ndescription: \"Use when a user asks to inspect, find, create, continue, or schedule a NewsTune podcast; turn project progress or source material into an episode; monitor generation; make ChatGPT/Codex an ongoing podcast production partner; or replies to a pending NewsTune charge preview with a bare approval such as 'I approve', 'yes', or '同意扣除 20 credits'. Uses OAuth-connected tools, one exact approval for a private multi-episode batch, sequential durable generation, and direct episode-page links.\"\n---\n\n# NewsTune Studio\n\nUse only the OAuth-connected NewsTune tools bundled with this plugin. Never ask the user for a NewsTune API key, Auth0 token, cookie, password, or raw credential, and never call private HTTP endpoints directly.\n\nTypical triggers include “show my existing podcasts,” “continue this series,” “turn this project update into an episode,” “make my computer a podcast production partner,” and a short approval that continues an immediately preceding NewsTune preview, such as “同意扣除 20 credits.”\n\n## Production frame\n\nTreat NewsTune as an ongoing podcast production system, not only a one-time audio renderer. It can discover a user's existing shows, create private episodes from source material or an approved script, track generation, choose accessible voices, and publish an exact approved scope.\n\nThe host AI may also collect project-progress inputs from connected tools or local files and run recurring automations. A schedule belongs to the host AI unless a NewsTune scheduling tool is explicitly available. Confirm the full recurring execution contract once when the schedule is created or materially changed; covered runs then generate, upload, poll, and publish automatically without another user turn.\n\n## Workflow\n\n1. Use `get_account_overview` to verify the connection, plan features, credit balance, and server-owned prices.\n2. Clarify the topic, audience, language, use case, desired format, source policy, voice preference, and whether this is a one-off or ongoing series. Ask only for missing decisions.\n3. Use `list_podcast_series` before creating a series. Follow `nextOffset` until it is `null` when identifying all possible matches.\n4. Prefer an existing series when the user says “my podcast,” “continue,” “add an episode,” or supplies a matching title. Use `get_podcast_series` to confirm its ID, hosts, format, visibility, persistent `customPrompts`, and recent episodes.\n5. For source material:\n   - Summarize local/private sources in the host AI and use `script_to_audio` when the user does not want raw content sent to NewsTune.\n   - Use `material_to_podcast` only for material the user agrees may be sent to NewsTune and, when relevant, researched on the open web.\n   - Never upload secrets, credentials, unrelated private files, or an entire local project by default.\n6. Reuse hosts and persistent `customPrompts` already approved in this conversation. Combine missing host, source, settings, and credit choices into one confirmation; do not request separate host or prompt approvals. Call `preview_podcast_series_creation` with the complete final payload, show its exact charge, retain its opaque `previewId` internally, and use `confirm_podcast_series_creation` under that unchanged approval without asking again. New plugin-created series and episodes are always private. Do not choose the compatibility-only `create_podcast_series` tool for this workflow.\n7. After an episode is queued, poll `get_generation_status` until `succeeded` or `failed`. When it succeeds, treat transcript media as part of the episode refresh: call `get_episode_transcript_context`, re-evaluate existing user-provided and sourced web assets against the new canonical segments, validate/import or prepare/finalize only the assets that are actually needed, and call `replace_episode_media_cues` with the returned `revisionId`. Do not generate new images, video, or attachment audio. If sourcing or validation fails, do not replace the active cue revision; report the incomplete media refresh explicitly. Return the exact episode-page link and explain that a private link requires NewsTune sign-in.\n\nWhen the user asks to replace an already generated episode in place, use `regenerate_podcast_episode`, not a new episode number. Its first call is a read-only billing preview; interactive execution requires the exact fresh approval fields, while a scheduled execution must remain inside the unchanged recurring contract. After regeneration succeeds, the same transcript-media refresh is mandatory before any publication.\n\nRead [references/tools.md](references/tools.md) for the podcast, dashboard, and transcript-media tool contracts.\n\n## Persistent production brief\n\nBefore `preview_podcast_series_creation`, convert the confirmed interview into all applicable `customPrompts` fields: `gatherContent`, `generatePlan`, `conductResearch`, `generateScript`, `supplementScript`, `deeperResearch`, `generateFinalScript`, and `generateCoverImage`. These prompts are durable series memory for another agent or device, so keep concrete source rules, update cadence, audience/use case, host interaction, show structure, required and prohibited content, verification, privacy, final checks, and visual identity. Do not collapse them into vague style adjectives, invent missing choices, or store credentials and raw private documents.\n\nBefore every `create_podcast_episode`, call `get_podcast_series` and read every non-empty `customPrompts` field plus relevant recent episodes. `material_to_podcast` applies the stored prompts in NewsTune's pipeline, but the submitted brief must still align with them. For `script_to_audio`, apply the stored sourcing, planning, research, scripting, supplement, and finalization rules while writing the transcript before sending it to NewsTune. If an interactive request conflicts with the persistent brief, ask whether it is a one-episode exception or a permanent series change. In a headless scheduled run, a conflict pauses/skips the run instead of asking or silently changing the show.\n\n## Canonical `script_to_audio` transcript\n\nBefore preview, resolve the selected host IDs through current host data. The decoded script must use actual LF (U+000A): JSON source `\\n` decodes to LF; reject a runtime literal `\\\\n` (backslash + n), CR, or CRLF. Multi-host scripts require every non-empty line to be exactly `<exact current host name>: <spoken dialogue>` with exact casing, ASCII colon, and one space. Reject unlabeled prose and any Markdown, bullet, timestamp, or stage direction around the label. Single-host scripts contain bare spoken text and no speaker label.\n\nSerialize the complete tool input, parse it back, assert the script is unchanged, and validate it again. A grammar or serialize → parse round-trip failure stops before preview, debit, job creation, or rendering. After terminal success, read-back the canonical transcript with `get_episode_transcript_context`, verify real line breaks and no literal `\\\\n`, inspect only returned `ttsMeta`, and perform an audio review: listen for correct voice turns and confirm no label or wrapper is spoken. Never invent absent `ttsMeta`; any read-back or playback mismatch blocks completion and publishing.\n\nThe immutable Dashboard plus transcript media form the synchronized digital manuscript. After the transcript/audio checks, refresh cues with `replace_episode_media_cues` and give the read-only evidence packet to an independent fresh-context reviewer before claiming completion or publishing.\n\n## Recurring automation authorization\n\nWhen the user requests a recurring schedule, use the host's native scheduler. Before activation, show and approve one self-contained contract containing the target series, cadence/timezone, generation mode, hosts, duration, maximum credits per run, every exact source/location and source policy, checkpoint/freshness/citation rules, privacy boundaries, full editorial brief and all `customPrompts`, episode visibility, RSS behavior, retries, and stop/skip conditions. Put every execution detail into the automation task prompt, but keep cadence/timezone in the scheduler's schedule fields. Do not rely on setup-chat memory and never store credentials or raw private documents there.\n\nEach covered occurrence must run without questions: read the live series/custom prompts/recent episodes, gather only new approved material, preview and execute the episode charge automatically within the approved ceiling, and poll generation to completion. After generation succeeds, call `get_episode_transcript_context`, refresh the sourced or user-provided assets against its canonical segments, and call `replace_episode_media_cues` with that exact transcript revision and a stable idempotency key. Only after the cue refresh succeeds may the run preview and execute `publish_podcast_series` for the one new episode, preserve the approved RSS state, verify the final episode URL/feed, and advance the checkpoint. If media sourcing, validation, import, or cue replacement fails, do not publish and do not advance the checkpoint; report the skipped run.\n\nRecurring authorization never covers creating another series or host, changing/adopting/cloning a voice, changing sources or editorial rules, increasing the credit ceiling, changing slug/SEO, enabling/disabling RSS, or publishing additional episodes. If a quote or preview exceeds the contract, if credits are insufficient, or if live settings conflict, do not ask in the scheduled run and do not broaden scope: skip/pause, keep the checkpoint, and report the reason.\n\n## Paid-action confirmation\n\nSeries creation uses two separate tools; episode creation and regeneration each use one two-phase tool:\n\n1. For a series, call `preview_podcast_series_creation` with every final content input. For a new episode call `create_podcast_episode` once without confirmation; for an in-place replacement call `regenerate_podcast_episode` once without confirmation. An affordable preview returns `phase`, `quoteCredits`, `currentCredits`, and short-lived confirmation values; it writes nothing and spends no credits. `create_podcast_series` is compatibility-only for older clients and must not compete with the new preview-then-confirm workflow.\n2. If `phase` is `insufficient_credits`, report the current balance and exact quote, confirm that no write or debit occurred, and stop. Do not retry, downgrade, substitute another format, switch accounts, bypass billing, or direct the user to buy credits, upgrade, purchase a subscription, or open a payment link.\n3. Show the exact title, series, source/privacy scope, mode, private visibility, and quote. Ask once only if approval of this unchanged still-pending action and charge is missing. An explicit prior approval remains valid; do not require a special phrase or another confirmation after a technical preview. An accepted or already charged action consumes its approval and does not authorize another generation. A generic generation request does not approve an unknown charge.\n4. A bare approval such as “yes” or “同意扣除 20 credits” can approve the immediately preceding concrete preview. For series creation use `confirm_podcast_series_creation` with the exact opaque `previewId` and `confirmed: true`; do not reconstruct content inputs or switch to the compatibility-only creation tool.\n5. Execute an approved single episode with identical content plus the returned confirmation values and `confirmed: true`. Covered scheduled runs follow their unchanged contract without another question.\n6. An expired technical token requires another preview, not automatically another user approval. Continue if the exact approved action, content, privacy scope, and charge remain unchanged. Ask only for a material change; scheduled runs pause instead. Never switch accounts, mode, sources, or credit limits to evade a failure.\n\nKeep the `previewId`, confirmation tokens, and idempotency keys tool-internal. Never print them in the suggested reply or user-facing response.\n\nDo not treat a queued response as completion. Publishing remains a separate publisher-tool action; a covered scheduled run performs that action automatically after generation succeeds.\n\n## Existing-series selection\n\nMatch an explicit ID first, then a normalized title. If more than one series matches, show concise differences and ask the user to choose. Never create a duplicate merely because the first result page did not contain the show.\n\n## Voice and publishing boundaries\n\nUse the `newstune-voice-studio` skill for voice selection or consent-based cloning. Use `newstune-podcast-publisher` for public pages and RSS. Voice recordings remain in NewsTune's secure handoff. Interactive publishing requires exact-scope preview and approval; a covered scheduled run may auto-execute only a preview that publishes its one newly generated episode while preserving every other approved public/RSS/slug/SEO effect.\n\n## Safety\n\n- Never expose credentials, private scripts, internal logs, or raw provider errors.\n- Do not infer consent to clone a voice from possession of an audio file.\n- Do not claim that an RSS feed has been submitted to Spotify, Apple Podcasts, or YouTube.\n- Do not accept third-party platform terms, ownership declarations, or account verification for the user.\n\n\n## Multiple episodes in one request\n\nA request for four episodes means deliver all four within the approved scope. Keep an ordered episode plan with each title, source boundary, mode, status, returned job/episode identifiers, and episode-page link. Reuse the selected series, cast, language, and editorial brief. Resolve only missing decisions in one combined question; do not ask whether to continue after each successful episode or request the same host/script/credit approval again.\n\nUse only tools exposed by the live client. When it exposes `create_podcast_episode_batch` and `get_episode_batch_status`, prefer that durable queue for 2–10 episodes in the same owned series. Prepare every final episode input, preview the complete batch, and present its per-episode charges and total charge together with its source/privacy scope and private visibility. An explicit prior approval of this unchanged complete batch and total charge remains valid; otherwise obtain approval once. Execute the identical batch with the returned confirmation fields and stable idempotency key. The batch uses its own exact confirmation; a recurring schedule is not blanket approval for extra episodes. Preserve the generation-mode rules above; batch support does not permit silently changing a script request to cloud drafting.\n\nAfter confirmed acceptance, retain the returned batch ID and poll `get_episode_batch_status`. The server runs the episodes sequentially and can continue while chat is inactive. Charges occur as each item starts, within the quoted total; undispatched items expire after 24 hours. Include that time limit in the batch approval summary. Report accepted/queued as queued, and report each completed episode independently with its returned page URL. A failed or stalled item stops later items; report completed, failed, and not-started items accurately. Do not recreate the batch, retry a charged item with a new key, or claim that blocked items will continue automatically. Read the existing batch status before deciding any recovery.\n\nIf those tools are unavailable, explain that this connection lacks a durable batch queue. Use unchanged exact-action approvals and create one episode at a time: preview, execute, poll to terminal success, retain its result, then continue to the next approved episode in the same active task without another user turn. Never parallelize writes for the same series. Stop on an ambiguous/failed charge, generation failure, or scope/budget mismatch. Keep the remaining plan and known IDs for resumption, but do not promise background continuation without a server queue or an explicitly configured scheduler.\n\nAlways return one clickable episode-page link per available episode, even when a player is displayed. Use returned `episodeUrl` for signed-in access and `publicEpisodeUrl` only when the tool confirms that episode is public; creating a link never authorizes publication. Queued episode links open its location, not completed audio. Include unfinished statuses and remaining episode count rather than finishing with only the first episode's result. Audio-ready batch items still require the transcript/media checks above before being described as fully reviewed deliverables.\n\n\nDefault to `script_to_audio` when the host AI writes the script. Use `material_to_podcast` only for an explicit user request or a disclosed exception authorized by the user, including its source/privacy and credit implications. Never silently switch or fall back between modes.\n"
}