tiktok-warmup

TikTok Warmup Skill

Warms up TikTok accounts for Flooently + Blaze using Multilogin browser profiles. Targets Spanish learners across Latin America.

This is now a semi-manual system. Faiyam runs /execute-warmups (see prompts/execute-warmups.md) when ready to warm up. The agent plans today's sessions, runs them in parallel across accounts, and relies on Faiyam for manual debugging (CAPTCHAs, re-logins, weird modals). No background scheduler, no cron — just a slash command.

Pre-flight — run this immediately on skill load

First, update the skill to the latest version from fstack:

npx skills update

Then run the checks below and report health status for each activity. Do not block — just show the user what's ready and what isn't.

source .env.cli 2>/dev/null || true

# 1Password — TikTok vault
OP_VAULT_STATUS="❌ OP_SERVICE_ACCOUNT_TOKEN not set"
if [ -n "$OP_SERVICE_ACCOUNT_TOKEN" ]; then
  VAULTS=$(OP_SERVICE_ACCOUNT_TOKEN=$OP_SERVICE_ACCOUNT_TOKEN op vault list --format=json 2>&1)
  if echo "$VAULTS" | python3 -c "import json,sys; names=[v['name'] for v in json.load(sys.stdin)]; assert 'Tiktok' in names" 2>/dev/null; then
    OP_VAULT_STATUS="✅ 1Password Tiktok vault accessible"
  else
    OP_VAULT_STATUS="❌ Tiktok vault not found (wrong OP token, or vault not shared with this service account)"
  fi
fi

# MLX token
MLX_STATUS="❌ MLX_AUTOMATION_TOKEN not set"
[ -n "$MLX_AUTOMATION_TOKEN" ] && MLX_STATUS="✅ MLX_AUTOMATION_TOKEN set"

# AgentMail
AM_STATUS="❌ AGENTMAIL_KEY not set"
[ -n "$AGENTMAIL_KEY" ] && AM_STATUS="✅ AGENTMAIL_KEY set"

# Airtable — token must be present AND resolver must find a matching base
AT_STATUS="❌ AIRTABLE_ACCESS_TOKEN not set"
if [ -n "$AIRTABLE_ACCESS_TOKEN" ]; then
  RESOLVER_OUT=$(python3 .agents/skills/tiktok-warmup/resolve_airtable_schema.py 2>&1)
  if [ $? -eq 0 ]; then
    AT_STATUS="✅ $(echo "$RESOLVER_OUT" | head -1)"
  else
    AT_STATUS="❌ Airtable resolver failed: $(echo "$RESOLVER_OUT" | tail -2 | head -1)"
  fi
fi

echo ""
echo "🔍 Environment Health"
echo ""
echo "  Account Warmup:"
echo "    $MLX_STATUS"
echo "    $OP_VAULT_STATUS"
echo "    $AM_STATUS"
echo "    $AT_STATUS"
echo ""
echo "  Account Creation:"
echo "    $OP_VAULT_STATUS (needs read+write)"
echo "    $AM_STATUS"
echo "    $AT_STATUS"
echo ""

Report the output to the user before proceeding. If warmup prerequisites (MLX + OP vault) are missing, tell the user warmup won't work and ask if they want to fix it first.

---

Reference Files

File	Purpose
multiloginRef.md	Multilogin X API reference — auth, workspace IDs, profile IDs, how to start/stop profiles, Playwright connection.
browserWarmupRef.md	Browser warmup protocol — humanized Playwright sessions on tiktok.com via Multilogin browser profiles. Preferred approach.
loginRef.md	TikTok login procedure — do this yourself agentically, never delegate to ensure_login.py. Covers where creds live (1Password Claude-Accessible vault), OTP retrieval (AgentMail), captcha handling, and the visual login-verification checklist.
sessionDesignRef.md	How to compose the per-account task queue. Target 50%+ niche-explicit time in early weeks. Recommended task mixes by week, anti-patterns, working example for Sofia. Read this when building a queue for any /execute-warmups run.
accountsRef.md	Account registry auto-refresh protocol. Accounts live in Airtable; scripts read from scripts/warmup/accounts.json. The agent refreshes the cache at step 2 of every /execute-warmups run so new/removed accounts propagate automatically with no code edits.
airtableRef.md	Airtable base/table/field IDs - Accounts + Session Log are the two tables we use.
computerUseRef.md	Mobile cloud phone warmup - computer-use based. Used only for late-stage weeks or special cases.
peekabooRef.md	Peekaboo CLI fallback - used when request_access fails for cloud phone sessions.
proxyRefreshRef.md	Proxy refresh protocol — when and how to rotate a profile's IP via API. Ban risk decision tree, generate+update flow, country codes, failure handling. See also refresh_proxy.py for the standalone script.
runtimeLearnings.md	Operational learnings from live sessions - read before every execution.
accountCreationRef.md	How to create TikTok accounts and store credentials in 1Password.
createTiktokRef.md	Full interactive protocol for /create-tiktok — step-by-step account creation walkthrough.
adoptAccountRef.md	Walkthrough for integrating a TikTok account created by someone else (e.g. a Fiverr freelancer) — credential takeover, Multilogin setup, Airtable registration, Postiz connection, Search Term generation.
executeWarmupsRef.md	Full protocol for /execute-warmups — plans and runs warmup sessions across all active accounts.

Protocols

• Run today's warmups (the main thing): trigger /execute-warmups. Full protocol in executeWarmupsRef.md.
• Run a one-off browser warmup session: read multiloginRef.md + browserWarmupRef.md + runtimeLearnings.md, then invoke scripts/tiktok-warmup-poc.py.
• Run a mobile warmup session (rare): read multiloginRef.md + computerUseRef.md + runtimeLearnings.md.
• Create a new TikTok account: trigger /create-tiktok. Full protocol in createTiktokRef.md.
• Adopt an externally-created account (e.g. from Fiverr): read adoptAccountRef.md and walk the user through it step-by-step.
• Multilogin API operations: read multiloginRef.md.

Design philosophy

Target 30-90 min of warmup per account per day, split into 2-4 sessions of 15-30 min each. Rest days in weeks 1-2 are natural (deterministic per account). The Scheduled Sessions Airtable table is deprecated - we log results directly to Session Log.

Ban risk lens — apply to every strategic decision

Whenever evaluating any infrastructure or workflow choice (proxy setup, IP rotation, session timing, account actions, tooling), explicitly reason through: how does this impact TikTok ban risk?

TikTok's trust system tracks device fingerprint + IP consistency over time. The main ban risk vectors to reason about for any decision:

• IP consistency: same IP per account per session, same geo across sessions. Any IP change is a risk event.
• Session realism: human-like dwell time, natural scroll speed, no bot-pattern actions (instant likes, identical session lengths).
• Account age signals: new accounts are high-scrutiny; the first 14 days are the highest-risk window.
• Fingerprint stability: Multilogin profile fingerprint (device, browser, OS) should never change mid-warmup.
• Action velocity: too many follows/likes/comments in a session triggers spam detection.

For any proposed change, ask: does this make the account look more or less like a real human using a real phone on a consistent network? If less — find the version that doesn't.