luckiest-co 1.0.9 → 1.0.11

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.8",
+      "version": "0.1.12",
       "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.10",
+  "version": "0.1.12",
   "author": { "name": "Luckiest" }
 }

package/bin/install.js

@@ -212,6 +212,7 @@ async function syncSkills() {
     console.log(`  ${green}✓${reset} Removed duplicate commands/luckiest (plugin marketplace already provides them)`);
   }
 
+  nudgeStaleInstall(globalDir);
   nudgeUsageHook(globalDir);
 
   const key = readSavedKey();
@@ -478,6 +479,51 @@ function nudgeUsageHook(globalClaudeDir) {
   console.log(`  ${dim}Skill usage tracking is off. Run ${cyan}npx luckiest-co@latest --hook${dim} to turn it on.${reset}`);
 }
 
+/**
+ * Numeric semver-ish compare. Returns >0 when a is newer than b.
+ * String compare would read "0.1.10" as older than "0.1.9", which is exactly
+ * the version pair this shipped on.
+ */
+function compareVersions(a, b) {
+  const pa = String(a).split('.').map((n) => parseInt(n, 10) || 0);
+  const pb = String(b).split('.').map((n) => parseInt(n, 10) || 0);
+  for (let i = 0; i < Math.max(pa.length, pb.length); i += 1) {
+    const diff = (pa[i] || 0) - (pb[i] || 0);
+    if (diff !== 0) return diff;
+  }
+  return 0;
+}
+
+function readPluginVersion(root) {
+  try {
+    return JSON.parse(fs.readFileSync(path.join(root, '.claude-plugin', 'plugin.json'), 'utf8')).version || null;
+  } catch {
+    return null;
+  }
+}
+
+/**
+ * Tell people when their installed copy is behind.
+ *
+ * Both update paths are pull-based, so someone who installed once can sit on an
+ * old copy indefinitely with nothing to tell them. Sync runs every session, and
+ * `npx luckiest-co@latest` always fetches the newest package, so the version
+ * this process is running from is by definition current — comparing it against
+ * the copy on disk needs no server call.
+ *
+ * Silent when current, when nothing is installed to compare against, or when
+ * the marketplace plugin is in charge (that copy updates through Claude's own
+ * plugin menu, not this installer).
+ */
+function nudgeStaleInstall(globalClaudeDir) {
+  if (hasMarketplacePlugin(globalClaudeDir)) return;
+  const installed = readPluginVersion(globalClaudeDir);
+  const current = readPluginVersion(path.join(__dirname, '..'));
+  if (!installed || !current) return;
+  if (compareVersions(current, installed) <= 0) return;
+  console.log(`  ${dim}Your Luckiest install is ${cyan}v${installed}${dim}, latest is ${cyan}v${current}${dim}. Run ${cyan}npx luckiest-co@latest${dim} to update.${reset}`);
+}
+
 /**
  * Register the PostToolUse(Skill) telemetry hook in the user's settings.json.
  *

package/commands/finish.md

@@ -4,6 +4,33 @@ 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.
 
+Asking the user a question: this command tells you to use the AskUserQuestion tool
+so the user can click instead of typing. That tool only exists in Claude Code. In
+web chat and Cowork it is not there, and waiting for it will stall the command.
+
+So, every time this command says to use AskUserQuestion:
+
+- If the tool is available, use it exactly as written.
+- If it is not, ask the same question in plain chat as a numbered list of the
+  same options, and tell the user to reply with a number or type their own
+  answer. Treat a typed answer the same as the "Other" free-text choice.
+
+The options, their order, and their wording stay the same either way. Only the
+delivery changes. Never skip a question, never answer it on the user's behalf,
+and never merge several questions into one just because they are text.
+
+For example, "Here's your plan, good to go?" with options "Good to go" and
+"Make changes" becomes:
+
+```
+Here's your plan, good to go?
+
+1. Good to go
+2. Make changes
+
+Reply with a number, or tell me what to change.
+```
+
 ## 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.

package/commands/go.md

@@ -4,6 +4,33 @@ 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.
 
+Asking the user a question: this command tells you to use the AskUserQuestion tool
+so the user can click instead of typing. That tool only exists in Claude Code. In
+web chat and Cowork it is not there, and waiting for it will stall the command.
+
+So, every time this command says to use AskUserQuestion:
+
+- If the tool is available, use it exactly as written.
+- If it is not, ask the same question in plain chat as a numbered list of the
+  same options, and tell the user to reply with a number or type their own
+  answer. Treat a typed answer the same as the "Other" free-text choice.
+
+The options, their order, and their wording stay the same either way. Only the
+delivery changes. Never skip a question, never answer it on the user's behalf,
+and never merge several questions into one just because they are text.
+
+For example, "Here's your plan, good to go?" with options "Good to go" and
+"Make changes" becomes:
+
+```
+Here's your plan, good to go?
+
+1. Good to go
+2. Make changes
+
+Reply with a number, or tell me what to change.
+```
+
 ## 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.

package/commands/plan.md

@@ -4,6 +4,33 @@ description: Plan your next piece of work. Guided questions, then a plan Claude
 
 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.
 
+Asking the user a question: this command tells you to use the AskUserQuestion tool
+so the user can click instead of typing. That tool only exists in Claude Code. In
+web chat and Cowork it is not there, and waiting for it will stall the command.
+
+So, every time this command says to use AskUserQuestion:
+
+- If the tool is available, use it exactly as written.
+- If it is not, ask the same question in plain chat as a numbered list of the
+  same options, and tell the user to reply with a number or type their own
+  answer. Treat a typed answer the same as the "Other" free-text choice.
+
+The options, their order, and their wording stay the same either way. Only the
+delivery changes. Never skip a question, never answer it on the user's behalf,
+and never merge several questions into one just because they are text.
+
+For example, "Here's your plan, good to go?" with options "Good to go" and
+"Make changes" becomes:
+
+```
+Here's your plan, good to go?
+
+1. Good to go
+2. Make changes
+
+Reply with a number, or tell me what to change.
+```
+
 ## 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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "luckiest-co",
-  "version": "1.0.9",
+  "version": "1.0.11",
   "description": "Luckiest for Claude Code: plan, go, finish. Your luckiest.co skills and tribe, inside Claude.",
   "bin": {
     "luckiest-co": "./bin/install.js"

package/skills/luckiest-finish/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: luckiest-finish
+description: Wrap up a completed Luckiest plan: recap what shipped, close it out, award charms. Use when the user says /luckiest finish, luckiest finish, or all plan tasks are done.
+---
+
+Vocabulary rules for all output: plain language, no em dashes, no internal terms. Never surface internal words like PLAN, APPLY, UNIFY, skill_loop, UAT, AC, HANDOFF, DRAFT, DOING in user-visible output; say plan, go, finish, status, testing, requirements, ready for review, in progress, active, complete instead. End every response with exactly one next-step line in the form `Next: <one action>`.
+
+Project key for luckiest MCP plan tool calls: if a shell is available, run `git config --get remote.origin.url` and normalize to `host/owner/repo` (lowercase, no `.git`); if not a git repo, use the absolute path from `pwd`. If there is no shell at all (web chat, Cowork), omit `project` entirely. Use the same value on every plan tool call this whole session.
+
+Asking the user a question: this command tells you to use the AskUserQuestion tool
+so the user can click instead of typing. That tool only exists in Claude Code. In
+web chat and Cowork it is not there, and waiting for it will stall the command.
+
+So, every time this command says to use AskUserQuestion:
+
+- If the tool is available, use it exactly as written.
+- If it is not, ask the same question in plain chat as a numbered list of the
+  same options, and tell the user to reply with a number or type their own
+  answer. Treat a typed answer the same as the "Other" free-text choice.
+
+The options, their order, and their wording stay the same either way. Only the
+delivery changes. Never skip a question, never answer it on the user's behalf,
+and never merge several questions into one just because they are text.
+
+For example, "Here's your plan, good to go?" with options "Good to go" and
+"Make changes" becomes:
+
+```
+Here's your plan, good to go?
+
+1. Good to go
+2. Make changes
+
+Reply with a number, or tell me what to change.
+```
+
+## Step 1: Check that everything is done
+
+Derive the project key as described in the project key rules above. 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/skills/luckiest-go/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: luckiest-go
+description: Run the active Luckiest plan, one task at a time, checked as it goes. Use when the user says /luckiest go, luckiest go, or wants to continue their staged Luckiest plan.
+---
+
+Vocabulary rules for all output: plain language, no em dashes, no internal terms. Never surface internal words like PLAN, APPLY, UNIFY, skill_loop, UAT, AC, HANDOFF, DRAFT, DOING in user-visible output; say plan, go, finish, status, testing, requirements, ready for review, in progress, active, complete instead. End every response with exactly one next-step line in the form `Next: <one action>`.
+
+Project key for luckiest MCP plan tool calls: if a shell is available, run `git config --get remote.origin.url` and normalize to `host/owner/repo` (lowercase, no `.git`); if not a git repo, use the absolute path from `pwd`. If there is no shell at all (web chat, Cowork), omit `project` entirely. Use the same value on every plan tool call this whole session.
+
+Asking the user a question: this command tells you to use the AskUserQuestion tool
+so the user can click instead of typing. That tool only exists in Claude Code. In
+web chat and Cowork it is not there, and waiting for it will stall the command.
+
+So, every time this command says to use AskUserQuestion:
+
+- If the tool is available, use it exactly as written.
+- If it is not, ask the same question in plain chat as a numbered list of the
+  same options, and tell the user to reply with a number or type their own
+  answer. Treat a typed answer the same as the "Other" free-text choice.
+
+The options, their order, and their wording stay the same either way. Only the
+delivery changes. Never skip a question, never answer it on the user's behalf,
+and never merge several questions into one just because they are text.
+
+For example, "Here's your plan, good to go?" with options "Good to go" and
+"Make changes" becomes:
+
+```
+Here's your plan, good to go?
+
+1. Good to go
+2. Make changes
+
+Reply with a number, or tell me what to change.
+```
+
+## Step 1: Load the plan
+
+Derive the project key as described in the project key rules above. 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/skills/luckiest-plan/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: luckiest-plan
+description: Plan your next piece of work with Luckiest. Guided questions, then a staged plan Claude can run. Use when the user says /luckiest plan, luckiest plan, or wants to plan work with their Luckiest tribe.
+---
+
+Vocabulary rules for all output: plain language, no em dashes, no internal terms. Never surface internal words like PLAN, APPLY, UNIFY, skill_loop, UAT, AC, HANDOFF, DRAFT, DOING in user-visible output; say plan, go, finish, status, testing, requirements, ready for review, in progress, active, complete instead. End every response with exactly one next-step line in the form `Next: <one action>`.
+
+Project key for luckiest MCP plan tool calls: if a shell is available, run `git config --get remote.origin.url` and normalize to `host/owner/repo` (lowercase, no `.git`); if not a git repo, use the absolute path from `pwd`. If there is no shell at all (web chat, Cowork), omit `project` entirely. Use the same value on every plan tool call this whole session.
+
+Asking the user a question: this command tells you to use the AskUserQuestion tool
+so the user can click instead of typing. That tool only exists in Claude Code. In
+web chat and Cowork it is not there, and waiting for it will stall the command.
+
+So, every time this command says to use AskUserQuestion:
+
+- If the tool is available, use it exactly as written.
+- If it is not, ask the same question in plain chat as a numbered list of the
+  same options, and tell the user to reply with a number or type their own
+  answer. Treat a typed answer the same as the "Other" free-text choice.
+
+The options, their order, and their wording stay the same either way. Only the
+delivery changes. Never skip a question, never answer it on the user's behalf,
+and never merge several questions into one just because they are text.
+
+For example, "Here's your plan, good to go?" with options "Good to go" and
+"Make changes" becomes:
+
+```
+Here's your plan, good to go?
+
+1. Good to go
+2. Make changes
+
+Reply with a number, or tell me what to change.
+```
+
+## 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 the project key rules above. 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.