luckiest-co 1.0.0 → 1.0.3

package/.claude-plugin/marketplace.json

@@ -0,0 +1,16 @@
+{
+  "name": "luckiest",
+  "owner": { "name": "Luckiest", "url": "https://luckiest.co" },
+  "metadata": {
+    "description": "Luckiest skills, commands, and your tribe inside Claude. Works in Claude Code, web chat, and Cowork."
+  },
+  "plugins": [
+    {
+      "name": "luckiest",
+      "source": "./",
+      "description": "Plan, go, finish, plus bundled free Luckiest skills that work in Claude Code, web chat, and Cowork.",
+      "version": "0.1.0",
+      "author": { "name": "Luckiest" }
+    }
+  ]
+}

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "luckiest",
   "description": "Plan, go, finish. Guided planning, progress dashboards, and your luckiest.co tribe inside Claude Code.",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "author": { "name": "Luckiest" }
 }

package/LICENSE

@@ -0,0 +1,24 @@
+Luckiest Plugin — License and Alpha Access Grant
+Copyright (c) 2026 Luckiest. All rights reserved.
+
+This plugin and its bundled skills are provided to invited alpha testers for
+personal evaluation only. During the alpha period you may install and use the
+skills for your own work. You may not redistribute, resell, republish, or
+sublicense them, in whole or in part.
+
+Access is provided at no charge during the alpha and may be changed,
+restricted, revoked, or converted to a paid license at any time and without
+notice. Continued availability is not guaranteed.
+
+Third-party portions
+--------------------
+Many of the bundled skills are derivative works of MIT-licensed third-party
+skills (including the "marketingskills" project by Corey Haines and the
+"Superpowers" project by Jesse Vincent). Those upstream portions remain
+governed by their original MIT licenses, whose notices are retained verbatim
+in each skill's ATTRIBUTION.md and/or LICENSE file. This grant governs
+Luckiest's own original content and the plugin as an assembled whole; it does
+not, and cannot, restrict rights already granted under those upstream MIT
+licenses for the upstream portions.
+
+Licensing inquiries: https://luckiest.co

package/bin/install.js

@@ -83,7 +83,7 @@ if (hasHelp) {
     npx luckiest-co --sync-only
 
   ${yellow}What gets installed:${reset}
-    commands/luckiest/   - Slash commands (/luckiest:plan, /luckiest:go, etc.)
+    commands/            - Slash commands (/luckiest:plan, /luckiest:go, etc.)
     references/          - Vocabulary and chart-renderer references
     templates/            - Brief templates
     .claude-plugin/       - Plugin manifest
@@ -178,7 +178,7 @@ function promptKey() {
 }
 
 function apiBaseUrl() {
-  return (process.env.LUCKIEST_API_URL || 'https://luckiest.co').replace(/\/$/, '');
+  return (process.env.LUCKIEST_API_URL || 'https://api.luckiest.co').replace(/\/$/, '');
 }
 
 function hasUnzip() {
@@ -310,11 +310,13 @@ function install(isGlobal) {
 
   console.log(`  Installing to ${cyan}${locationLabel}${reset}\n`);
 
-  // Copy commands/luckiest into commands/luckiest
+  // Copy flat commands/ into commands/luckiest so the subfolder becomes the
+  // `luckiest:` command namespace (=> /luckiest:plan). The repo keeps commands
+  // flat so the plugin install path yields the same single namespace.
   const commandsDir = path.join(claudeDir, 'commands');
   fs.mkdirSync(commandsDir, { recursive: true });
 
-  const commandsSrc = path.join(src, 'commands', 'luckiest');
+  const commandsSrc = path.join(src, 'commands');
   const commandsDest = path.join(commandsDir, 'luckiest');
   if (fs.existsSync(commandsSrc)) {
     copyWithPathReplacement(commandsSrc, commandsDest, pathPrefix);
@@ -322,7 +324,7 @@ function install(isGlobal) {
   }
 
   // Copy references/, templates/, .claude-plugin/ into the target root
-  const topLevelDirs = ['references', 'templates', '.claude-plugin'];
+  const topLevelDirs = ['references', 'templates', 'skills', '.claude-plugin'];
   for (const dir of topLevelDirs) {
     const dirSrc = path.join(src, dir);
     const dirDest = path.join(claudeDir, dir);

package/commands/{luckiest/finish.md → finish.md}

@@ -23,6 +23,8 @@ If every task is complete, write a short recap in chat with these sections:
 
 ## Step 3: Close it out
 
+After the recap, confirm with the AskUserQuestion tool so the user can click instead of typing. Question: "Close this out and award charms?" Options: "Close it out" and "Not yet" (keep the "Other" free-text choice available). Only continue on "Close it out"; on "Not yet", stop and end with `Next: /luckiest go` so they can keep working.
+
 Call the `finish` tool from the luckiest MCP server with:
 
 ```

package/commands/go.md

@@ -0,0 +1,53 @@
+---
+description: Run your plan, one task at a time, checked as it goes.
+---
+
+Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
+
+## Step 1: Load the plan
+
+Call the `status` tool from the luckiest MCP server. This is a zero-context resume, treat its result as the full picture of where things stand: don't assume anything about prior state beyond what it returns.
+
+## Step 2: Pick how to run
+
+Default: do all task work yourself, in this session, message by message. This is the safe, reviewable mode.
+
+Fast mode (subagents): if the user wants tasks done faster, you may hand a ready task to a subagent instead of doing it yourself. Only do this when the user has asked to go fast, or says yes when you offer it. When you dispatch a subagent for a task:
+
+- Run it on the task's `model` hint from `status` (light work like haiku, heavy work like opus), so each task uses the smallest model that fits and saves tokens.
+- Independent tasks can run in parallel; tasks that depend on an earlier one wait for it.
+- You still own Step 3's checks: read the subagent's result, hold it to the "done means..." line, and only then apply and verify.
+
+Research subagents (looking something up, exploring the codebase) are always allowed in either mode.
+
+## Step 3: Work through ready tasks, one at a time
+
+Take the ready tasks one at a time, in order. For each one:
+
+1. First, turn the task into a tight working prompt with the `luckiest-prompt-rewrite` skill, targeting whoever will do the work (yourself, or the subagent and its model from Step 2). Use that rewritten prompt to do the task. If the skill is not installed, write a clear prompt yourself and continue. Do this before every task, in both default and fast mode.
+2. Do the work using the task's suggested skill. If that skill is installed, invoke it via the Skill tool. If it isn't installed, do the work directly without it.
+3. Check your result against the task's "done means..." line. Don't move on until it's actually met.
+4. If the result is something the user can try themselves (a page, a feature, a flow), ask with the AskUserQuestion tool so they can click instead of typing. Question: "Try it yourself, does it work?" Options: "Works" and "Needs fixes" (keep the "Other" free-text choice available). Wait for their answer.
+5. On a pass, call the `apply` tool with `{ taskId }` for that task, then call the `verify` tool with `{ results: [{ taskId, pass: true }] }`.
+6. On a fail, fix the problem before moving on to the next task. Only call `verify` with `pass: false` for that task if the user explicitly chooses to defer the fix instead of having you fix it now.
+
+Only move to the next ready task once the current one is applied and verified (or deferred).
+
+After a task passes and is verified, run a quick automation check. Ask yourself: was this task repeatable, rule-based, or the kind of thing that will come up again? If yes, offer it with the AskUserQuestion tool so the user can click instead of typing. Question: "This looks worth automating. Turn it into a skill you can schedule or run as a routine?" Options: "Automate it" and "Skip" (keep the "Other" free-text choice available). Only offer, never build it without a yes. If they say yes, create the skill (with the skill-builder or skill-creator skill) and set it up to run on a schedule or as a routine. If the task was a one-off, skip the offer and move on.
+
+## Step 4: Stop conditions
+
+Pause and ask the user before doing any of the following, even if it seems like the obvious next step:
+
+- Any destructive action (deleting data, dropping tables, force-pushing, overwriting files with no way back).
+- Adding a new dependency.
+- Any schema change.
+
+If the session has to end before the plan is done, call the `pause` tool with `{ reason }`, a one-line reason describing where things were left.
+
+## Step 5: Wrap up
+
+End your response with exactly one line, nothing after it.
+
+- If all tasks are done: `Next: /luckiest finish to wrap up.`
+- Otherwise: `Next: <the next task title>.`

package/commands/plan.md

@@ -0,0 +1,66 @@
+---
+description: Plan your next piece of work. Guided questions, then a plan Claude can run.
+---
+
+Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
+
+## Step 1: Gather context
+
+Check whether `.luckiest/BRIEF.md` exists in the current project. If it exists, read it and use it as context for the interview below (what they're building, who it's for, what winning looks like). If it does not exist, continue without it.
+
+## Step 2: Check for active work
+
+Call the `status` tool from the luckiest MCP server.
+
+- If the returned state's position is active (already in progress), stop here. Tell the user a plan is already active and offer `/luckiest go` to resume it instead. Do not stage a new plan over an active one unless the user explicitly confirms they want to replace it. If they confirm, continue to Step 3.
+- Otherwise, continue to Step 3.
+
+## Step 3: Run the interview
+
+Open the interview with a short line that says no plan is active and you are starting the interview.
+
+Then ask question 1 using the AskUserQuestion tool so the user can click an answer instead of typing one. Do not put the examples in plain text for them to copy. Present them as selectable options:
+
+1. What do you want to tackle most on this task?
+
+Build 3 to 4 options for that question. Draw them from their brief if one exists, otherwise use plausible outcomes for their project (for example: "About page rewritten to explain the full skills network, live on luckiest.co"). Keep the "Other" free-text choice available so they can still write their own outcome if none fit.
+
+Use the picked option (or their typed answer) plus the brief, if present, to shape the plan.
+
+Use the answer (plus the brief, if present) to shape a draft task list of 3 to 7 tasks. Each task title must be a single clean line under 200 characters, describing one piece of work. Do not append "done means" text or any acceptance-criteria text to the title.
+
+Include non-coding work too. Marketing, content, design, research, and ops tasks belong in the plan alongside code. Never drop a task just because it is not a coding task; route it to its matching skill like any other.
+
+For each draft task, call the `skill_router` tool from the luckiest MCP server. It returns `skills` (matching owned skills) and `who` (up to 3 tribe members who finished a similar task before). Attach the suggested skill(s) to the task, and attach `who` so the plan can carry who has done this kind of work.
+
+For each task, state a one-line "done means..." in chat (not in the title, not stored anywhere) so the user sees what complete looks like for that task. When `who` is not empty, add a short line naming those people, for example "Done before by: Sam, Alex."
+
+## Step 4: Present the plan
+
+Show the full draft plan: each task's title, its suggested skill(s), and its "done means..." line. Then ask exactly one approval question using the AskUserQuestion tool so the user can click instead of typing. Use "Here's your plan, good to go?" as the question, with these options (keep the "Other" free-text choice available for anything else):
+
+- "Good to go" — stage the plan as shown.
+- "Make changes" — the user wants edits before staging.
+
+Wait for the answer.
+
+- If the user picks "Make changes" (or types their own edit), revise the plan and ask the same approval question again.
+- If the user picks "Good to go", continue to Step 5.
+
+## Step 5: Stage the plan
+
+Call the `plan` tool from the luckiest MCP server with:
+
+```
+{ phase: <short phase name if any>, tasks: [{ title, skills, who }] }
+```
+
+Pass the `who` list you got from `skill_router` for each task so the plan keeps who has done this kind of work before.
+
+Include at most 25 tasks. Each title must stay under 200 characters. Do not include acceptance criteria or "done means" text in any task field.
+
+## Step 6: Wrap up
+
+End your response with exactly one line, nothing after it:
+
+Next: /luckiest go to start.

package/package.json

@@ -1,9 +1,20 @@
 {
   "name": "luckiest-co",
-  "version": "1.0.0",
+  "version": "1.0.3",
   "description": "Luckiest for Claude Code: plan, go, finish. Your luckiest.co skills and tribe, inside Claude.",
-  "bin": { "luckiest-co": "./bin/install.js" },
-  "files": ["bin", "commands", "references", "templates", ".claude-plugin"],
-  "license": "MIT",
-  "engines": { "node": ">=18" }
+  "bin": {
+    "luckiest-co": "./bin/install.js"
+  },
+  "files": [
+    "bin",
+    "commands",
+    "references",
+    "templates",
+    "skills",
+    ".claude-plugin"
+  ],
+  "license": "SEE LICENSE IN LICENSE",
+  "engines": {
+    "node": ">=18"
+  }
 }

package/skills/brainstorm/ATTRIBUTION.md

@@ -0,0 +1,27 @@
+# Attribution
+
+This skill is adapted from the "brainstorming" skill in Superpowers
+(https://github.com/obra/superpowers) by Jesse Vincent (obra), used under
+the MIT License.
+
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/brainstorm/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: brainstorm
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — check files, docs, recent commits
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
+6. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
+7. **User reviews written spec** — ask user to review the spec file before proceeding
+8. **Transition to implementation** — invoke writing-plans skill to create implementation plan
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write design doc" [shape=box];
+    "Spec self-review\n(fix inline)" [shape=box];
+    "User reviews spec?" [shape=diamond];
+    "Invoke writing-plans skill" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write design doc" [label="yes"];
+    "Write design doc" -> "Spec self-review\n(fix inline)";
+    "Spec self-review\n(fix inline)" -> "User reviews spec?";
+    "User reviews spec?" -> "Write design doc" [label="changes requested"];
+    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
+}
+```
+
+**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+
+## The Process
+
+**Understanding the idea:**
+
+- Check out the current project state first (files, docs, recent commits)
+- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
+- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
+- For appropriately-scoped projects, ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+**Design for isolation and clarity:**
+
+- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
+- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
+- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
+- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.
+
+**Working in existing codebases:**
+
+- Explore the current structure before proposing changes. Follow existing patterns.
+- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
+- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
+
+## After the Design
+
+**Documentation:**
+
+- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
+  - (User preferences for spec location override this default)
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Spec Self-Review:**
+After writing the spec document, look at it with fresh eyes:
+
+1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
+2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
+3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?
+4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.
+
+Fix any issues inline. No need to re-review — just fix and move on.
+
+**User Review Gate:**
+After the spec review loop passes, ask the user to review the written spec before proceeding:
+
+> "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
+
+Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
+
+**Implementation:**
+
+- Invoke the writing-plans skill to create a detailed implementation plan
+- Do NOT invoke any other skill. writing-plans is the next step.
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design, get approval before moving on
+- **Be flexible** - Go back and clarify when something doesn't make sense

package/skills/luckiest-ab-testing/ATTRIBUTION.md

@@ -0,0 +1,35 @@
+# Attribution
+
+This skill, **luckiest-ab-testing**, is a rebranded and modified ("Luckiest edition")
+derivative of the original skill **"ab-testing"** from the **marketingskills** project
+(https://github.com/coreyhaines31/marketingskills) by **Corey Haines** (https://corey.co),
+distributed under the MIT License.
+
+The original copyright and license notice are reproduced verbatim below and are retained
+in full as required by the MIT License.
+
+---
+
+## Original License (verbatim)
+
+MIT License
+
+Copyright (c) 2025 Corey Haines
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/luckiest-ab-testing/CHANGELOG.md

@@ -0,0 +1,27 @@
+# Changelog — luckiest-ab-testing
+
+## 1.1.0 — 2026-07-06
+Skill updater pass: analytics integration.
+
+### Analytics (report_usage)
+- Updated `report_usage` call to `skill_version: "1.1.0"` and `check_updates`
+  `installedSemver: "1.1.0"`. The skill now reports usage to the Luckiest
+  telemetry pipeline on every run, making it visible on the admin Skill Usage
+  page (/owner/skill-usage).
+
+## 1.0.0 — 2026-07-01
+Rebranded from ab-testing (marketingskills, MIT).
+
+### Improve pass (/refract)
+- Added Sample Ratio Mismatch (SRM) as a mandatory Step 0 data-quality check before reading any metric, plus a dedicated SRM section in the sample-size guide and a results-template row. SRM was a genuine gap: the source covered peeking thoroughly but had no data-integrity guardrail.
+- Added a low-traffic default: when the sample-size math exceeds ~60 days, steer to Bayesian/sequential/CUPED/qualitative instead of grinding a fixed-horizon test.
+- Added trigger phrases: "sample ratio mismatch," "SRM," "my test results look weird," "why is my split uneven," "Bayesian A/B test." Added eval #8 covering the SRM edge case.
+
+### Network hook
+- Share-with-tribe: after a winning test's playbook entry is written, the skill OFFERS to surface the sanitized winning pattern to the user's Luckiest tribe (never auto-posts; excludes raw traffic data, customer records, and any credentials/tokens).
+
+### Trend pass (/newsjack + /luckiest-trends)
+- Sample Ratio Mismatch prevalence ~6-10% of A/B tests; check-before-metrics is the standard guardrail — VWO "20 Best Practices for A/B Testing in Enterprise for 2026" (vwo.com); Kameleoon; Microsoft Research "Diagnosing Sample Ratio Mismatch" — 2026-07-01.
+- CUPED variance reduction (Microsoft) can tighten confidence intervals without more traffic (~equivalent to +20% traffic for one team); added to the low-traffic options — KDnuggets "A/B Testing Pitfalls"; GrowthBook — 2026-07-01.
+- Sequential testing with anytime-valid confidence sequences (Netflix approach) noted as the modern basis for early stopping — 2026-07-01.
+- Note: /luckiest-trends requires a full multi-source setup wizard outside this task's timebox; signal above was gathered via host web search and is dated/attributed.