Activity Feed Skill

How this skill behaves (read first)

This is a generative skill. A feed's job is to surface what matters and let the noise fade — and the defaults work against that: each entry crammed with every available field, loud exact timestamps, every social control on every row, ungrouped notifications buzzing one-by-one, and a blank feed greeting brand-new users in the exact window where they decide whether to stay. There's also a consequential upfront choice — chronological vs. algorithmic/ranked — that teams often make by accident. So this skill gates:

1. Establish the feed type and what the feed is for — chronological vs. ranked is hard to change later and reshapes everything downstream.
2. Apply the always-true core — curate each entry, keep text legible, downplay timestamps, never show an empty feed, show refresh status.
3. Surface the context-dependent decisions (notification aggregation, follow recommendations, per-entry controls) with trade-offs.

Then it hands off to ux-aesthetics-audit, ux-heuristics-audit, ux-accessibility-audit, ux-microcopy-audit, ux-dark-patterns-audit, and ux-mobile-responsiveness-audit for validation.

Scope & composition (per docs/orchestration-policy.md §9): this skill covers the feed screen and its entries and composes lower-scope skills rather than re-deriving them. Core children (built as part of the feed): per-entry card anatomy via ux-cards. Peers that own a sub-part (defer): notification component behavior to ux-notifications-and-toasts and loaders/skeletons to ux-loaders-and-progress (they own those sub-parts if reached). Downstream (offer, don't auto-build): the empty-feed screen craft via ux-empty-states. Inherit, don't regenerate: under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.

Step 0 — Establish context before designing

Ask if not known; state the assumption if proceeding without an answer: