app-review-prep

# App Review Prep Check everything needed before submitting a Meta app for App Review. ## Prerequisites — MCP connection (read first) This skill needs the Meta Social Technologies MCP server `devtools` (`https://mcp.facebook.com/devtools`, streamable-http). Plugin installs bundle it; skills-only installs such as `npx skills add` do not ([setup](https://github.com/facebook/agentic-tools#install-via-vercel-skillssh)). **If the `mcp__devtools__*` tools are not available, STOP.** Do not invent tool output, including the step 1 tracking call. Ask the user to add the server and complete its OAuth flow (never ask for an access token), then continue. ## Workflow 1. **Start tracking.** Before any other work, call `devtools_skill_invocation` with action `start` and `skill_name` `app-review-prep`. Pass `skill_name` `app-review-prep` on every `devtools_*` tool call in the following steps. 2. **Identify the app.** Ask the user for the app **name or ID**. If they give a name (or aren't sure of the ID), call `devtools_app_list` (action `list`) and resolve it to an `app_id` — match the name case-insensitively. If several apps match or it's ambiguous, show the candidates (name, ID, viewer role) and ask the user to pick. If they give a numeric ID, use it directly. 3. **Collect review data in parallel.** Run all calls concurrently: - `devtools_app` with action `basic_settings` — app name, category, status for report context - `devtools_app_review` with action `status` — current review state - `devtools_app_review` with action `requirements` — what's needed for approval - `devtools_app_review` with action `privileges` — currently granted permissions/features - `devtools_app_review` with action `history` — past submissions and their outcomes - `devtools_compliance` with action `status` — compliance blockers that could prevent approval 4. **Analyze readiness.** Evaluate: - Are all required items complete? - Are there compliance violations that would block review? - Have previous submissions been rejected? If so, what was the reason? - Which permissions/features are already approved vs. still needed? 5. **Produce a readiness report:** ### Report Format **Current Status** - Review state (e.g., not submitted, in review, approved, rejected) - Last submission date and outcome (if any) **Granted Privileges** - List of approved permissions and features **Outstanding Requirements** - Each requirement with its completion status - Clear description of what's needed to fulfill incomplete items **Compliance Blockers** - Any violations or required actions that must be resolved before submission **Submission History** - Past submissions with dates, statuses, and rejection reasons (if any) - Pattern analysis if there are repeated rejections **Readiness Verdict** - READY: all requirements met, no blockers - NOT READY: list exactly what needs to be done, in priority order 6. **Suggest next steps** based on the verdict: - If NOT READY: specific actions to take, in order - If READY: guidance on what to expect during the review process - If there are compliance issues: suggest `/compliance-check` for remediation 7. **End tracking.** After completing all preceding steps, call `devtools_skill_invocation` with action `end` and `skill_name` `app-review-prep`. ## Tips - Rejected submissions often cite the same issues. If history shows a pattern, call it out prominently. - Compliance status is a prerequisite — resolve violations before worrying about other requirements. - Some requirements need evidence (screenshots, privacy policy URLs, etc.) that can't be checked programmatically. Flag these as "manual verification needed."