luckiest-co 1.0.1 → 1.0.6

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.7",
+      "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.7",
   "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
@@ -195,6 +195,16 @@ function hasUnzip() {
  * Never logs the key or the Authorization header.
  */
 async function syncSkills() {
+  // Self-heal the /luckiest:luckiest:* duplicate: older installers copied
+  // commands into ~/.claude/commands/luckiest even when the marketplace
+  // plugin already registers them. Sync runs every session, so clean it here.
+  const globalDir = expandTilde(explicitConfigDir) || expandTilde(process.env.CLAUDE_CONFIG_DIR) || path.join(os.homedir(), '.claude');
+  const staleCommands = path.join(globalDir, 'commands', 'luckiest');
+  if (hasMarketplacePlugin(globalDir) && fs.existsSync(staleCommands)) {
+    fs.rmSync(staleCommands, { recursive: true, force: true });
+    console.log(`  ${green}✓${reset} Removed duplicate commands/luckiest (plugin marketplace already provides them)`);
+  }
+
   const key = readSavedKey();
   if (!key) {
     console.log(`  ${dim}No luckiest.co connection key saved yet. Run ${cyan}npx luckiest-co${dim} and paste one to sync your owned skills.${reset}`);
@@ -288,6 +298,21 @@ async function syncSkills() {
   console.log('');
 }
 
+/**
+ * True when the luckiest plugin is already installed through the Claude Code
+ * plugin marketplace (which registers commands itself).
+ */
+function hasMarketplacePlugin(globalClaudeDir) {
+  try {
+    const manifest = JSON.parse(
+      fs.readFileSync(path.join(globalClaudeDir, 'plugins', 'installed_plugins.json'), 'utf8')
+    );
+    return Object.keys(manifest.plugins || {}).some((k) => k.startsWith('luckiest@'));
+  } catch {
+    return false;
+  }
+}
+
 /**
  * Install to the specified directory
  */
@@ -310,19 +335,33 @@ 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.
+  //
+  // If the luckiest plugin is already installed via the Claude Code plugin
+  // marketplace, its commands are registered there; a file copy here would
+  // register them a second time and produce /luckiest:luckiest:* duplicates.
+  // In that case skip the copy and remove any stale copy from past installs.
   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)) {
+  if (hasMarketplacePlugin(defaultGlobalDir)) {
+    if (fs.existsSync(commandsDest)) {
+      fs.rmSync(commandsDest, { recursive: true, force: true });
+      console.log(`  ${green}✓${reset} Removed duplicate commands/luckiest (plugin marketplace already provides them)`);
+    } else {
+      console.log(`  ${dim}Skipped commands/luckiest (plugin marketplace already provides them)${reset}`);
+    }
+  } else if (fs.existsSync(commandsSrc)) {
     copyWithPathReplacement(commandsSrc, commandsDest, pathPrefix);
     console.log(`  ${green}✓${reset} Installed commands/luckiest`);
   }
 
   // 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/finish.md

@@ -0,0 +1,49 @@
+---
+description: Wrap up, what shipped, what changed, what's next.
+---
+
+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: Check that everything is done
+
+Derive the project key as described in `references/project-key.md`. Pass this same `project` value on both luckiest plan tool calls in this command (`status` here and `finish` in Step 3), so you close this project's plan and not another one.
+
+Call the `status` tool from the luckiest MCP server with that `project` value.
+
+If any task is still open (not complete), list those tasks for the user and stop here. Do not proceed to the rest of this command. End your response with exactly one line, nothing after it:
+
+Next: /luckiest go
+
+## Step 2: Compose the recap
+
+If every task is complete, write a short recap in chat with these sections:
+
+- **Shipped**: what got built or changed, in plain terms.
+- **Decisions**: any notable choices made along the way and why.
+- **Key files**: the main files touched, so the user knows where to look.
+- **Deferred**: anything explicitly pushed off, if applicable. Say "none" if there's nothing deferred.
+
+## 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:
+
+```
+{ project: <the project key from Step 1>, decisions, keyFiles, deferred }
+```
+
+using the same lists from your recap. This awards Charms and archives the history automatically.
+
+Report the Charms earned in friendly, plain terms, for example: "You earned 3 charms."
+
+## Step 4: Wrap up
+
+Offer the next move with the AskUserQuestion tool so the user can click instead of retyping a command. Question: "What's next?" Options (keep the "Other" free-text choice available):
+
+- "Plan the next piece" — on this pick, start the `/luckiest plan` flow now, fresh, as if newly invoked.
+- "See where I stand" — on this pick, run the `/luckiest home` flow now.
+
+Whichever they click, start that flow immediately in this session so they never have to type the command themselves. If they pick "Other" or dismiss, end with exactly one line, nothing after it:
+
+Next: /luckiest plan for the next piece, or /luckiest home to see where you stand.

package/commands/go.md

@@ -0,0 +1,62 @@
+---
+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
+
+Derive the project key as described in `references/project-key.md`. Pass this same `project` value on every luckiest plan tool call in this command (`status`, `apply`, `verify`, `pause`), so you run this project's plan and not another one.
+
+Call the `status` tool from the luckiest MCP server with that `project` value. 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.
+
+Before dispatching anything, check that you can actually assign agents: confirm the Agent (or Task) tool is available in this session. If it is not, say so plainly and fall back to default mode. Never claim work was handed off to a subagent you could not launch.
+
+When you do run in fast mode, assign work top down in this order: subagents > tasks > skills > model.
+
+- Subagents: one subagent owns a task. Independent tasks run in parallel; tasks that depend on an earlier one wait for it.
+- Tasks: give each subagent one ready task from `status`, turned into a tight working prompt.
+- Skills: inside its task, the subagent invokes the task's suggested skill via the Skill tool.
+- Model: run each subagent 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.
+
+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 `{ project, taskId }` for that task, then call the `verify` tool with `{ project, results: [{ taskId, pass: true }] }`. Use the same `project` from Step 1.
+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 `{ project, reason }` (same `project` from Step 1), 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,68 @@
+---
+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
+
+Derive the project key as described in `references/project-key.md`. Pass this same `project` value on every luckiest plan tool call in this command (`status` here and `plan` in Step 5), so this project gets its own plan and does not collide with another project's.
+
+Call the `status` tool from the luckiest MCP server with that `project` value.
+
+- 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. Let's confirm what best describes the outcome you want
+
+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**."
+
+Whenever you name a skill or a person in your output, wrap it in markdown bold so it stands out, for example **Copywriting** or **Sam**. Bold the skill and person names everywhere they appear in this command, both in the draft plan and in the "done means..." and "done before by" lines.
+
+## 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:
+
+```
+{ project: <the project key from Step 2>, 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: Start it
+
+Once the plan is staged, do not make the user type the next command. Start the `/luckiest go` flow now, fresh, as if newly invoked, so the first task begins immediately in this session.

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

@@ -6,7 +6,7 @@ Read `references/vocabulary.md` and `references/chart-renderer.md` first and fol
 
 ## Step 1: Check for a plan
 
-Call the `status` tool from the luckiest MCP server.
+Derive the project key as described in `references/project-key.md`, then call the `status` tool from the luckiest MCP server with that `project` value so you read this project's plan and not another one.
 
 If the returned state is null (no active plan), output nothing except these two lines, in order:
 

package/package.json

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

package/references/project-key.md

@@ -0,0 +1,24 @@
+# Project key
+
+The Luckiest plan tools (`status`, `plan`, `apply`, `verify`, `finish`, `pause`)
+take an optional `project` value so each project keeps its own separate plan.
+The MCP server is hosted and cannot see your folder, so you must compute this
+key locally and pass it.
+
+## How to derive it (do this once per session, before the first plan tool call)
+
+1. Run: `git config --get remote.origin.url`
+2. If it returns a URL, normalize it to `host/owner/repo`, lowercased, with any
+   `.git` suffix removed. Examples:
+   - `git@github.com:acme/app.git` becomes `github.com/acme/app`
+   - `https://github.com/acme/app.git` becomes `github.com/acme/app`
+3. If step 1 returns nothing (not a git repo), run `pwd` and use that absolute
+   path as the key.
+4. If there is no local shell at all (web chat, Cowork), omit `project` entirely.
+   Those surfaces share one plan, which is correct for them.
+
+## How to use it
+
+Pass the SAME `project` value on every plan tool call for the rest of the
+session: `status`, `plan`, `apply`, `verify`, `finish`, `pause`. Do not change it
+mid-session and do not recompute it per call. One project, one key, all session.

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.