skills/wc-building-block-crossover/SKILL.md
The recombination operator for the FIFA World Cup Fantasy evolution engine. Crosses elite candidate squads/plans at BUILDING-BLOCK boundaries (Captain Core, Clean-Sheet Spine, Mid-Engine, Differential Pod, Enabler Bench; or for matchday plans the XI/captain-ladder/bench/sub/chip blocks) — harvesting the strongest module from each parent rather than swapping individual players — then runs a feasibility REPAIR operator (budget, nation cap, formation, 15-man shape) that restores legality from the cheapest block first and never guts a value-bearing block. Records block lineage (which parent each block came from). Implements the Evolution document's central lesson that naive crossover destroys good building blocks. Use in the recombine stage after fitness selection.
npx skillsauth add lyndonkl/claude wc-building-block-crossoverInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Implements the recombination step of evolution-protocol.md against the module map in building-blocks.md. The discipline that defines this skill, straight from the Evolution document: a squad is not a flat list of independent slots; it is modules with internal linkage, and crossover must operate at module boundaries or it destroys the very things that make the parents good. "Excellent planning + Excellent memory without rediscovering both independently" — here: the best captain core and the best clean-sheet stack, fused.
tournament-state.md: budget (group $100m / KO $105m), nation cap (3 group, current-phase cap KO), phase.- [ ] 1. For each block slot, rank the elites by that block's quality (per-block fitness contribution)
- [ ] 2. Compose offspring by harvesting the top block from different parents (try a few combinations)
- [ ] 3. REPAIR each offspring to feasibility — cheapest block first, never gut a value block
- [ ] 4. Drop any offspring whose parents' blocks are fundamentally incompatible (repair would break a block)
- [ ] 5. Record block lineage per offspring; emit the feasible offspring
For a squad, the blocks are BB1 Captain Core, BB2 Clean-Sheet Spine, BB3 Mid-Engine, BB4 Differential Pod, BB5 Enabler Bench (BB6 Fixture/Timing is the constraint layer, enforced in repair). For each block, identify which elite has the best version (highest contribution to fitness for that module — best captain core, best stack, sharpest pod). Compose 2–4 candidate offspring by mixing: e.g.
offspring_1 = BB1(A1) + BB2(A4) + BB3(A5) + BB4(A2) + BB5(cheapest-feasible)
offspring_2 = BB1(A6) + BB2(A3) + BB3(A5) + BB4(A4) + BB5(...)
Harvest whole blocks, not players. Do not pluck one defender out of a stack — the stack's value is its correlation; take it or leave it. For a matchday plan, cross MB2 captain-ladder from one parent, MB3 bench-order from another, MB1 XI / MB4 sub-triggers / MB5 chip likewise — keeping each block internally intact.
Recombined blocks will usually break BB6 constraints. Repair in this order, preserving value-bearing blocks:
Repair invariant: never satisfy a constraint by destroying a block. If, say, the only way to afford BB1(A1)'s captain core is to break BB2(A4)'s stack, the two parents are incompatible — drop that offspring and report it rather than emit a mangled squad. An incompatible pairing is information (those two genotypes don't fuse this round), not something to force.
For each surviving offspring record:
offspring_id: <id>
blocks:
BB1_captain_core: { from: A1, players: [...] }
BB2_clean_sheet: { from: A4, players: [...] }
BB3_mid_engine: { from: A5, players: [...] }
BB4_differential: { from: A2, players: [...] }
BB5_enabler_bench: { from: repair, players: [...] }
repair_log: [ "downgraded enabler X→Y for $1.5m", "swapped nation-clash bench Z" ]
feasible: true
Lineage feeds the board ("A1 core + A4 stack + A2 pod") and the archetype scoreboard (which genotypes' blocks keep getting chosen). Hand the offspring to mutation, then diversity.
testing
Cluster a conference's event records into a small set of coarse themes with finer sub-clusters, an explicit outlier bucket, and soft (multi-membership) affinities — using the hybrid embed-then-label pipeline (embed abstracts, reduce, density-cluster, then LLM-label the clusters) when embedding libraries are available, and an LLM-reasoned hierarchical fallback when they are not. Embeddings do the grouping; the LLM only names the groups. Conference-agnostic. Use when turning structured event records into a navigable theme map for preference elicitation and scheduling, when you need 6-8 reasonable themes rather than 20 muddy ones, or when overlapping talks must belong to more than one theme. Trigger keywords - theme clustering, cluster talks, embed then label, soft membership, outlier talks, conference themes, topic map.
development
Build a personal conference schedule as a constraint-optimization problem — hard constraints (no time overlap, room-to-room travel time, capacity/registration, the attendee's own must-attends and blackouts) plus a user-owned weighted objective trading interest against breadth, pacing (maximize contiguous free time), and serendipity. Surfaces unbreakable conflicts (two high-value overlapping talks the model cannot rank) as decisions for the human rather than silently picking, and reports what each choice traded away. Conference-agnostic. Use to turn a preference profile plus a theme map into a day-by-day plan, to resolve overlapping sessions, or to balance a packed vs paced schedule. Trigger keywords - schedule optimization, conference schedule, constraint optimization, overlapping talks, contiguous free time, conflict surfacing, packed vs paced.
development
Parse a heterogeneous conference program (markdown, HTML, PDF-derived text, or JSON) into normalized event records with per-field confidence scores and independent classification axes (topic, depth, format, prerequisites, recorded, capacity). Detects the program's format before extracting, treats every inferred field as uncertain (present vs inferred vs missing), and flags thin or missing abstracts so downstream enrichment can target them. Conference-agnostic. Use when ingesting a conference or event schedule into a structured store, normalizing a talk/session list, or extracting per-session metadata with calibrated confidence. Trigger keywords - program ingestion, parse schedule, session extraction, event records, conference program, talk metadata, per-field confidence.
development
Build a personalized preference profile from a small number of well-chosen, cluster-grounded questions instead of a long survey. Represents the person's interests as an uncertainty region over the theme map, picks the single highest-information-gain choice-based question (contrasting real talks from different clusters), balances exploiting known interests against exploring uncertain ones, deliberately injects outlier probes to fight selection bias, and stops as soon as the schedule would be stable. Also elicits the user-owned objective weights and hard constraints. Interactive — runs where it can actually ask the person. Conference-agnostic. Use to turn a theme map into a preference profile, to decide what to ask a conference attendee, or to elicit scheduling priorities. Trigger keywords - preference elicitation, ask few questions, information gain, choice-based questions, selection bias probe, objective weights, attendee preferences.