Design composable recommendation, ranking, and feed pipelines using the six-stage Source→Hydrator→Filter→Scorer→Selector→SideEffect framework popularized by xAI's open-sourced For You algorithm.
All-time #3061Trending #2837First seen May 19, 2026
Design composable recommendation, ranking, and feed pipelines using the six-stage Source→Hydrator→Filter→Scorer→Selector→SideEffect framework popularized by xAI's open-sourced For You algorithm.
Use this skill whenever the user is building any system that picks "the top K items for a (user, context)" — social feeds, content CMSs, RAG rerankers, task prioritizers, notification triage, search reranking, ad ranking.
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars254.3K
LicenseLICENSE
Default branchmain
Open issues54
Status
Active
Skill metadata
Parsed from SKILL.md frontmatter.
More metadata
origin
community
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md7,788 B
docsSUMMARY.md458 B
History
First seen on skills.sh
First recorded snapshot · 4,549 installs
SKILL.md
recsys-pipeline-architect
A spec-and-scaffold skill for building composable recommendation, ranking, and feed pipelines. It encodes the six-stage pattern — Source → Hydrator → Filter → Scorer → Selector → SideEffect — popularized by xAI's open-sourced For You algorithm (Apache 2.0). This skill is an independent reimplementation of the pattern (MIT) — no code copied from the original.
Model architecture work (transformer design, two-tower retrieval, embedding training) — this skill is plumbing around the model, not the model itself
Pure ML training pipelines — the scoring function is the user's responsibility
Operating a deployed pipeline (monitoring, autoscaling) — out of scope
The six-stage framework
#
Stage
Job
Parallel?
1
Source
Fetch candidates from one or more origins
Yes — multiple sources run in parallel
2
Hydrator
Enrich each candidate with metadata needed for filtering and scoring
Yes — independent hydrators run in parallel
3
Filter
Drop candidates that should never be shown (blocked, expired, duplicate, ineligible)
Sequential — each filter sees fewer items
4
Scorer
Assign each surviving candidate one or more scores
Sequential — later scorers see earlier scores
5
Selector
Sort by final score, return top K
Single op
6
SideEffect
Cache served IDs, log impressions, emit events, update counters
Async — must never block the response
Why this exact order
Sources before hydration: know what candidates exist before paying to enrich them
Hydration before filtering: many filters need metadata the source did not provide
Filtering before scoring: scoring is the expensive stage; drop the ineligible first
Scorer chain (not single scorer): real systems compose ML scoring + diversity reranking + business rules
Selector after scoring: keeps scoring deterministic and cacheable
SideEffects last and async: side effects must never block the user response
Workflow when invoked
Walk the user through these eight steps:
Clarify the use case (one round, three questions): items being ranked? input context? language/runtime?
Identify the candidate sources: usually in-network (followed/owned/subscribed) + out-of-network (ML retrieval / trending / similar-to-liked)
List required hydrations: for each filter and scorer, what data does it need that the source did not provide?
List the filters: duplicate, self, age, block/mute, previously-served, eligibility. Order matters — cheap before expensive.
Design the scorer chain: primary (ML) → combiner (multi-action with weights) → diversity → business rules
Selector: sort descending by final score, take top K (or stratified mix for in-network/out-of-network)
SideEffects: cache served IDs, emit impression events, update counters, log analytics — all fire-and-forget
Generate the scaffold in the user's stack
Key trade-offs to surface (don't default silently)
1. Single score vs multi-action prediction
Single score: train one model to predict relevance. To change behavior → retrain.
Multi-action: predict P(action) for many actions (read, like, share, skip, report), combine with weights at serving time. To change behavior → change weights. No retraining.
The X For You system uses multi-action with both positive and negative weights. Recommend multi-action when the user expects to tune frequently.
2. Candidate isolation in scoring
Isolated: each candidate scored independently. Deterministic, cacheable.
Joint: candidates attend to each other during scoring (e.g., transformer over batch). More expressive but non-deterministic across batches.
Default to isolation. Joint only when there's a specific reason (e.g., explicit batch-aware diversity).
3. Online vs offline
Request-time (online): pipeline runs on each request. Latency budget: 100–300ms. Default.
Do not invent benchmark numbers. "How much faster?" → "depends on workload, run it yourself."
Attribution discipline. When the pattern is referenced, attribute as "popularized by xAI's open-sourced For You algorithm" / github.com/xai-org/x-algorithm (Apache 2.0).
No trademark use. Do not name the user's artifact "X-like" or use "For You" branding. Pattern is free; brand is not. Suggested naming: "candidate pipeline", "feed pipeline", "ranking pipeline", "recsys pipeline".
Surface trade-offs. Multi-action vs single, isolation vs joint, online vs offline — never default silently.
The generated scaffold must run. No pseudocode passing as code.
Filter order matters. Cheap before expensive. Universal before user-specific.
Side effects never block. Wrap in fire-and-forget patterns (goroutines / promises without await / asyncio tasks).
Anti-Patterns
Scoring before filtering (wastes compute on candidates that will be dropped anyway)
Synchronous side effects (cache writes / impression emits blocking the response)
A single "relevance" score when the product needs to tune for multiple objectives (engagement vs safety vs diversity vs ads)
Joint scoring as default (non-deterministic, harder to cache, doesn't compose with reranking stages)
Generating pseudocode "for illustration" — the scaffold must actually run