luckiest-co 1.0.3 → 1.0.7

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
       "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",
+      "version": "0.1.8",
       "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.2",
+  "version": "0.1.8",
   "author": { "name": "Luckiest" }
 }

package/bin/install.js

@@ -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,48 @@ async function syncSkills() {
   console.log('');
 }
 
+/**
+ * True when the luckiest plugin is installed AND enabled through the Claude
+ * Code plugin marketplace (which registers commands itself). A disabled
+ * plugin still appears in installed_plugins.json but registers nothing, so
+ * treating it as present would delete the user's commands/luckiest copy and
+ * leave them with no /luckiest:* commands at all.
+ */
+function hasMarketplacePlugin(globalClaudeDir) {
+  try {
+    const manifest = JSON.parse(
+      fs.readFileSync(path.join(globalClaudeDir, 'plugins', 'installed_plugins.json'), 'utf8')
+    );
+    const entries = Object.entries(manifest.plugins || {}).filter(([k]) => k.startsWith('luckiest@'));
+    if (entries.length === 0) return false;
+
+    // Some Claude Code versions record enabled state on the install entry itself.
+    const entryDisabled = entries.every(([, v]) => {
+      const items = Array.isArray(v) ? v : [v];
+      return items.every((item) => item && typeof item === 'object' && item.enabled === false);
+    });
+    if (entryDisabled) return false;
+
+    // Others track it in settings.json under enabledPlugins ("name@marketplace": bool).
+    try {
+      const settings = JSON.parse(
+        fs.readFileSync(path.join(globalClaudeDir, 'settings.json'), 'utf8')
+      );
+      const enabledMap = settings.enabledPlugins || {};
+      const flags = entries
+        .map(([k]) => enabledMap[k])
+        .filter((flag) => typeof flag === 'boolean');
+      if (flags.length > 0 && flags.every((flag) => flag === false)) return false;
+    } catch {
+      // No readable settings.json — fall through to "installed means enabled".
+    }
+
+    return true;
+  } catch {
+    return false;
+  }
+}
+
 /**
  * Install to the specified directory
  */
@@ -313,12 +365,24 @@ function install(isGlobal) {
   // 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');
   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`);
   }

package/commands/finish.md

@@ -6,7 +6,9 @@ Read `references/vocabulary.md` first and follow it for all output in this comma
 
 ## Step 1: Check that everything is done
 
-Call the `status` tool from the luckiest MCP server.
+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:
 
@@ -28,7 +30,7 @@ After the recap, confirm with the AskUserQuestion tool so the user can click ins
 Call the `finish` tool from the luckiest MCP server with:
 
 ```
-{ decisions, keyFiles, deferred }
+{ 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.
@@ -37,6 +39,11 @@ Report the Charms earned in friendly, plain terms, for example: "You earned 3 ch
 
 ## Step 4: Wrap up
 
-End your response with exactly one line, nothing after it:
+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

@@ -6,17 +6,26 @@ Read `references/vocabulary.md` first and follow it for all output in this comma
 
 ## 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.
+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. When you dispatch a subagent for a task:
+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.
 
-- 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.
+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.
 
@@ -28,7 +37,7 @@ Take the ready tasks one at a time, in order. For each one:
 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 }] }`.
+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).
@@ -43,7 +52,7 @@ Pause and ask the user before doing any of the following, even if it seems like
 - 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.
+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
 

package/commands/plan.md

@@ -10,7 +10,9 @@ Check whether `.luckiest/BRIEF.md` exists in the current project. If it exists,
 
 ## Step 2: Check for active work
 
-Call the `status` tool from the luckiest MCP server.
+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.
@@ -21,7 +23,7 @@ Open the interview with a short line that says no plan is active and you are sta
 
 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?
+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.
 
@@ -33,7 +35,9 @@ Include non-coding work too. Marketing, content, design, research, and ops tasks
 
 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."
+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
 
@@ -52,15 +56,13 @@ Wait for the answer.
 Call the `plan` tool from the luckiest MCP server with:
 
 ```
-{ phase: <short phase name if any>, tasks: [{ title, skills, who }] }
+{ 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: Wrap up
-
-End your response with exactly one line, nothing after it:
+## Step 6: Start it
 
-Next: /luckiest go to start.
+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/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.3",
+  "version": "1.0.7",
   "description": "Luckiest for Claude Code: plan, go, finish. Your luckiest.co skills and tribe, inside Claude.",
   "bin": {
     "luckiest-co": "./bin/install.js"

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.