luckiest-co 1.0.11 → 1.0.13

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.12",
+      "version": "0.1.14",
       "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.12",
+  "version": "0.1.14",
   "author": { "name": "Luckiest" }
 }

package/commands/charms.md

@@ -2,7 +2,9 @@
 description: Your charms balance and recent related activity.
 ---
 
-Read `references/vocabulary.md` and `references/chart-renderer.md` first and follow them for all output in this command.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
+
+Read `references/chart-renderer.md` before rendering any chart and follow it.
 
 ## Step 1: Get the data
 
@@ -27,7 +29,7 @@ Example:
  → /luckiest charms
 ```
 
-Use only user-facing vocabulary from `references/vocabulary.md`. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
 
 ## Step 3: Recommend next action
 

package/commands/finish.md

@@ -2,7 +2,7 @@
 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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 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
@@ -33,7 +33,7 @@ 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.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. 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.
 

package/commands/go.md

@@ -2,7 +2,7 @@
 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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 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
@@ -33,7 +33,7 @@ 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.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. 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.
 
@@ -60,7 +60,7 @@ Research subagents (looking something up, exploring the codebase) are always all
 
 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.
+1. If the task is being handed to a subagent (fast mode), first turn it into a tight working prompt with the `luckiest-prompt-rewrite` skill, targeting that subagent and its model from Step 2; if the skill is not installed, write a clear prompt yourself. When you are doing the task yourself, skip the rewrite and start working; the task title and its "done means..." line are the prompt.
 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.
@@ -71,6 +71,9 @@ Only move to the next ready task once the current one is applied and verified (o
 
 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.
 
+
+Shell note: always quote file paths in shell commands. Paths with parentheses or brackets (for example `app/(public)/orders`) break zsh globbing when unquoted and waste turns on retries. Prefer the dedicated file tools (Read, Glob, Grep) over shell listing commands when either works.
+
 ## Step 4: Stop conditions
 
 Pause and ask the user before doing any of the following, even if it seems like the obvious next step:

package/commands/helpers.md

@@ -2,7 +2,9 @@
 description: See who needs a hand right now, and claim a request to help.
 ---
 
-Read `references/vocabulary.md` and `references/chart-renderer.md` first and follow them for all output in this command.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
+
+Read `references/chart-renderer.md` before rendering any chart and follow it.
 
 ## Step 1: Get the data
 
@@ -55,7 +57,7 @@ Example:
  → tell me "claim a13" and I'll pick it up with respond_to_assist
 ```
 
-Use only user-facing vocabulary from `references/vocabulary.md`. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term. Do not fabricate requests, posters, or rewards beyond what the tools return.
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term. Do not fabricate requests, posters, or rewards beyond what the tools return.
 
 ## Step 3: Recommend next action
 

package/commands/home.md

@@ -2,7 +2,9 @@
 description: The community dashboard. Wishes and charms, plan progress, tribe pulse, and who needs help.
 ---
 
-Read `references/vocabulary.md` and `references/chart-renderer.md` first and follow them for all output in this command.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
+
+Read `references/chart-renderer.md` before rendering any chart and follow it.
 
 ## Step 1: Get the data
 
@@ -33,7 +35,7 @@ Render one fenced code block following the chart-renderer grammar, with four box
    - One line: `open requests X` where X is `openAssists`.
    - Footer: `→ /luckiest helpers`
 
-Use only user-facing vocabulary from `references/vocabulary.md`. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
 
 ## Step 3: Recommend next action
 

package/commands/leaderboard.md

@@ -2,7 +2,9 @@
 description: See how the tribe ranks. Top scores, one bar chart.
 ---
 
-Read `references/vocabulary.md` and `references/chart-renderer.md` first and follow them for all output in this command.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
+
+Read `references/chart-renderer.md` before rendering any chart and follow it.
 
 ## Step 1: Get the data
 
@@ -28,7 +30,7 @@ Render one fenced code block following the chart-renderer grammar.
 
 4. **Footer**: last line in the block is `→ /luckiest leaderboard` (or the range-qualified form if a range was passed, e.g. `→ /luckiest leaderboard 30d`).
 
-Use only user-facing vocabulary from `references/vocabulary.md`. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
 
 ## Step 3: Recommend next action
 

package/commands/merge.md

@@ -2,7 +2,7 @@
 description: Merge two overlapping skills into one, after you review the diff.
 ---
 
-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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 ## Step 1: Get the two skill ids
 

package/commands/overlaps.md

@@ -2,7 +2,7 @@
 description: Find installed skills that overlap with your own, and resolve them.
 ---
 
-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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 ## Step 1: Pick a skill to check
 

package/commands/plan.md

@@ -2,7 +2,7 @@
 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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 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
@@ -37,7 +37,7 @@ Check whether `.luckiest/BRIEF.md` exists in the current project. If it exists,
 
 ## 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.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. 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.
 
@@ -46,7 +46,9 @@ Call the `status` tool from the luckiest MCP server with that `project` value.
 
 ## Step 3: Run the interview
 
-Open the interview with a short line that says no plan is active and you are starting the interview.
+If the user's invocation already states the outcome they want (they passed arguments describing a goal, a feature, or a problem to solve), skip the interview question entirely. Say in one line that you are planning from what they gave you, use their stated outcome directly, and jump ahead to drafting the task list below. The approval question in Step 4 still runs; it is the only question they get.
+
+Otherwise, 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:
 
@@ -60,7 +62,7 @@ Use the answer (plus the brief, if present) to shape a draft task list of 3 to 7
 
 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.
+Route all draft tasks in ONE `skill_router` call from the luckiest MCP server: pass `prompts` as an array of every task title. It returns `results`, one entry per task with `skills` (matching owned skills) and `who` (up to 3 tribe members who finished a similar task before). Attach the suggested skill(s) to each task, and attach `who` so the plan can carry who has done this kind of work. If the server rejects `prompts` (older server), fall back to one `skill_router` call per task, issued in parallel in a single message, never one at a time.
 
 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**."
 

package/commands/skills.md

@@ -2,7 +2,7 @@
 description: Your skills, list what's installed, pull new purchases.
 ---
 
-Read `references/vocabulary.md` first and follow it for all output in this command. Never delete skills.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 ## Step 1: List installed luckiest skills
 

package/commands/start.md

@@ -2,7 +2,7 @@
 description: Tell me about your project, a short interview that writes your Brand Brief.
 ---
 
-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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 ## Step 1: Check for an existing brief
 

package/commands/status.md

@@ -2,11 +2,13 @@
 description: Where you are. Progress, tasks, and your one next step.
 ---
 
-Read `references/vocabulary.md` and `references/chart-renderer.md` first and follow them for all output in this command.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
+
+Read `references/chart-renderer.md` before rendering any chart and follow it.
 
 ## Step 1: Check for a plan
 
-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.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. 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:
 
@@ -35,7 +37,7 @@ If a plan exists, render one fenced code block following the chart-renderer gram
 5. **Bookmark line (if paused)**: If the state includes a bookmark (pause), add a line showing the bookmark message.
 6. **Footer**: Last line in the block ends with the command to check status again (e.g. `→ /luckiest status`).
 
-Use only the user-facing vocabulary from `references/vocabulary.md`. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
 
 Map each task's status to a glyph (these are the task status values, not the plan position):
 - "done" -> `✓`

package/commands/updates.md

@@ -2,7 +2,7 @@
 description: Check for updates to your installed luckiest skills and plugin.
 ---
 
-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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 ## Step 1: Check for updates
 

package/commands/vouch.md

@@ -2,7 +2,7 @@
 description: Request or approve a warm intro to someone outside your tribe.
 ---
 
-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.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 ## Step 1: Figure out the intent
 

package/commands/wishes.md

@@ -2,7 +2,9 @@
 description: Your wishes balance and recent related activity.
 ---
 
-Read `references/vocabulary.md` and `references/chart-renderer.md` first and follow them for all output in this command.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
+
+Read `references/chart-renderer.md` before rendering any chart and follow it.
 
 ## Step 1: Get the data
 
@@ -27,7 +29,7 @@ Example:
  → /luckiest wishes
 ```
 
-Use only user-facing vocabulary from `references/vocabulary.md`. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
 
 ## Step 3: Recommend next action
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "luckiest-co",
-  "version": "1.0.11",
+  "version": "1.0.13",
   "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-charms/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: luckiest-charms
+description: "Your Luckiest charms balance and recent related activity. Use when the user says /luckiest charms, luckiest charms, or asks about their charms."
+---
+
+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, DONE 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>`.
+
+Chart grammar for any dashboard output in this skill:
+
+
+All dashboard commands use this grammar for rendering data visualizations.
+
+## Grammar Rules
+
+Render dashboards as fenced code blocks using this grammar:
+- Section box: title line, then content, no borders needed beyond blank lines.
+- Horizontal bar: `█` for filled, `░` for empty, width 20 chars, value right-aligned.
+- Numbers: aligned columns, thousands separators.
+- Range header when applicable: `[ 7 Days ]  30 Days  All` with the active range bracketed.
+- Footer line naming the drill-down command, e.g. `→ /luckiest wishes 30d`.
+
+## Example
+
+```
+ Wishes                                [ 7 Days ]
+ balance 42        earned 12       spent 5
+ 06-28 ████████░░░░░░░░░░░░  4
+ 06-29 ██████████████░░░░░░  7
+ 07-01 ██░░░░░░░░░░░░░░░░░░  1
+ → /luckiest wishes 30d
+```
+
+## Implementation Notes
+
+- Each bar is exactly 20 filled/empty blocks.
+- Values are right-aligned after the bar.
+- Column headers are spaced evenly with at least 2 spaces between.
+- The footer command should match the context (e.g., `/luckiest wishes 30d` for a wishes dashboard).
+- Use single-space line breaks between sections for clarity.
+
+## Step 1: Get the data
+
+Call the `overview` tool from the luckiest MCP server. Use the `charms` balance and scan `tribePulse` for any entries whose `event` text relates to charms (earning or spending).
+
+## Step 2: Render the dashboard
+
+Render one fenced code block following the chart-renderer grammar:
+
+1. Title line: `Charms`
+2. Balance line: `balance X` where X is the `charms` value from `overview`, right-aligned if paired with other numbers.
+3. If any charm-related entries exist in `tribePulse`, list them plainly, one per line, using the raw `event` text exactly as returned. Do not invent a friendlier phrasing.
+4. If there is no daily earn/spend history available (there is no history endpoint in this version), add this exact line: `History view coming soon.` Do not invent daily numbers, trends, or a chart of activity over time. Only render a bar chart of actual daily values if such data is actually returned by a tool; since none is available here, skip the bar chart and show the line above instead.
+5. Footer: `→ /luckiest charms`
+
+Example:
+
+```
+ Charms
+ balance 130
+ History view coming soon.
+ → /luckiest charms
+```
+
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+
+## Step 3: Recommend next action
+
+End your response with exactly one line, nothing after it:
+
+Next: /luckiest home

package/skills/luckiest-finish/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+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>`.

package/skills/luckiest-go/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+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>`.
@@ -63,7 +63,7 @@ Research subagents (looking something up, exploring the codebase) are always all
 
 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.
+1. If the task is being handed to a subagent (fast mode), first turn it into a tight working prompt with the `luckiest-prompt-rewrite` skill, targeting that subagent and its model from Step 2; if the skill is not installed, write a clear prompt yourself. When you are doing the task yourself, skip the rewrite and start working; the task title and its "done means..." line are the prompt.
 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.
@@ -74,6 +74,9 @@ Only move to the next ready task once the current one is applied and verified (o
 
 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.
 
+
+Shell note: always quote file paths in shell commands. Paths with parentheses or brackets (for example `app/(public)/orders`) break zsh globbing when unquoted and waste turns on retries. Prefer the dedicated file tools (Read, Glob, Grep) over shell listing commands when either works.
+
 ## Step 4: Stop conditions
 
 Pause and ask the user before doing any of the following, even if it seems like the obvious next step:

package/skills/luckiest-helpers/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: luckiest-helpers
+description: "See who in your Luckiest tribe needs a hand right now, and claim a request to help. Use when the user says /luckiest helpers, luckiest helpers, or asks who needs help."
+---
+
+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, DONE 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>`.
+
+Chart grammar for any dashboard output in this skill:
+
+
+All dashboard commands use this grammar for rendering data visualizations.
+
+## Grammar Rules
+
+Render dashboards as fenced code blocks using this grammar:
+- Section box: title line, then content, no borders needed beyond blank lines.
+- Horizontal bar: `█` for filled, `░` for empty, width 20 chars, value right-aligned.
+- Numbers: aligned columns, thousands separators.
+- Range header when applicable: `[ 7 Days ]  30 Days  All` with the active range bracketed.
+- Footer line naming the drill-down command, e.g. `→ /luckiest wishes 30d`.
+
+## Example
+
+```
+ Wishes                                [ 7 Days ]
+ balance 42        earned 12       spent 5
+ 06-28 ████████░░░░░░░░░░░░  4
+ 06-29 ██████████████░░░░░░  7
+ 07-01 ██░░░░░░░░░░░░░░░░░░  1
+ → /luckiest wishes 30d
+```
+
+## Implementation Notes
+
+- Each bar is exactly 20 filled/empty blocks.
+- Values are right-aligned after the bar.
+- Column headers are spaced evenly with at least 2 spaces between.
+- The footer command should match the context (e.g., `/luckiest wishes 30d` for a wishes dashboard).
+- Use single-space line breaks between sections for clarity.
+
+## Step 1: Get the data
+
+Call the `overview` tool from the luckiest MCP server to get the `openAssists` count. If an assist listing tool is available that returns the actual open requests (title, poster, wish reward, and id for each), use it and prefer that list over the raw count. In v1 a per-request listing may not be available through the MCP server: in that case, do not invent requests. Show the count and point the user to the full board, as described in Step 2.
+
+## Step 2: Render the open requests
+
+If the count is zero and no requests come back, output nothing except:
+
+```
+No open requests right now.
+```
+
+Then end with:
+
+```
+Next: /luckiest home
+```
+
+Do not proceed further.
+
+If you have the count but no per-request details (no listing tool available), render one fenced block with the count and an honest pointer, then stop:
+
+```
+ Needs Help
+ open requests 3
+ Full board and claiming at luckiest.co/dashboard
+ → /luckiest home
+```
+
+and end with `Next: open luckiest.co to claim a request`.
+
+If there are open requests with details, render one fenced code block following the chart-renderer grammar:
+
+1. Title line: `Needs Help (X open)` where X is the number of requests actually listed.
+2. One entry per request, each showing:
+   - Title of the request
+   - Poster name
+   - Wish reward, right-aligned, e.g. `reward 8 wishes`
+   - A claim line directly under it: `→ tell me "claim <id>" and I'll pick it up with respond_to_assist`
+
+Example:
+
+```
+ Needs Help (2 open)
+ Fix the onboarding copy         posted by Priya      reward 8 wishes
+ → tell me "claim a12" and I'll pick it up with respond_to_assist
+
+ Review the pricing page         posted by Marcus     reward 5 wishes
+ → tell me "claim a13" and I'll pick it up with respond_to_assist
+```
+
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term. Do not fabricate requests, posters, or rewards beyond what the tools return.
+
+## Step 3: Recommend next action
+
+End your response with exactly one line, nothing after it:
+
+Next: tell me "claim <id>" for the request you want to help with

package/skills/luckiest-home/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: luckiest-home
+description: "The Luckiest community dashboard: wishes and charms, plan progress, tribe pulse, and who needs help. Use when the user says /luckiest home, luckiest home, or asks for their Luckiest dashboard."
+---
+
+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, DONE 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>`.
+
+Chart grammar for any dashboard output in this skill:
+
+
+All dashboard commands use this grammar for rendering data visualizations.
+
+## Grammar Rules
+
+Render dashboards as fenced code blocks using this grammar:
+- Section box: title line, then content, no borders needed beyond blank lines.
+- Horizontal bar: `█` for filled, `░` for empty, width 20 chars, value right-aligned.
+- Numbers: aligned columns, thousands separators.
+- Range header when applicable: `[ 7 Days ]  30 Days  All` with the active range bracketed.
+- Footer line naming the drill-down command, e.g. `→ /luckiest wishes 30d`.
+
+## Example
+
+```
+ Wishes                                [ 7 Days ]
+ balance 42        earned 12       spent 5
+ 06-28 ████████░░░░░░░░░░░░  4
+ 06-29 ██████████████░░░░░░  7
+ 07-01 ██░░░░░░░░░░░░░░░░░░  1
+ → /luckiest wishes 30d
+```
+
+## Implementation Notes
+
+- Each bar is exactly 20 filled/empty blocks.
+- Values are right-aligned after the bar.
+- Column headers are spaced evenly with at least 2 spaces between.
+- The footer command should match the context (e.g., `/luckiest wishes 30d` for a wishes dashboard).
+- Use single-space line breaks between sections for clarity.
+
+## Step 1: Get the data
+
+Call the `overview` tool from the luckiest MCP server. It returns `{ wishes, charms, loop, openAssists, tribePulse }`.
+
+## Step 2: Render the dashboard
+
+Render one fenced code block following the chart-renderer grammar, with four boxes in this order. Separate boxes with a blank line.
+
+1. **Wishes + Charms box**
+   - Title line: `Wishes & Charms`
+   - One line showing the two balances, aligned columns, thousands separators, for example `wishes 42        charms 130`
+   - Footer: `→ /luckiest wishes`
+
+2. **Active plan progress box**
+   - Title line: `Plan Progress`
+   - If `loop` is null, one line: `No plan yet.`
+   - If `loop` is present, one progress bar line using `█` (filled) and `░` (empty), exactly 20 chars total, with `done/total` right-aligned, for example `██████░░░░░░░░░░░░  3/5`, plus the phase name if present.
+   - Footer: if `loop` is present, `→ /luckiest go`; if `loop` is null, `→ /luckiest status`
+
+3. **Tribe pulse box**
+   - Title line: `Tribe Pulse`
+   - One line per entry in `tribePulse`, showing the member name and the raw `event` string exactly as returned. Do not rewrite, embellish, or invent a friendlier phrasing for the event text. If `tribePulse` is empty, one line: `No recent activity.`
+   - Footer: `→ /luckiest leaderboard`
+
+4. **Needs help box**
+   - Title line: `Needs Help`
+   - One line: `open requests X` where X is `openAssists`.
+   - Footer: `→ /luckiest helpers`
+
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+
+## Step 3: Recommend next action
+
+End your response with exactly one line, nothing after it, based on whether a plan is active:
+
+- If `loop` is present (active plan): `Next: /luckiest go`
+- If `loop` is null (no active plan): `Next: /luckiest plan`

package/skills/luckiest-leaderboard/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: luckiest-leaderboard
+description: "See how the Luckiest tribe ranks: top scores, one bar chart. Use when the user says /luckiest leaderboard, luckiest leaderboard, or asks for tribe rankings."
+---
+
+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, DONE 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>`.
+
+Chart grammar for any dashboard output in this skill:
+
+
+All dashboard commands use this grammar for rendering data visualizations.
+
+## Grammar Rules
+
+Render dashboards as fenced code blocks using this grammar:
+- Section box: title line, then content, no borders needed beyond blank lines.
+- Horizontal bar: `█` for filled, `░` for empty, width 20 chars, value right-aligned.
+- Numbers: aligned columns, thousands separators.
+- Range header when applicable: `[ 7 Days ]  30 Days  All` with the active range bracketed.
+- Footer line naming the drill-down command, e.g. `→ /luckiest wishes 30d`.
+
+## Example
+
+```
+ Wishes                                [ 7 Days ]
+ balance 42        earned 12       spent 5
+ 06-28 ████████░░░░░░░░░░░░  4
+ 06-29 ██████████████░░░░░░  7
+ 07-01 ██░░░░░░░░░░░░░░░░░░  1
+ → /luckiest wishes 30d
+```
+
+## Implementation Notes
+
+- Each bar is exactly 20 filled/empty blocks.
+- Values are right-aligned after the bar.
+- Column headers are spaced evenly with at least 2 spaces between.
+- The footer command should match the context (e.g., `/luckiest wishes 30d` for a wishes dashboard).
+- Use single-space line breaks between sections for clarity.
+
+## Step 1: Get the data
+
+Call the `tribe_leaderboard` tool from the luckiest MCP server. If the tool accepts a range argument and the user specified one (e.g. `/luckiest leaderboard 30d`), pass it through. Otherwise call it with no range argument.
+
+## Step 2: Render the leaderboard
+
+Render one fenced code block following the chart-renderer grammar.
+
+1. **Range header**: only include a `[ 7 Days ]  30 Days  All`-style range header if the tool's response indicates it supports ranges (e.g. it echoes back a range or accepts one). If there is no evidence the tool supports ranges, omit the header entirely. Do not invent range options.
+
+2. **Ranked bar chart**: one line per member, in rank order, with columns for rank, name, and a horizontal bar representing score. Use `█` for filled, `░` for empty, width 20 chars, value right-aligned. For example:
+
+```
+ Tribe Leaderboard
+ 1  Priya   ████████████████░░░░  820
+ 2  Sam     ██████████████░░░░░░  710
+ 3  Marcus  ████████░░░░░░░░░░░░  405
+ → /luckiest leaderboard
+```
+
+3. **Movement arrows**: only add a movement indicator (e.g. `▲2`, `▼1`, `=`) next to a member's name if the tool response includes prior-rank data for that member. If no prior-rank data is present anywhere in the response, omit movement indicators entirely for all members. Do not fabricate or estimate movement.
+
+4. **Footer**: last line in the block is `→ /luckiest leaderboard` (or the range-qualified form if a range was passed, e.g. `→ /luckiest leaderboard 30d`).
+
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+
+## Step 3: Recommend next action
+
+End your response with exactly one line, nothing after it:
+
+Next: /luckiest helpers

package/skills/luckiest-merge/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: luckiest-merge
+description: "Merge two overlapping Luckiest skills into one, after the user reviews the diff. Use when the user says /luckiest merge, luckiest merge, or wants to combine overlapping skills."
+---
+
+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, DONE 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>`.
+
+## Step 1: Get the two skill ids
+
+If the user named both skills (e.g. `/luckiest merge luckiest-copywriting their-copy-skill`), use those as `ourSkillId` and `theirSkillId`. Otherwise ask which two skills to merge, or point them to `/luckiest overlaps` to find a pair first.
+
+## Step 2: Draft the merge
+
+Call the `draft_merge` tool from the luckiest MCP server with `{ ourSkillId, theirSkillId }`.
+
+This does not install or archive anything yet. Show the user the returned diff plainly, as a fenced code block. Do not summarize it away, they need to see exactly what changes.
+
+Ask exactly one approval question:
+
+"Use this merged version? yes / no"
+
+Wait for the answer.
+
+- If no, stop here. End with the wrap-up line in Step 4.
+- If yes, continue to Step 3.
+
+## Step 3: Apply the merge
+
+Call the `apply_merge` tool from the luckiest MCP server with `{ ourSkillId, theirSkillId, mergedName, mergedContent }`, using the merged name and content from the draft in Step 2.
+
+Tell the user plainly what happened: the two original skill directories were archived (moved to `~/.claude/luckiest-archive/`, never deleted) and the merged skill was installed under `mergedName`.
+
+## Step 4: Wrap up
+
+End your response with exactly one line, nothing after it:
+
+```
+Next: /luckiest skills
+```

package/skills/luckiest-overlaps/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: luckiest-overlaps
+description: "Find installed Luckiest skills that overlap with your own, and resolve them. Use when the user says /luckiest overlaps, luckiest overlaps, or asks about duplicate skills."
+---
+
+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, DONE 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>`.
+
+## Step 1: Pick a skill to check
+
+If the user named a skill (e.g. `/luckiest overlaps luckiest-copywriting`), use that as `skillId`. Otherwise, list the installed `luckiest-*` skills (same discovery as `/luckiest skills`, directories under `~/.claude/skills/`) and ask which one to check.
+
+## Step 2: Scan
+
+Call the `scan_overlaps` tool from the luckiest MCP server with `{ skillId }`.
+
+If it returns no overlapping pairs, output exactly:
+
+```
+No overlaps found for <skillId>.
+```
+
+Then skip to Step 4.
+
+## Step 3: Show what overlaps and offer a resolution
+
+List each overlapping pair plainly, one per entry, showing the other skill's id and its tag-overlap score (and description-similarity score if the tool returned one). Do not invent a score if none was returned.
+
+```
+Overlaps with <skillId>:
+• <theirSkillId>  tag overlap 0.82
+```
+
+For each pair, tell the user their three options in plain terms and how to pick one:
+
+- "keep both" — leave both installed, the router picks the best fit per task.
+- "shadow" — yours stays authoritative, theirs becomes a fallback.
+- "merge" — draft a combined skill for review (nothing installs yet).
+
+Tell them to reply with one of those words plus which pair, e.g. `"merge with <theirSkillId>"`.
+
+If the user picks "keep both" or "shadow", call `resolve_overlap` with `{ ourSkillId, theirSkillId, resolution }` using their choice, then confirm what happened in one line.
+
+If the user picks "merge", do not call `resolve_overlap` here. Instead tell them to run `/luckiest merge <skillId> <theirSkillId>` to draft and review it.
+
+## Step 4: Wrap up
+
+End your response with exactly one line, nothing after it:
+
+```
+Next: /luckiest skills
+```

package/skills/luckiest-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+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>`.
@@ -49,7 +49,9 @@ Call the `status` tool from the luckiest MCP server with that `project` value.
 
 ## Step 3: Run the interview
 
-Open the interview with a short line that says no plan is active and you are starting the interview.
+If the user's invocation already states the outcome they want (they passed arguments describing a goal, a feature, or a problem to solve), skip the interview question entirely. Say in one line that you are planning from what they gave you, use their stated outcome directly, and jump ahead to drafting the task list below. The approval question in Step 4 still runs; it is the only question they get.
+
+Otherwise, 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:
 
@@ -63,7 +65,7 @@ Use the answer (plus the brief, if present) to shape a draft task list of 3 to 7
 
 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.
+Route all draft tasks in ONE `skill_router` call from the luckiest MCP server: pass `prompts` as an array of every task title. It returns `results`, one entry per task with `skills` (matching owned skills) and `who` (up to 3 tribe members who finished a similar task before). Attach the suggested skill(s) to each task, and attach `who` so the plan can carry who has done this kind of work. If the server rejects `prompts` (older server), fall back to one `skill_router` call per task, issued in parallel in a single message, never one at a time.
 
 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**."
 

package/skills/luckiest-skills/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: luckiest-skills
+description: "Your Luckiest skills: list what is installed, pull new purchases. Use when the user says /luckiest skills, luckiest skills, or asks what Luckiest skills they have."
+---
+
+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, DONE 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>`.
+
+If there is no shell or filesystem on this surface (web chat), skip any step that runs a command or reads or writes a local file, and tell the user that step needs Claude Code or Cowork.
+
+## Step 1: List installed luckiest skills
+
+First, identify all directories in `~/.claude/skills/` that match the pattern `luckiest-*`. For each one:
+
+1. Read its `SKILL.md` file
+2. Extract the one-line `description:` value from the YAML frontmatter
+3. Display the skill name and description as a clean list
+
+Format each line as:
+```
+• <skill-name>: <one-line description>
+```
+
+If no luckiest skills are installed, output:
+```
+No luckiest skills installed yet. Use /luckiest skills sync to pull your purchases from luckiest.co.
+```
+
+Then jump to Step 3.
+
+## Step 2: Offer sync
+
+After the list, add a blank line, then this prompt:
+
+```
+You can pull newly purchased skills by replying "sync" below.
+```
+
+## Step 3: Handle sync request
+
+If the user replies "sync" or similar intent:
+
+1. Run this command via Bash: `npx luckiest-co --sync-only`
+2. Report what was added (skill names and versions) from the command output
+3. If no new skills were synced, acknowledge that the installation is already up to date
+
+If the user does not request sync, skip this step.
+
+## Step 4: Next line
+
+End your response with exactly one line, nothing after it:
+
+```
+Next: /luckiest plan
+```
+
+Never modify or delete any installed skills. This command is read-only except for the sync operation.

package/skills/luckiest-start/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: luckiest-start
+description: "A short interview about your project that writes your Brand Brief. Use when the user says /luckiest start, luckiest start, or wants to set up Luckiest for a project."
+---
+
+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, DONE 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>`.
+
+If there is no shell or filesystem on this surface (web chat), skip any step that runs a command or reads or writes a local file, and tell the user that step needs Claude Code or Cowork.
+
+## Step 1: Check for an existing brief
+
+Check whether `.luckiest/BRIEF.md` exists in the current project.
+
+- If it exists, read it and show the user a short summary (what they're building, who it's for, what winning looks like). Then ask: "Keep this brief as is, or update it?" Wait for their answer.
+  - If they choose to keep it, skip straight to the sync step below and end the command.
+  - If they choose to update it, continue to the interview below, but only ask about the sections they want to change.
+- If it does not exist, continue to the interview below.
+
+Never overwrite `.luckiest/BRIEF.md` silently. The user always gets to see what's there first and decide.
+
+## Step 2: Run the interview
+
+Ask the following questions ONE at a time, in order, waiting for the answer before asking the next. There are at most 6 questions. Tell the user up front that any question can be skipped by answering "skip."
+
+1. What are you building?
+2. Who is it for?
+3. What does winning look like in 30 days?
+4. What tone or voice should this have?
+5. Is there anything that must not change?
+6. Any links to share (designs, docs, prior work)?
+
+Keep the tone conversational, not a form. Ask one question, read the reply, then move to the next. Don't dump all six at once.
+
+## Step 3: Write the brief
+
+Read `templates/BRIEF.md` (in this plugin) for the section structure. Each section carries an HTML-comment prompt like `<!-- filled from the /luckiest start interview -->`. Fill each section in using the interview answers, in the user's own words where possible. If the user skipped a question, leave that section's `<!-- ... -->` comment in place rather than inventing content.
+
+Write the result to `.luckiest/BRIEF.md` in the current project (create the `.luckiest/` directory if it doesn't exist).
+
+## Step 4: Sync
+
+Call the `pause` tool from the luckiest MCP server with a reason like: `Brief created: <one-line summary of what they're building>`. This notes in the session bookmark that the brief now exists.
+
+## Step 5: Wrap up
+
+End your response with exactly one line, nothing after it:
+
+Next: /luckiest plan to plan your first work.

package/skills/luckiest-status/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: luckiest-status
+description: "Where you are in your Luckiest plan: progress, tasks, and your one next step. Use when the user says /luckiest status, luckiest status, or asks where their plan stands."
+---
+
+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, DONE 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>`.
+
+Chart grammar for any dashboard output in this skill:
+
+
+All dashboard commands use this grammar for rendering data visualizations.
+
+## Grammar Rules
+
+Render dashboards as fenced code blocks using this grammar:
+- Section box: title line, then content, no borders needed beyond blank lines.
+- Horizontal bar: `█` for filled, `░` for empty, width 20 chars, value right-aligned.
+- Numbers: aligned columns, thousands separators.
+- Range header when applicable: `[ 7 Days ]  30 Days  All` with the active range bracketed.
+- Footer line naming the drill-down command, e.g. `→ /luckiest wishes 30d`.
+
+## Example
+
+```
+ Wishes                                [ 7 Days ]
+ balance 42        earned 12       spent 5
+ 06-28 ████████░░░░░░░░░░░░  4
+ 06-29 ██████████████░░░░░░  7
+ 07-01 ██░░░░░░░░░░░░░░░░░░  1
+ → /luckiest wishes 30d
+```
+
+## Implementation Notes
+
+- Each bar is exactly 20 filled/empty blocks.
+- Values are right-aligned after the bar.
+- Column headers are spaced evenly with at least 2 spaces between.
+- The footer command should match the context (e.g., `/luckiest wishes 30d` for a wishes dashboard).
+- Use single-space line breaks between sections for clarity.
+
+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.
+
+## Step 1: Check for a plan
+
+Derive the project key as described in the project key rules above, 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:
+
+```
+No plan yet. Start with /luckiest plan.
+```
+
+Then end with:
+
+```
+Next: /luckiest plan
+```
+
+Do not proceed further.
+
+## Step 2: Render the status dashboard
+
+If a plan exists, render one fenced code block following the chart-renderer grammar. The block MUST include:
+
+1. **Plan phase and header**: First line shows the plan's phase name (if present) or a generic title like "Your Work".
+2. **Progress bar**: One line with format `█` (filled) and `░` (empty) chars, exactly 20 chars total, with the count `done/total` right-aligned. Example: `██████░░░░░░░░░░░░  3/5`
+3. **Task lines**: One line per task in the plan's task list. Each line shows:
+   - Task title (truncate to fit on line)
+   - Status glyph: `✓` for done, `▸` for doing, `·` for ready, `?` for assist
+4. **Pass rate (if any)**: If the state includes any verified task results, add a line showing pass rate in the format `pass rate: X/Y` where X is completed verifications and Y is total tasks.
+5. **Bookmark line (if paused)**: If the state includes a bookmark (pause), add a line showing the bookmark message.
+6. **Footer**: Last line in the block ends with the command to check status again (e.g. `→ /luckiest status`).
+
+Use only the user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+
+Map each task's status to a glyph (these are the task status values, not the plan position):
+- "done" -> `✓`
+- "doing" -> `▸`
+- "ready" -> `·`
+- "assist" -> `?`
+- "blocked" -> `✗`
+
+## Step 3: Recommend next action
+
+End your response with exactly one line, nothing after it, derived from the MCP `nextAction` field:
+
+```
+Next: <nextAction>
+```
+
+If nextAction is null or empty, default to the most logical next step based on the current state (e.g., `Next: /luckiest go` if tasks are ready).

package/skills/luckiest-updates/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: luckiest-updates
+description: "Check for updates to your installed Luckiest skills and plugin. Use when the user says /luckiest updates, luckiest updates, or asks if their Luckiest install is current."
+---
+
+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, DONE 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>`.
+
+If there is no shell or filesystem on this surface (web chat), skip any step that runs a command or reads or writes a local file, and tell the user that step needs Claude Code or Cowork.
+
+## Step 1: Check for updates
+
+Call the `check_updates` tool from the luckiest MCP server.
+
+## Step 2: Report what's available
+
+If no updates are available, output exactly:
+
+```
+Everything is up to date.
+```
+
+Then skip to Step 3.
+
+If updates are available, list each one plainly, one per line, using only what the tool returns (skill or plugin name, current version, available version). Do not invent version numbers or changelog details that weren't returned. For example:
+
+```
+Updates available:
+• luckiest-copywriting  1.2.0 → 1.3.0
+• luckiest-cro          2.0.1 → 2.1.0
+```
+
+If any update includes a changelog or summary field in the tool response, show it as a short indented line under that entry. Do not fabricate one if it's missing.
+
+## Step 3: Offer to sync
+
+If updates were found, add a blank line, then:
+
+```
+You can pull these by replying "sync" below.
+```
+
+If the user replies "sync" or similar intent, run this command via Bash: `npx luckiest-co --sync-only`, then report what was actually updated from the command output.
+
+## Step 4: Wrap up
+
+End your response with exactly one line, nothing after it:
+
+```
+Next: /luckiest skills
+```

package/skills/luckiest-vouch/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: luckiest-vouch
+description: "Request or approve a warm intro to someone outside your Luckiest tribe. Use when the user says /luckiest vouch, luckiest vouch, or asks for an intro."
+---
+
+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, DONE 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>`.
+
+## Step 1: Figure out the intent
+
+- If the user is asking for an intro to someone (e.g. `/luckiest vouch <targetId>`, or "I need a warm intro to X"), go to Step 2.
+- If the user is approving a vouch someone asked them for (e.g. "approve vouch <vouchId>", or they were told about a pending vouch elsewhere), go to Step 3.
+- If neither is clear, ask which one they mean.
+
+## Step 2: Request a warm intro
+
+Call the `request_vouch` tool from the luckiest MCP server with `{ targetId }`. If this request is tied to an open assist request, include `assistRequestId` too.
+
+This asks a shared 1st-degree tribe member (someone in your direct tribe who also knows the target) to vouch for you before you can reach a 3rd-degree person directly.
+
+Report plainly that the request was sent and who needs to approve it, if the tool response says.
+
+## Step 3: Approve a vouch
+
+Call the `approve_vouch` tool from the luckiest MCP server with `{ vouchId }`.
+
+Confirm plainly that the vouch was approved and the intro can proceed.
+
+## Step 4: Wrap up
+
+End your response with exactly one line, nothing after it:
+
+```
+Next: /luckiest helpers
+```

package/skills/luckiest-wishes/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: luckiest-wishes
+description: "Your Luckiest wishes balance and recent related activity. Use when the user says /luckiest wishes, luckiest wishes, or asks about their wishes."
+---
+
+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, DONE 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>`.
+
+Chart grammar for any dashboard output in this skill:
+
+
+All dashboard commands use this grammar for rendering data visualizations.
+
+## Grammar Rules
+
+Render dashboards as fenced code blocks using this grammar:
+- Section box: title line, then content, no borders needed beyond blank lines.
+- Horizontal bar: `█` for filled, `░` for empty, width 20 chars, value right-aligned.
+- Numbers: aligned columns, thousands separators.
+- Range header when applicable: `[ 7 Days ]  30 Days  All` with the active range bracketed.
+- Footer line naming the drill-down command, e.g. `→ /luckiest wishes 30d`.
+
+## Example
+
+```
+ Wishes                                [ 7 Days ]
+ balance 42        earned 12       spent 5
+ 06-28 ████████░░░░░░░░░░░░  4
+ 06-29 ██████████████░░░░░░  7
+ 07-01 ██░░░░░░░░░░░░░░░░░░  1
+ → /luckiest wishes 30d
+```
+
+## Implementation Notes
+
+- Each bar is exactly 20 filled/empty blocks.
+- Values are right-aligned after the bar.
+- Column headers are spaced evenly with at least 2 spaces between.
+- The footer command should match the context (e.g., `/luckiest wishes 30d` for a wishes dashboard).
+- Use single-space line breaks between sections for clarity.
+
+## Step 1: Get the data
+
+Call the `overview` tool from the luckiest MCP server. Use the `wishes` balance and scan `tribePulse` for any entries whose `event` text relates to wishes (earning or spending).
+
+## Step 2: Render the dashboard
+
+Render one fenced code block following the chart-renderer grammar:
+
+1. Title line: `Wishes`
+2. Balance line: `balance X` where X is the `wishes` value from `overview`, right-aligned if paired with other numbers.
+3. If any wish-related entries exist in `tribePulse`, list them plainly, one per line, using the raw `event` text exactly as returned. Do not invent a friendlier phrasing.
+4. If there is no daily earn/spend history available (there is no history endpoint in this version), add this exact line: `History view coming soon.` Do not invent daily numbers, trends, or a chart of activity over time. Only render a bar chart of actual daily values if such data is actually returned by a tool; since none is available here, skip the bar chart and show the line above instead.
+5. Footer: `→ /luckiest wishes`
+
+Example:
+
+```
+ Wishes
+ balance 42
+ History view coming soon.
+ → /luckiest wishes
+```
+
+Use only user-facing vocabulary. Never surface PLAN, APPLY, UNIFY, DRAFT, DOING, DONE, HANDOFF, or any internal term.
+
+## Step 3: Recommend next action
+
+End your response with exactly one line, nothing after it:
+
+Next: /luckiest charms