luckiest-co 1.0.11 → 1.0.12

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.13",
       "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.13",
   "author": { "name": "Luckiest" }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "luckiest-co",
-  "version": "1.0.11",
+  "version": "1.0.12",
   "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>`.

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>`.

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