creator-account-teardown

Creator Account Teardown

Read a short-video or social account from what can actually be seen, work out the system underneath it, and turn that system into a build template for the user's own account — ending in a first post that is produced, not described.

Scope and adjacent routes

The route is: an account, a diagnosis, a build template for the user's own account, and one produced first post. It fits when someone points at an account — a competitor, a benchmark, or their own — and wants to know how it works and what to do next.

viral-video-teardown-remake is the neighbouring route and the boundary is clean: that one takes apart a single video and rebuilds that one video. This one takes apart a whole account and produces a positioning and content plan, landing on a first post. When the user brings one clip and wants their own version of that clip, send them there. When they bring a grid, a profile, or a list of posts, stay here.

Other starting points fit elsewhere. A topic that is trending right now belongs in a hot-topic workflow. Copy already written and about to be published belongs in a pre-publish check workflow. A finished script that only needs a voice belongs in a voiceover workflow.

Inputs and defaults

Two hard inputs: the account being torn down, and who the user is building for.

The account arrives as whatever the user can see, and every shape works. Profile screenshots. The bio, verbatim. A pasted list of recent posts with their titles or captions and the view, like, comment, save, and share counts visible on each. Screenshots of the grid. A handful of full captions. Any one of these starts the read; more of them sharpens it. Take whatever arrives and say plainly, once, which parts were read directly and which came from the user's account of them.

The shape a user reaches for first is the handle, or a link to the profile, and this package can read that directly on TikTok, Douyin, Xiaohongshu, Instagram, YouTube, and X (YouTube wants the channel URL rather than a bare handle): the profile, a page of recent posts with their counts, and — on TikTok, Douyin, and Xiaohongshu — a page of comments. Each is a separate paid lookup, each is optional, and each is confirmed on its own before it runs, per reading the account from a handle. The rule is the whitelist, not a list of exceptions: a platform with no operation on it cannot be looked up. WeChat Channels is one, and so are Kuaishou, Bilibili, Weibo and Zhihu, and the list is not exhaustive; for any of them the account is read from what the user pastes, and no neighbouring platform's figures are ever put in its place.

The second input is the user's own side: their industry, product, expertise, or persona, and their own account if they already have one. Without it the diagnosis is a report about someone else instead of a plan for them. Reuse whatever the conversation already states rather than asking again.

Default to a read of the ten to twenty most recent posts, looked up or supplied, three to five content pillars, a matrix laid out as pillar by format by cadence, an opening plan of ten posts, one first post produced, a 9:16 vertical cover, and a narration voice matched to short social content. Name each default with the result instead of asking about it.

Everything up to the produced post costs nothing, apart from an account lookup the user asked for and separately approved, and a run that stops at the template is already a complete, useful result. Say so rather than steering toward either paid step.

Every number has a source

This is the rule the whole diagnosis rests on, and it is not negotiable.

Every number and every fact about the analysed account comes from one of exactly two places: a lookup this package ran, or the user. There is no third source.

The order is: look it up when the user asked for that and the platform has an operation; otherwise take what the user supplied; and label which of the two every row came from, with the time a looked-up figure was read. Public counts move, and a count quoted without its read time ages badly.

Follower counts, view counts, like and comment counts, engagement rates, posting frequency, revenue, monetization, and growth trajectory are never estimated, never interpolated, and never carried in from what similar accounts usually look like. That prohibition is not softened by having a lookup available — it is the reason the lookup is worth running. When a figure is missing from both sources, say it is unstated and diagnose around it; a content matrix, a hook pattern, and a positioning read all survive a missing follower count. A plausible-looking metric about a real account is the worst possible output here, because the user will act on it.

A looked-up number is not a more certain number than a pasted one, only a differently sourced one. It can still be stale, disputed, or inflated by the account itself. Label it and move on rather than presenting it as settled.

The same line runs through the pattern reads. Why a post performed well is inference, not fact. Mark it as inference, give the evidence behind it, and say what would confirm it — usually a wider post sample, or the same structure repeated across the top performers rather than appearing once.

Analysing an account the user does not own is ordinary competitive research, and the read goes wherever the evidence goes. What comes out the other side is the user's own version of a structure: their pillars, their hooks, their claims, their footage. Do not carry over another creator's actual footage, recorded voice, or verbatim captions.

Claims about the user's own subject — specifications, prices, results, credentials, offers — come from the user. Write around a missing one rather than producing it.

Golden path

Stages 1 to 7 cost nothing. The only paid call that can precede them is the optional account lookup below, which runs only when the user asked for it and only after its own price has been confirmed. Apart from that, the first paid call is stage 8, and it happens only after the user has seen the template and the first post plan and approved them.

1. Optional: look the account up. Skip this unless the user gave a handle or a profile link and wants it read. Confirm it on its own — which operation it maps to, the price the live tool card just returned, and how many lookups the plan contains — then run it, per reading the account from a handle. When the user has already pasted screenshots and post counts, skip it; the teardown built from those is a real teardown.

2. Build the evidence table. Lay out every post — looked up at stage 0, or supplied by the user — with its visible metrics and its caption or title, plus the bio and anything the profile shows. Each row carries where it came from, and a looked-up row carries the time it was read. Mark the gaps as gaps. This table is the only thing later stages are allowed to reason from, per reading the account.

3. Diagnose the account. Positioning, the audience it actually speaks to, the content matrix behind the grid, the hook and structure pattern its best-performing posts repeat, the posting cadence, and the account's own weak point. Separate what the evidence shows from what you infer from it.

4. Read the gap. Put the analysed account beside the user's own — what transfers, what does not, what the user has that the other account does not, and where the opening is.

5. Build the template. A positioning line, a bio, content pillars with their formats and cadence, the repeatable hook formula written so the user can run it again, and an opening plan of ten posts, per building your own account.

6. Write the first post and get it approved. The strongest post from the opening plan, written out: cover wording, caption, hashtags, and the script with on-screen action and spoken line kept apart. This is the artifact the paid work is built from, and it is free to revise.

7. Read the live text_to_speech card with beatra.models.list, and the card for the cover route it will actually take — text_to_image for a fresh render, image_edit when the user uploaded their own cover or avatar to build from — then select a voice with beatra.voices.list.

8. Confirm production. Show the approved cover wording and script, the 9:16 canvas and what changing it later would cost, the selected ready voice, the current estimate, and a stable request ID for every planned paid call.

9. Render the cover with beatra.images.generate — or with beatra.images.edit when the user uploaded their own existing cover or avatar to build from, in which case the payload states the 9:16 canvas explicitly, because the edit route otherwise keeps the uploaded image's own ratio and silently overrides what was frozen at the gate — and synthesize the script with beatra.speech.synthesize, then read the actual returned duration, size, and MIME type.

10. Poll each task with beatra.tasks.get until terminal, deliver the diagnosis, the template, and the produced post together, and review what you can actually see.

Decisions that require confirmation

Confirm before spending, at two separate boundaries. First, and only when the user asked for it, each account lookup on its own, naming the operation it maps to and the price the live tool card just returned — counting the profile, each page of posts, and each page of comments as its own charge. Second, the cover wording and the script together, with every one of their priced calls named. The two are never folded into one approval: the lookup happens inside the stages this package promises are free, and an approval for production is not an approval for it.

Also confirm, rather than deciding alone: a canvas other than 9:16, a positioning line that contradicts what the user said about themselves, a claim about the user's subject they have not supplied, and any change after an artifact is approved. Each changed argument is new paid work with a new request identifier and fresh approval.

When the user asks for the analysed account's own footage, cover art, or captions to be reproduced rather than its structure, say what this route does produce — their own post built on the same structure — and continue from there.

Execution

Invoke every remote Beatra tool only through the bundled scripts/mcp_client.py, with the tool name as the CLI argument and its arguments as JSON on standard input:

printf '%s' '{"capability":"text_to_image"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"image_edit"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"capability":"text_to_speech"}' | python3 scripts/mcp_client.py call beatra.models.list
printf '%s' '{"language":"zh-CN"}' | python3 scripts/mcp_client.py call beatra.voices.list
printf '%s' '{"query":"user posts","platform":"douyin","capability_family":"creator"}' | python3 scripts/mcp_client.py call beatra.social.tools.search
python3 scripts/mcp_client.py upload ./current-cover.jpg --mime-type image/jpeg

Do not configure or call a host Beatra Connector, and do not use REST/OpenAPI as a fallback. Give each logical paid request one stable opaque client_request_id and submit it exactly once.

Delivery and review

Deliver the evidence table with its sources, the diagnosis, the gap read, the build template, the opening plan, the first post's cover with its wording, its caption and hashtags, its script, the rendered cover, and the voiced narration. For each generation task deliver its task ID, the returned artifact links, the resolved model, the returned dimensions and duration, and billing.net_charged_credits. An account lookup reports differently — the returned payload, its task ID, its terminal state, and the credits it actually charged, with no model, dimensions, or duration to report. Report only facts the task actually returned.

Cover wording is generated artwork. Read the rendered text back against the approved wording and say plainly when it did not render legibly, rather than describing an uninspected cover as correct. Play the narration when the host can access it and report the true duration. State which media details could not be inspected instead of inferring them from task metadata.

Recovery

Record each task ID immediately and poll only that task. queued and running mean wait. If a create response is lost, resubmit only the identical frozen payload under the same identifier; if a task ID is lost, list tasks for that capability and match candidates against your own ledger before any retry — including an account lookup: list the tasks, match a candidate against the operation, arguments and schema fingerprint in your ledger, and only then replay the byte-identical arguments under the same identifier. Repeating a lookup with anything changed is a second charge, not a retry. Redoing the cover reuses the narration unchanged, and the reverse. insufficient_balance means nothing was charged and the identical request can be resubmitted after a top-up.

References by task

• Building the evidence table, the positioning and audience reads, the content matrix, the hook pattern, and the cadence read: reading the account
• Reading the profile, the posts, and the comments from a handle, what each lookup costs, and how the result is labelled: reading the account from a handle
• Turning the diagnosis into a positioning line, a bio, pillars, a hook formula, an opening plan, and the first post: building your own account
• Exact payloads, what the confirmation freezes, polling, redoing one stage, recovery, and cancellation: account teardown workflow
• First install or expired authorization: installation and authentication
• Non-billable package registration: installation registration
• Task polling, artifacts, and result fields: tasks and results
• Balance, validation, and structured errors: billing, errors, and recovery
• When the bundled client cannot connect: Bundled MCP Client diagnostics
• Update guarantees and controls: automatic updates and safety
• Removing the package or shared credentials: uninstall and disconnect

Runtime and safe automatic updates

The bundled client silently checks for a newer release at most once every 24 hours per installation. When a higher version is available it installs automatically without separate confirmation. It downloads only from the fixed official Beatra discovery and immutable CDN paths for this package, channel, and locale, verifies the discovery data, archive, manifest, and every file's size and checksum before replacement, and replaces only package-owned files. It rejects redirects, downgrades, mismatched package, channel, locale, or version data, unexpected URLs, unsafe archives, and any file outside the owned destination.

Update checks, downloads, verification, replacement, and rollback all fail open: the current installation stays usable and the original command continues. An update failure never authorizes retrying a paid generation. The choice persists across later commands for this installation.

python3 scripts/mcp_client.py update --auto off
python3 scripts/mcp_client.py update --auto on
python3 scripts/mcp_client.py update --check

--auto off disables silent checks, --auto on restores them, and --check reports the official available version without replacing files. See automatic updates and safety.