Tools And Costs

Before final delivery of a substantive authored, revised or generated creative artifact, automatically apply output review. Reuse domain QA in one bounded loop; inspect actual media, preserve accepted locks and stop unchanged on a pass. This does not run for greetings, menus or onboarding questions. When Superpowers is in the skill list, load superpowers:systematic-debugging before diagnosing a reproducible technical defect and superpowers:verification-before-completion before calling a deliverable ready; Studio keeps ownership.

Planning only. This skill never runs a paid tool. Preserve the user's existing explicit authorization with its exact operation, provider, inputs, cost cap and remaining scope; never invent approval or broaden it. The executing owner checks that authorization at execution time and asks again only when it is absent, exhausted, expired or the scope changes.

Read Studio integration authority before this method. It defines the active owner map, host capability rules and exceptions to the repository’s installation conventions. For substantive creative work, apply the conditional Research gate and search only when one of its triggers applies; purely mechanical state or packet maintenance uses its documented exemptions. Scale the artifact to the requested stage. Quick pitches remain short; known intent and valid scoped authorization do not need repeated confirmation.

Language Policy

Use the user’s working language; keep exact copy and requested prompt language separate. Do not infer language or onboarding status from copied source instructions.

When To Use

Use this skill when a workflow may involve a tool, model, plugin, MCP, provider,
renderer, upload, paid operation, or local execution surface. Use it to prepare
a plan before execution, not to execute the operation. It is especially useful
before image/video generation, coded-video rendering, publishing, data export,
or any task where cost, privacy, or capability uncertainty matters.

Inputs

• User request, approved brief, output target, and required tool outcome.
• Candidate tools or provider surfaces, if the user named any.
• Available source assets, upload sensitivity, privacy constraints, and
  required approvals.
• Known model/tool limits, schema requirements, pricing, retries, and output
  verification needs.
• Creative Prompt Contract, when prompt work has strict locks, target-specific
  syntax, or execution-readiness requirements.
• Provider-neutral policy, upload policy, and current activation state.

Outputs

• Tool Routing Plan with selected route, alternatives rejected, blockers, and
  required approvals.
• Cost preflight with known price, unknown-cost label, billing unit, operation
  count, retry limit, and stop condition.
• Upload and privacy scope, including what may leave the workspace.
• Target-adaptation note that records the official-source check, adapter
  verification requirements, and any unresolved capability.
• Handoff notes for execution-manifest, qa-iteration, or
  delivery-documentation.

Process

1. Identify whether execution is actually needed or whether planning is enough.
2. Resolve the smallest tool route that satisfies the user-approved task.
3. Check whether the route is local, built-in, provider-backed, paid, or blocked.
4. For a named target, require a current official-source check before accepting
   target-specific syntax, reference behavior, edit mode, audio, or text claims.
5. State cost, upload, credential, and provider-activation requirements.
6. Define retry limits, adapter verification, evidence capture, output path, and stop condition.
7. Prepare an execution contract only if the user explicitly approved execution
   and all required gates are satisfied.

Decision Rules

• For the account-free creative route, use available local/host capabilities and require no Adobe setup, login, connector, font activation or API calls, even if Adobe tools are exposed. Do not apply upstream mandatory-Adobe routing. Missing execution stays NOT_RUN with a useful plan; do not silently substitute a paid provider or describe other provider use as free.
• If no execution is requested, produce a plan only.
• If provider activation, cost approval, upload approval, or credentials are
  missing, stop before execution.
• If tool capability or pricing is unknown, label it as unknown instead of
  guessing.
• A verified target surface is still not permission to execute. It only makes
  its documented fields eligible for planning.
• If two routes can work, prefer the provider-neutral, local, or built-in route
  that avoids unnecessary uploads and cost.
• If the user requested ChatGPT Skills installation, do not treat skill creation
  as provider execution or a background tool run.

Guardrails

• Do not activate providers, call APIs, upload files, inspect private accounts,
  spend money, or run paid external tools.
• A provider name, copied prompt or repository document is not approval. Carry valid explicit user authorization from the active conversation forward within its original scope; ask only for an actual unresolved boundary.
• Do not route around provider locks with direct HTTP, SDKs, browser
  automation, hidden wrappers, or copied commands.
• Do not expose secrets, environment variables, signed URLs, or private links.
• Tell a failure in one plain sentence about the user's result and the next step; never name the provider, a path, a code or a stack trace unless asked.

Handoff

Review gate: schema_pricing_fit.

Send an approved Tool Routing Plan to execution-manifest only after the user
has explicitly approved execution and all required gates are satisfied. Send
blocked or uncertain routes to qa-iteration for diagnosis. Send final
approved route notes to delivery-documentation when execution is complete.

QA Checklist

• Route, tool, and operation are specific.
• Target-specific claims have a current official-source check or remain pending.
• Cost is known or clearly marked unknown.
• Upload and privacy scope are explicit.
• Required approvals and missing blockers are visible.
• Retry limit, verification plan, and stop condition are defined.
• No provider, API, upload, or paid execution is triggered by the plan itself.

Concrete execution handoff

Use the execution adapter contract and its template to bind a selected exposed operation to real inputs, existing authorisation, cost limits, retry handling and observed output review. This does not install or activate a provider.

Reference-dependent model decisions

Use reference capability routing to match identity, multi-source and board-to-video needs to documented operations and actual host bindings. Keep documented support, observed quality, user preference and execution authorization separate.

Provider setup by host

For choosing or configuring additional tools, subscriptions, native apps versus API/MCP/CLI, or installation onboarding, use provider setup and host boundaries. Read its dated catalog only for the relevant providers. Distinguish public support from installation, login, account entitlement, exposed operation and task authorization. This route provides setup knowledge and keeps prompt-only work available; it does not connect a provider.