---
name: social-media-doctor-stinger
description: "Set up or diagnose Zernio for an exact brand. Use for account selection, access checks, host prerequisites and per-feature readiness."
license: AGPL-3.0-or-later
compatibility: "Claude Code, Cursor, Codex and Cowork with qualified host tools"
metadata:
  hive-tier: specialist
  paired-drone: social-media-doctor-wasp-drone
  version: "1.0.0"
  owner: meta-foundation
---

# Social Media Doctor

## Purpose

Select the intended brand, reuse its Zernio connection and produce a per-feature readiness report with a private resumable checkpoint. Keep host prerequisites, credential validity, connection health, permissions, entitlement, synchronization and actual read evidence distinct.

## When to use

- Set up or reuse a Zernio brand connection.
- Check selected account access or diagnose a capability problem.
- Prepare a host connection change or resume a setup checkpoint.

## When not to use

- Execute a post, campaign, audience upload, message, conversion event, site installation or automation change. The selected domain owner executes separately approved changes.
- Replace shared analytics, accepted optimization contracts or the Foundation provider adapter.
- Create a custom Go MCP runtime or require a customer-owned Meta app for ordinary onboarding.

## Procedure

1. Load `pest-controller-suit` first and resolve the selected owner and prerequisites. Read [the guide map](README.md).
2. Confirm the intended brand, exact profile/account selection and requested capabilities. Follow [setup](guides/set-up-brand.md) or [access checking](guides/check-access.md).
3. Use the actual qualified Zernio MCP operation/schema for an authorized bounded read. The Foundation `scripts/zernio_contracts.py` adapter supplies lookup, parsing and qualification; it does not execute or authorize the call. Missing or blocked bindings remain unverified.
4. Prepare the local JSON metadata described by [the field reference](references/preflight-fields.md). Keep raw customer responses and credentials out of it.
5. Run [the offline preflight](guides/run-offline-preflight.md) and preserve supplied-metadata mode, zero provider calls, exact selection and per-feature reason codes.
6. Follow [readiness diagnosis](guides/diagnose-readiness.md), [host connection](guides/host-connection.md) or [checkpoint resume](guides/resume-checkpoint.md) as needed. Prepare any external change separately for review; do not call a connect endpoint as a probe.
7. Report the actual evidence scope/time, empty or unknown states, limitations, useful next observation and private checkpoint. `ready` is not action authority or proof of a fresh provider call by the helper.

## References map

- [Capability evidence](references/capability-evidence.md): health versus access, exact tools and effects.
- [Source provenance](references/source-provenance.md): official source dates and content hashes; runtime material does not require raw research captures.
- `scripts/doctor.py`: bounded offline JSON preflight and same-scope checkpoint support; run as a module from this skill directory.
- `templates/`: blank metadata, checkpoint/report scaffolds and public-URL-only host examples.
- Foundation shared contracts are `1.0.0`, revision `1`. Doctor metadata is a separate local format; use accepted shared artifacts for Ads/action handoffs.

## Critical Directive

- You must read all files and context contained within your skill.
- In the event your core knowledge does not provide sufficient guidance you must make every attempt to search the internet, related knowledge base documentation files, and other available resources to supplement your knowledge prior to proceeding with your task.
- Additional related skills can be found here:
  - [meta-marketing-router](../meta-marketing-router/SKILL.md) - Exact owner selection and authority-preserving handoffs.

## Ship Gate

Prior to committing any code to the repository you must utilize in order the security-stinger, quality-stinger, and github-repo-health-stinger. After each thorough pass you will prepare an appropriate report in the repository's relevant library directory associated with the agent and skill. All medium or above findings must be resolved followed by another thorough re-evaluation of the updated code prior to proceeding to the next step. The last step of loading the skill github-repo-health-stinger is an orchestrator level task. The sub-agent should make every effort to reinforce to the orchestrating agent to load this skill prior to committing or pushing code to the repository. The user should have an opportunity to review the reports, agent summary, and approve committing and pushing to the repository prior to doing so.