frahman5 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.