Research Playbook

How to actually gather this information, per platform, without hallucinating feature details from training data alone.

Source hierarchy (prefer higher, verify lower)

Direct observation — visit the live web app yourself with the browser tools and look. This is the only way to describe real motion/animation behavior and current layout. It's also the only source for things that change constantly (button placement, icon styles).
Official documentation — Help Center / Support articles (these usually enumerate every report reason, every privacy setting, every moderation tool precisely, because they're written for support agents too), official engineering blogs, published algorithm explainers, and — for X specifically — the open-sourced ranking code repositories.
Reputable secondary sources — UX teardown publications, design case studies, credible tech journalism covering a specific feature launch. Fine for context and for filling gaps observation can't reach (e.g. behavior behind a login wall you can't access), but say so.
Training-data recall — only as a last resort, and label it as such in the output ("not independently verified this session — recalled, may be stale"). Social apps change fast; a remembered feature may have been renamed, removed, or redesigned since your knowledge cutoff. Never present recalled information with the same confidence as something you just observed or read.

Live observation

Set a mobile viewport first, every time. Before observing any screen, call mcp__Claude_Browser__resize_window with preset: "mobile" (375x812, and it switches the user agent + touch emulation too — reload the page after switching so any load-time device gates re-run). These products are designed thumb-first; desktop web frequently hides or redesigns the interactions that actually matter (bottom tab bars, swipe gestures, full-bleed media, thumb-zone placement). Only drop to desktop width when you specifically need to compare how a layout reflows, or when a platform's mobile web is materially worse than desktop for observation purposes (note that explicitly if so).

Getting rebuild-level precision, not just descriptions

Eyeballing a screenshot gets you "the button looks rounded and dark." You can do much better by reading the actual rendered CSS with mcp__Claude_Browser__javascript_tool. This is the technique that turns a vague description into a spec someone could rebuild from:

// exact computed style for a specific element (find it first via find/read_page, then
// target it with a CSS selector or by walking from a data-testid/aria-label if present)
const el = document.querySelector('SELECTOR_FOR_THE_ELEMENT');
const cs = getComputedStyle(el);
({
  color: cs.color, background: cs.backgroundColor, font: cs.font,
  padding: cs.padding, margin: cs.margin, borderRadius: cs.borderRadius,
  boxShadow: cs.boxShadow, transition: cs.transition, animation: cs.animation
})

For an element's animation specifically, cs.transition/cs.animation gives you the duration and timing-function directly (e.g. "transform 0.2s cubic-bezier(0.34, 1.56, 0.64, 1)" tells you it's a springy overshoot, not a guess). If the value references a named @keyframes rule, you can pull the keyframe percentages/values too by scanning document.styleSheets for a matching rule. This works for anything rendered as real DOM/CSS — which covers most of a mobile web app. It won't work for native-app-only interactions with no web equivalent (a truly native gesture has no CSS to read) — for those, fall back to the qualitative description approach and say so.

Use this liberally on the highest-value elements: primary action buttons, cards/post containers, modals/sheets, the nav bar, and anything with a hover/press/loading state change. You don't need to CSS-inspect every single element on a screen — spend this effort where the rebuild value is highest.

Use the in-app Browser tools (mcp__Claude_Browser__*) to visit the platform's web app:

Threads: threads.net
LinkedIn: linkedin.com (most of the feed and profile UI is visible logged out; some interactions redirect to a login wall — note where that happens, it's itself a UX decision worth cataloging)
Instagram: instagram.com
X: x.com
Reddit: reddit.com (also check old.reddit.com — Reddit maintains two UI generations side by side, which is itself worth noting as a design decision)

Logged-out access is limited on several of these (infinite scroll may cut off, some actions prompt a login modal). That's fine — catalog what's reachable, note explicitly what's behind the login wall so the report doesn't silently claim completeness it doesn't have, and lean on documentation/secondary sources to fill the gap for anything you can't reach directly.

Use read_page (accessibility tree) over screenshots when you need to verify exact text/labels — it's more reliable than reading pixels. Use screenshot/zoom when the thing you're describing is visual (layout, spacing, an animation's before/after frames via two screenshots a moment apart). Use find to locate specific controls (e.g. searching "report" or "more options") rather than hunting visually.

For animations, prefer the CSS-inspection technique above for exact numbers. When that's not possible (native-only gesture, or the timing only shows up mid-transition and you can't catch it in the computed style), trigger the interaction and take two screenshots close together (or use get_page_text/read_page before and after) to infer what changed, and describe the character of the motion (spring vs linear, fast vs lingering) rather than inventing precise numbers you didn't actually extract.

Web research

Use WebSearch/WebFetch for the documentation and algorithm layer. Useful query patterns:

"<platform>" engineering blog feed ranking algorithm
"<platform>" help center report a post reasons
"<platform>" "content moderation" policy transparency
site:github.com <platform> algorithm (X has published ranking code publicly)
"<platform>" design teardown OR UX case study <specific feature>

Cross-reference at least two sources for anything you plan to state as fact about the ranking algorithm — platforms publish selectively and sometimes inaccurately/incompletely, and secondary sources sometimes reverse-engineer claims that turn out wrong.

Orchestration: parallel research per platform

Given the amount of ground to cover, run one subagent per platform in parallel rather than researching platforms serially. Each subagent needs to be self-contained (it starts cold) — give it:

The platform name and its web URL
The paths to feature-taxonomy.md, ux-ui-framework.md, and this playbook (so it can Read them directly rather than you re-pasting the content)
The exact output file paths to write
Explicit permission/expectation to use the Browser tools and WebSearch/WebFetch

Template subagent prompt (fill in {platform}, {url}, {output_dir}, {skill_dir}):

Research {platform} ({url}) for a deep feature-and-design catalog. This feeds a larger
cross-platform research project comparing social media apps. Take real time on this — it should
take multiple browsing passes and many searches, not a quick skim. Depth is the whole point.

First read these files for the methodology and the checklists to work through:
- {skill_dir}/references/feature-taxonomy.md
- {skill_dir}/references/ux-ui-framework.md
- {skill_dir}/references/research-playbook.md
- {skill_dir}/references/brand-marketing-framework.md (only needed if you're also asked to
  produce the brand-marketing-kit.md file below)
- {skill_dir}/references/psychology-persuasion-framework.md (only needed if you're also asked
  to produce the psychology-and-persuasion.md file below)

Then produce three files (plus a fourth and/or fifth if those angles apply — see below):

1. {output_dir}/{platform}/feature-catalog.md — work through EVERY category in
   feature-taxonomy.md for {platform} specifically, not a subset. For each feature: name,
   where it lives, exactly what it does (real mechanics, not generic description), why it's
   there. If you catch yourself wanting to stop after a handful of categories, that's a sign to
   keep going — sweep the whole taxonomy.

2. {output_dir}/{platform}/algorithm-and-mindset.md — how {platform}'s ranking/discovery
   algorithm works (cite sources), what growth loops and retention mechanics drive its
   success, and the core product "mindset" — what behavior is this app fundamentally designed
   to produce, and how do its biggest features serve that.

3. {output_dir}/{platform}/ux-ui-catalog.md — work through the FULL screen inventory and
   component/interaction catalog from ux-ui-framework.md for {platform}'s actual current UI.
   Set a mobile viewport first (resize_window preset "mobile") and treat mobile as the primary
   surface — this is a mobile-first product and desktop web hides real interaction design.
   Visit the live app with the browser tools to observe real layouts and animations rather than
   relying on memory, and use the computed-CSS inspection technique in the playbook
   (javascript_tool + getComputedStyle) to pull exact colors, spacing, corner radii, font specs,
   and animation durations/easing wherever the element is real DOM/CSS — the deliverable should
   be precise enough that someone could rebuild the screen from your notes, not just recognize
   it. For every element, also name the mechanism behind why it works (use the glossary in
   ux-ui-framework.md) — don't just describe what it looks like.

4. (Only if the brand/marketing angle applies) {output_dir}/{platform}/brand-marketing-kit.md
   — work through brand-marketing-framework.md's four sections for {platform}: brand identity
   (color/type/logo/icon style/voice/positioning), a design-tokens reference table pulled from
   the same computed-CSS values you gathered for the UX/UI catalog (reuse them, don't re-derive),
   growth/lifecycle marketing mechanics, and copywriting patterns with real quoted examples. Also
   emit the machine-readable exports described in that framework file's Design Tokens section:
   {output_dir}/{platform}/design-tokens.json, design-tokens.css, and tailwind.tokens.js — only
   real, sourced values, nothing stubbed.

5. (Only if the psychology/behavioral/dark-pattern angle applies)
   {output_dir}/{platform}/psychology-and-persuasion.md — work through
   psychology-persuasion-framework.md's three sections for {platform}: Cialdini's six principles
   mapped to specific already-observed features, the full Hook Model loop narrated as a cycle
   (trigger → action → variable reward → investment → next trigger), and a dark-patterns audit
   against Brignull's taxonomy, stating honest absences as well as findings. This is diagnostic
   writing, not a manipulation guide — keep the framing audit-style throughout.

Follow the source hierarchy in research-playbook.md: prefer direct observation, then official
docs, then reputable secondary sources, and explicitly label anything you couldn't verify this
session. Note anything you couldn't reach because of a login wall rather than silently omitting
it.

Report back a short summary of what you found and any gaps, once the three files are written.

Quality bar before delivering

Every non-obvious claim about the algorithm traces to a source — no uncited assertions about "how the algorithm works" stated as fact.
Every "why it works" line names a real mechanism, not a vague adjective.
Gaps are named explicitly ("couldn't verify X — behind login wall / not publicly documented") rather than silently skipped.
Recalled-but-unverified information is labeled as such.
Report reasons, moderation tools, and other enumerable lists are actually enumerated in full where a source made that possible — not summarized as "various reasons."
Full coverage of the taxonomy/framework checklists, not a representative sample — a stopping point after 4-5 categories or a couple of screens is premature, not a finished pass.
UI specs carry real extracted values (color/spacing/radius/font/timing) wherever the element is real DOM/CSS, not just adjectives — this is what makes the catalog rebuildable.

/social-media-app-researcher

referencesresearch-playbook.md