Benchmark

Research what to create

Break down one post or build a business content plan.

Paste this prompt into your AI client to start. Setup verification is free. Research can spend credits.

For persistent use, install the skill with the optional command below.

npx skills add https://benchmark.social --skill content-research

Content research

Choose the task from the user’s request. Use the single-post flow for a supplied post. Use the business flow for positioning, niche research, series, or a production plan. Do not require a business interview before starting a supplied-post breakdown.

Connection, scope, and spend

Reuse Benchmark MCP in the active client. If unavailable, use benchmark-setup or continue with accessible supplied content. State which evidence you can inspect. Public inspection does not produce Benchmark enriched analysis.

Read the MCP contract before Benchmark research calls. Use free whoami and list_operations to check the workspace and current operation schemas. Stored reads and refreshes can spend credits. Establish the task, maximum accounts and posts, date window, enrichment count, and credit cap before paid work. Use existing approval when it covers this task. Check current pricing before each new paid operation type. If the maximum charge is unclear or exceeds the remaining cap, stop before the call.

Collect the smallest useful sample first. Reuse cached results and remove duplicate canonical URLs. Do not start parallel paid requests. Track reserved and charged credits from unique receipts. Stop at the cap, uncertain billing, access errors, or terminal failures. Do not buy credits or subscriptions automatically. Do not repeat a paid request after an uncertain response. Check the known job status first.

Use readProfileHistory for stored Basic posts from a known account. Approve bounded refreshes separately when fresh history is necessary. Select useful examples before enriched reads or refreshes. Do not enrich the whole sample automatically. Follow returned dataRequest.nextOperations for status and result delivery. Cache a delivered result immediately. Do not consume both result delivery routes for one job.

One-post breakdown

Start with the original source URL or supplied content. A gallery URL is context, not the original post input. If only a gallery URL exists, inspect its source link or ask for the original URL. Do not substitute a media file, preview image, or invented URL. Use accessible supplied evidence immediately while paid access awaits approval.

After scope and budget approval, use readPostsEnriched for a known social post. Use readLinksEnriched for an article when useful. Request refresh only when necessary and approved. Read returned analysis.templates and steps when available. Use source wording as an exact quote only when the evidence contains that wording.

Return a Markdown breakdown with source links and these supported elements:

  • The verbal, visual, and on-screen text hooks when evidence exists, plus the audience promise.
  • The beat sequence, including proof, escalation, payoff, and CTA where present.
  • The source evidence for each observation.
  • Likely mechanisms, explicitly labeled as interpretations.
  • A reusable template with editable placeholders.
  • Optional original adaptations, labeled as proposals.
  • Missing evidence and access limits.

Do not force missing elements into the breakdown. Do not infer causation from views, likes, or a successful example. Do not invent a full transcript, timestamp, downloadable media URL, or private metric. Ask for business context only when the user wants a tailored adaptation.

Business or niche content strategy

Establish the missing parts of the brief before paid collection:

  • The business, offer, audience, and audience problems.
  • The commercial goal and intended audience action.
  • The platforms, formats, and existing account URLs.
  • Available expertise, assets, access, people, equipment, and production time.
  • The feasible cadence and planning period.
  • Research scope, credit budget, and stop conditions.

Use existing context instead of asking the same questions again. Propose a small pilot scope when the user has no research scope. Obtain approval before paid collection. Do not default to a large account count or a previous project’s budget.

Discover candidate creators through supplied URLs, public web research, and available platform search. Benchmark native keyword discovery is not guaranteed. list_operations.filter searches operations, not posts or creators. If public research is unavailable, ask for suitable account URLs or use the supplied examples. Explain each candidate’s audience, topic, or format relevance before selecting accounts. Include direct niche sources for demand and adjacent niches for transferable formats. Keep those evidence roles separate.

Compare bounded histories within each account. For each baseline, record the platform, format, date window, metric, observation date, and eligible sample count. Use comparable publication ages and formats where possible. Exclude or separately report posts too recent for the chosen comparison. Use a suitable baseline, such as median views, when that metric exists. Report the baseline value and the selected post’s ratio. Do not divide by zero or rank unavailable metrics. Call a small or biased sample exploratory. Do not compare raw views across unrelated accounts as if their audiences were equal.

Inspect ordinary posts as well as apparent outliers. Record retrieval and selection limits, including pagination, missing dates, missing metrics, and unknown paid distribution. Select a few useful contrasts for enriched analysis within the approved cap. Test whether the evidence supports a topic pattern, a format pattern, or only one unusual example. Do not treat adjacent-niche success as proof of demand in the user’s niche.

Turn supported patterns into original angles and repeatable series. Explain what transfers and what requires different access, expertise, assets, or testing. Do not copy another creator’s wording or claim their experience as the user’s experience. Ask for the user’s actual opinions, trials, and credentials when an idea requires them. Mark ideas that require new research, product use, permissions, or unavailable access. Do not depend on private scoring tools.

Return a concise Markdown strategy with:

  • The brief, scope, collected count, selected count, inspected count, and spend from available receipts.
  • A source ledger with canonical URLs, accounts, dates, formats, metrics, and selection reasons.
  • Baselines and outliers with explicit sample limits.
  • Evidence-linked patterns, with topic demand separate from transferable formats.
  • Original angles and repeatable series linked to their supporting sources.
  • A prioritized production plan that fits the user’s cadence and constraints.
  • A hook, format, effort, required assets, intended action, and evidence strength for each priority idea.
  • A small test schedule, success criteria, open questions, and next research decisions.

Treat predicted performance as a hypothesis. Use the user’s own comparable baseline to evaluate published tests. Do not promise that borrowing a pattern reproduces the source’s performance.

For reaction-video delivery, use the keyword handoff.

Preserve Markdown evidence

Use format: "markdown" in query or mutate when readable results serve the task. Use JSON when calculation requires structured data. Keep source links, headings, tables, and evidence labels in the final Markdown. Do not flatten Markdown into an unstructured summary. Request post analysis as Markdown with Benchmark MCP query or mutate and format: "markdown". Preserve canonical source URLs in the returned analysis and final report. Use available gallery analysis as existing evidence, not as a fresh enrichment result. Keep returned Markdown in the conversation or a file when available. Reuse that evidence for formatting instead of making another charged read.