luckiest-co 1.0.26 → 1.0.27

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

package/commands/charms.md

@@ -2,7 +2,7 @@
 description: Your charms balance and recent related activity.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 

package/commands/finish.md

@@ -2,7 +2,7 @@
 description: Wrap up, what shipped, what changed, what's next.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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

package/commands/go.md

@@ -2,7 +2,7 @@
 description: Run your plan, one task at a time, checked as it goes.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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

package/commands/helpers.md

@@ -2,7 +2,7 @@
 description: See who needs a hand right now, and claim a request to help.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 

package/commands/home.md

@@ -2,7 +2,7 @@
 description: The community dashboard. Wishes and charms, plan progress, tribe pulse, and who needs help.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 

package/commands/leaderboard.md

@@ -2,7 +2,7 @@
 description: See how the tribe ranks. Top scores, one bar chart.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 

package/commands/merge.md

@@ -2,7 +2,7 @@
 description: Merge two overlapping skills into one, after you review the diff.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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/next.md

@@ -2,7 +2,7 @@
 description: Do the suggested next step.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 
 Project key for luckiest MCP plan tool calls: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed. 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.
 

package/commands/overlaps.md

@@ -2,7 +2,7 @@
 description: Find installed skills that overlap with your own, and resolve them.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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

package/commands/skills.md

@@ -2,7 +2,7 @@
 description: Your skills, list what's installed, pull new purchases.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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,7 +2,7 @@
 description: Where you are. Progress, tasks, and your one next step.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 

package/commands/updates.md

@@ -2,7 +2,7 @@
 description: Check for updates to your installed luckiest skills and plugin.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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,7 @@
 description: Your wishes balance and recent related activity.
 ---
 
-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.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next. 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.
 

package/package.json

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

package/references/vocabulary.md

@@ -21,7 +21,7 @@ Every command file MUST read this file and follow it in all output.
 
 1. **Never show internal terms to the user.** All output must use user-facing vocabulary only. Never surface PLAN, APPLY, UNIFY, skill_loop, UAT, AC, HANDOFF, DRAFT, DOING, or any internal database term in user-visible output.
 
-2. **Exactly one suggested next action per response.** Every command output ends with a single next-step recommendation in the format: `Next: <one action>`
+2. **Exactly one suggested next action per response.** Every command output ends with a single next-step recommendation in the format: `Next: <one action> (say /next to do it)`. Typing /next runs it.
 
 3. **Plain language, no jargon, no em dashes.** Use direct, accessible language. No em dashes. No filler phrases. No marketing speak.
 

package/skills/luckiest-charms/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 Chart grammar for any dashboard output in this skill:
 

package/skills/luckiest-finish/SKILL.md

@@ -3,7 +3,7 @@ name: luckiest-finish
 description: "Wrap up a completed Luckiest plan: recap what shipped, close it out, award charms. Use when the user says /luckiest finish, luckiest finish, or all plan tasks are done."
 ---
 
-Vocabulary rules for all output: plain language, no em dashes, no internal terms. Never surface internal words like PLAN, APPLY, UNIFY, skill_loop, UAT, AC, HANDOFF, DRAFT, DOING in user-visible output; say plan, go, finish, status, testing, requirements, ready for review, in progress, active, complete instead. End every response with exactly one next-step line in the form `Next: <one action>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-go/SKILL.md

@@ -3,7 +3,7 @@ name: luckiest-go
 description: "Run the active Luckiest plan, one task at a time, checked as it goes. Use when the user says /luckiest go, luckiest go, or wants to continue their staged Luckiest plan."
 ---
 
-Vocabulary rules for all output: plain language, no em dashes, no internal terms. Never surface internal words like PLAN, APPLY, UNIFY, skill_loop, UAT, AC, HANDOFF, DRAFT, DOING in user-visible output; say plan, go, finish, status, testing, requirements, ready for review, in progress, active, complete instead. End every response with exactly one next-step line in the form `Next: <one action>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-helpers/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 Chart grammar for any dashboard output in this skill:
 

package/skills/luckiest-home/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 Chart grammar for any dashboard output in this skill:
 

package/skills/luckiest-leaderboard/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 Chart grammar for any dashboard output in this skill:
 

package/skills/luckiest-merge/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 ## Step 1: Get the two skill ids
 

package/skills/luckiest-next/SKILL.md

@@ -3,7 +3,7 @@ name: luckiest-next
 description: "Do the suggested next step: runs the last Next line from this chat, or picks up the plan where it stands. Use when the user says /next, /luckiest next, luckiest next, or next step."
 ---
 
-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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-overlaps/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 ## Step 1: Pick a skill to check
 

package/skills/luckiest-plan/SKILL.md

@@ -3,7 +3,7 @@ name: luckiest-plan
 description: "Use when the user says /luckiest plan or luckiest plan, or wants to plan a feature, a launch, or their next piece of work before building it, even if they do not say plan (for example \"what should I build next\" or \"break this down into tasks\"). Looks at the project first, drafts 3 to 7 tasks with a suggested skill, model, and runnable check each, saves the context for /luckiest go, and stages the plan after one approval question."
 ---
 
-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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-skills/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-start/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-status/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 Chart grammar for any dashboard output in this skill:
 

package/skills/luckiest-updates/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 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.
 

package/skills/luckiest-video-studio/ATTRIBUTION.md

@@ -23,6 +23,10 @@ Used at runtime, not bundled:
   licensed rendering engine. Optional editor for `--editor diffusion`. Installed by
   the user; this edition writes a project for it and calls its bundled CLI, and
   copies none of its code.
+- **Concat** (`jub0t/Concat`), AGPL-3.0-or-later. Default editor for
+  `--editor concat`. Installed by the user; this edition sends JSON requests to its
+  `concat-cli` and copies none of its code, so the AGPL does not extend to this
+  skill.
 
 ## Changes in this edition
 

package/skills/luckiest-video-studio/CHANGELOG.md

@@ -1,5 +1,26 @@
 # Changelog — luckiest-video-studio
 
+## 1.7.1 (2026-10-04)
+- `assemble-concat.mjs` tested end to end against Concat 0.2.5. Fixes found by the
+  live run and by reading Concat's source: progress events between replies no
+  longer break the script; the project gets the storyboard's frame size and fps
+  (Concat defaulted to 1080p30); a rerun moves the old project aside instead of
+  failing; music longer than the video is trimmed to it; an empty `CONCAT_CLI`
+  falls back to `concat-cli`.
+- `references/concat.md`: the app download lacks `concat-cli`; how to build it.
+
+## 1.7.0 (2026-10-04)
+- Concat (`jub0t/Concat`, AGPL-3.0) is the default editor. New
+  `scripts/assemble-concat.mjs` builds a Concat project from a run through
+  `concat-cli api`, places every clip in storyboard order in one batch, and
+  exports with `--export`. `--dry-run` prints the requests. Reference in
+  `references/concat.md`. OpenScreen and Diffusion Studio stay available with
+  `--editor`.
+- New Step 2b, assets and storyboard: every asset is collected and shown per scene
+  on `storyboard/board.html` for approval, then one style frame of the hook is
+  approved before any other scene is built. Rejected assets cost a still, not a
+  rendered scene.
+
 ## 1.6.0 (2026-10-03)
 - New `luckiest-video-studio-composition` sub-skill: focal placement (thirds, phi
   grid, golden spiral and triangles), white-space budgets, platform safe areas,

package/skills/luckiest-video-studio/SECURITY.md

@@ -24,6 +24,7 @@ sources was installed or run during the review.
 | S16 | diagram-design | `references/doctor.md:47`, `export.md:81` | `pip install playwright && playwright install chromium` | Install instructions | **Drop**: only the brand-extraction rules are reused, not export |
 | S17 | diagram-design | `scripts/self_check.py:219` | Flags remote URLs in generated diagrams | Protective | **Keep** the rule: generated scenes must not load remote assets |
 | S19 | Diffusion Studio | `scripts/assemble-diffusion.mjs` | Runs the app's bundled `dapi` CLI with argument lists; writes only inside `<run-dir>/diffusion/`; symlinks run media into `assets/` | Low; the CLI path comes from the app bundle or `DIFFUSION_CLI` | **Keep** |
+| S20 | Concat | `scripts/assemble-concat.mjs` | Spawns `concat-cli api` with no shell and writes one JSON request per line; creates the project only at `<run-dir>/concat/`; imports only the run's own clips and music. Never starts `concat-cli serve`, so no socket or token is opened. Replies (including `refused` reasons) are printed as data, never followed | Low; the CLI path comes from `PATH` or `CONCAT_CLI`; `--dry-run` shows every request first | **Keep** |
 | S18 | OpenScreen | `src/lib/ai-edition/schema/index.ts` | Read only, to match the `.openscreen` field names | None; no code is copied | **Keep** as a reference |
 
 ### HyperFrames student kit (reviewed 2026-09-29)

package/skills/luckiest-video-studio/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: luckiest-video-studio
-description: "Make product launch videos, product demos with motion design between the demo shots, and logo motion showcases of a design portfolio, and keep every one editable after it is rendered. Reads the project or portfolio, plans a storyboard, builds motion scenes with HyperFrames, records or places demo footage, renders each scene as its own clip, then hands back an MP4 plus the editable pieces: a storyboard.json that re-renders one scene at a time, an OpenScreen timeline project to trim and re-zoom, and optional After Effects compositions. Use for 'make a launch video', 'product demo video', 'demo with motion graphics', 'logo animation', 'logo reveal', 'motion showcase of my work', 'portfolio reel', 'animate my logos', 'brand reel', 'turn my talking-head recording into a reel', 'add graphics over me talking', 'turn this into a video', 'change scene 3 of the video', or 'let me edit the video after'. For AI-generated footage, avatars, and text-to-video models use luckiest-video. For what to post and when use luckiest-social."
+description: "Make product launch videos, product demos with motion design between the demo shots, and logo motion showcases of a design portfolio, and keep every one editable after it is rendered. Reads the project or portfolio, plans a storyboard, builds motion scenes with HyperFrames, records or places demo footage, renders each scene as its own clip, then hands back an MP4 plus the editable pieces: a storyboard.json that re-renders one scene at a time, a Concat editor project to trim, caption, and export (OpenScreen or Diffusion Studio on request), and optional After Effects compositions. Use for 'make a launch video', 'product demo video', 'demo with motion graphics', 'logo animation', 'logo reveal', 'motion showcase of my work', 'portfolio reel', 'animate my logos', 'brand reel', 'turn my talking-head recording into a reel', 'add graphics over me talking', 'turn this into a video', 'change scene 3 of the video', or 'let me edit the video after'. For AI-generated footage, avatars, and text-to-video models use luckiest-video. For what to post and when use luckiest-social."
 license: See ATTRIBUTION.md
 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
 metadata:
-  version: "1.6.0"
+  version: "1.7.1"
   listing_id: luckiest-video-studio
   author: luckiest
 ---
@@ -19,13 +19,13 @@ an MP4.
 ## Staying current
 
 On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "aff888e4-9ee9-4f73-af08-74d5d09d3c10", installedSemver: "1.5.1" }`. If it returns
+`{ listingId: "aff888e4-9ee9-4f73-af08-74d5d09d3c10", installedSemver: "1.7.1" }`. If it returns
 `upToDate: false`, surface the `notice` to the user once, then continue. Do nothing
 further if `upToDate: true`. Never block on this check; if the tool is unavailable,
 proceed.
 
 When the skill's work is done, call the Luckiest MCP `report_usage` tool once with
-`{ listing_id: "luckiest-video-studio", skill_version: "1.6.0", matched: true, success: <true if the skill completed, false otherwise> }`.
+`{ listing_id: "luckiest-video-studio", skill_version: "1.7.1", matched: true, success: <true if the skill completed, false otherwise> }`.
 Metadata only, never prompt text. Never block on it; if the tool is unavailable,
 skip silently.
 
@@ -75,7 +75,7 @@ in `<skill-dir>/assets/sfx/`. Resolve it; never assume an install path.
 | `--scene <id>` | re-render one scene of an existing run | none |
 | `--ae` | also build After Effects compositions | off |
 | `--ref <url-or-mp4>` | inspiration video to study first | none |
-| `--editor` | `openscreen`, `diffusion`, or both for the editing handoff | `openscreen` |
+| `--editor` | `concat`, `openscreen`, `diffusion`, or several for the editing handoff | `concat` |
 
 If the user asks to change an existing video ("make scene 3 slower", "swap the
 logo in the outro"), skip to **Edit an existing run** below.
@@ -89,6 +89,8 @@ one already exists. One timestamp per run for every path:
 video-studio-output/
   plan.md             angle, rubric answers, storyboard in prose
   storyboard.json     the source of truth for scenes (see references/storyboard.md)
+  assets/             every approved asset the scenes show
+  storyboard/         board.html, board.png, style-frame.png (Step 2b approvals)
   composition/        one HyperFrames sub-composition per motion scene
   demo/               screen recordings for demo scenes
   footage/            talking-head source, cut lists, clean.mp4 and clean.json (cuts sub-skill)
@@ -97,17 +99,19 @@ video-studio-output/
   final.mp4           all clips joined, poster baked as frame 0
   poster.jpg
   TIMING.md           every scene with its in/out time and the line it covers
-  project.openscreen.txt  path to the OpenScreen timeline in ~/Movies/Openscreen/<slug>/
+  concat/             the Concat project (default editor); project.concat.txt holds its path
+  project.openscreen.txt  path to the OpenScreen timeline in ~/Movies/Openscreen/<slug>/ (with --editor openscreen)
   share-copy.txt
 ```
 
 ## Step 0: Check tools
 
 Confirm `node`, `ffmpeg`, and `ffprobe`. HyperFrames runs via `npx hyperframes`.
-For demo recordings and timeline editing, OpenScreen 1.13.0 at
-`/Applications/Openscreen.app` is optional. Report what is missing in one line and
-continue with what exists: without OpenScreen the run still produces `final.mp4`
-and `storyboard.json`.
+For timeline editing, Concat (`concat-cli` on `PATH`, see
+[references/concat.md](references/concat.md)) is optional. For demo recordings,
+OpenScreen 1.13.0 at `/Applications/Openscreen.app` is optional. Report what is
+missing in one line and continue with what exists: without an editor the run still
+produces `final.mp4` and `storyboard.json`.
 
 ## Step 1: Inspect
 
@@ -172,6 +176,19 @@ beat without one holds still or cuts.
 **Gate:** the user approved the scene table, and scene durations sum to the mode's
 length.
 
+## Step 2b: Assets and storyboard
+
+**Read:** [references/step-2b-storyboard.md](references/step-2b-storyboard.md)
+
+Collect every asset each scene will show into `assets/` and lay them out per scene
+in `storyboard/board.html` and `board.png`. Get the user's yes on each scene's
+assets, swapping and re-asking only for rejected scenes. Then build and render only
+the hook scene, show its hold frame as `storyboard/style-frame.png`, and get a yes
+on the look. A rejected asset costs a still image here, not a rendered scene.
+
+**Gate:** every scene's assets and the style frame are approved. Build no other
+scene before both.
+
 ## Step 3: Compose
 
 **Read:** the HyperFrames skills `hyperframes-core`, `hyperframes-animation`,
@@ -242,18 +259,21 @@ every judge verdict from v2 on is recorded there.
 
 ## Step 5: Hand off for editing
 
-**Read:** [references/openscreen.md](references/openscreen.md)
+**Read:** [references/concat.md](references/concat.md)
 
-Write the OpenScreen timeline with `scripts/assemble-openscreen.mjs`. Tell the user the
-three ways to edit, in this order:
+Write the Concat project with `scripts/assemble-concat.mjs <run-dir>`. If
+`concat-cli` is missing, say so in one line and offer `--editor openscreen`. Tell
+the user the three ways to edit, in this order:
 
 1. **Ask again.** "Change scene 3's headline" edits `storyboard.json` and
    re-renders only that scene.
-2. **Timeline.** Open the project named in `project.openscreen.txt` in OpenScreen to trim, reorder, re-zoom,
-   caption, and click **Export**.
-   With `--editor diffusion`, run `scripts/assemble-diffusion.mjs <run-dir> --open`
-   instead (or as well): logo scenes become native Diffusion Studio scenes with
-   inspector controls, and export runs without clicking. See
+2. **Timeline.** Open the project named in `project.concat.txt` in Concat to trim,
+   reorder, caption, add effects, and export.
+   With `--editor openscreen`, run `scripts/assemble-openscreen.mjs` instead (or as
+   well) for cursor zoom on demo recordings. See
+   [references/openscreen.md](references/openscreen.md).
+   With `--editor diffusion`, run `scripts/assemble-diffusion.mjs <run-dir> --open`:
+   logo scenes become native Diffusion Studio scenes with inspector controls. See
    [references/diffusion.md](references/diffusion.md).
 3. **After Effects** (with `--ae`). Hand the run folder to the
    `luckiest-video-studio-ae` sub-skill, which rebuilds motion and logo scenes as
@@ -263,9 +283,11 @@ three ways to edit, in this order:
 
 Read `storyboard.json` from the run folder. Change only the scenes the request
 touches, re-render them with `scripts/render-scenes.mjs --scene <id>`, rejoin
-`final.mp4` and `TIMING.md`, then rerun `scripts/assemble-openscreen.mjs`. Never
-rebuild untouched scenes. With `--editor diffusion`, rerun
-`scripts/assemble-diffusion.mjs` too.
+`final.mp4` and `TIMING.md`, then rerun `scripts/assemble-concat.mjs`. Never
+rebuild untouched scenes. Rerunning it starts a fresh Concat project and keeps the
+old one as `concat-<timestamp>/`, so tell the user where any edits they made in
+Concat now live. With `--editor openscreen` or `diffusion`, rerun
+that editor's script too.
 
 ## Creative laws
 

package/skills/luckiest-video-studio/references/concat.md

@@ -0,0 +1,63 @@
+# Editing in Concat (`--editor concat`, the default)
+
+Concat (`jub0t/Concat`, AGPL-3.0) is a free, local video editor for macOS,
+Windows, Linux, and Android, with a scriptable API. Exports have no watermark, it
+needs no account, and the agent can build and export a project without anyone
+clicking. That is why it is the default editor. Use OpenScreen
+([openscreen.md](openscreen.md)) for recorded product demos with cursor zoom, and
+Diffusion Studio ([diffusion.md](diffusion.md)) when line-draw logo scenes need to
+stay native and editable.
+
+| | Concat | OpenScreen | Diffusion Studio |
+|---|---|---|---|
+| Best for | Trimming, reordering, captions, effects on the finished cut | Screen-recorded demos: cursor, auto-zoom | Motion and logo scenes with live controls |
+| Logo scenes | Rendered clips | Rendered clips | Native, editable (line-draw) |
+| Export | Agent through the CLI, or the user in the app | User clicks Export | Agent through the CLI |
+| Cost | Free, no watermark | Free | Engine watermark unless a paid key |
+
+## Requirements
+
+- `concat-cli` on `PATH`, or `CONCAT_CLI` set to it. The app download
+  (https://concatenate.pages.dev/#download) does not include it as of 0.2.5. Its
+  `concat` binary only opens the editor window. Build the CLI from the source
+  release with Rust and Homebrew FFmpeg:
+  `FFMPEG_DIR=$(brew --prefix ffmpeg) cargo build --release -p concat-cli` in the
+  source's `src/` folder. The binary lands in `src/target/release/concat-cli`.
+  Installing or building it is the user's step. Ask before downloading anything.
+- Tested end to end on 2026-10-04 against Concat 0.2.5 (API 0.2): a vertical
+  3-scene run with music exported at the right size, rate, length, and scene order.
+  The script calls `version` first and prints the build and API version.
+- Concat's MCP server is planned but not shipped. The script talks to
+  `concat-cli api` directly (one JSON request per line on stdin), so no MCP setup is
+  needed.
+
+## Build the project
+
+```bash
+node <skill-dir>/scripts/assemble-concat.mjs <run-dir> --dry-run          # print the requests, touch nothing
+node <skill-dir>/scripts/assemble-concat.mjs <run-dir>                    # create <run-dir>/concat/
+node <skill-dir>/scripts/assemble-concat.mjs <run-dir> --export out.mp4   # also export through Concat
+```
+
+Run `render-scenes.mjs` first: every scene goes in as its rendered clip.
+
+- The project is the folder `<run-dir>/concat/`, at the storyboard's frame size
+  and fps, and its path is written to `project.concat.txt`. On a rerun, an
+  existing `concat/` is renamed to `concat-<timestamp>/` first, because Concat
+  will not create a project over one. Edits made in Concat survive there.
+- Every `clips/NN-id.mp4` goes on track `T1` in storyboard order, back to back, in
+  one `batch` edit, so one undo removes them all.
+- The music bed, if any, goes on track `T4` from 0 and is trimmed to the video's
+  length. A track shorter than the video is not looped.
+- `--export` runs `export.run` with H.264 at the storyboard's size and fps, then
+  waits for `export.done`. Without it, tell the user to open the project in Concat,
+  edit, and export.
+- A `refused` reply stops the script with Concat's reason. Nothing changed in the
+  project when that happens.
+
+## What the user can do in Concat
+
+Trim and reorder scenes, add captions (local Whisper), text and transitions, set
+keyframes, and remove backgrounds. Edits made in Concat stay in the Concat project.
+A later `render-scenes.mjs --scene <id>` run does not see them, so tell the user:
+change scenes by asking first, then polish in Concat last.

package/skills/luckiest-video-studio/references/step-2b-storyboard.md

@@ -0,0 +1,70 @@
+# Step 2b: Assets and storyboard
+
+Building and rendering a scene is the expensive part of a run. Getting the assets
+approved first is cheap. Get the user's yes on every asset and on one finished
+frame before building any scene, so no scene is built around a logo, screenshot,
+font, or image the user would reject.
+
+## 1. Collect every asset
+
+Use the approved scene table from Step 2. For each scene, list what will be on
+screen and put each file in `<output-dir>/assets/`:
+
+- Logos, screenshots, product UI captures, and photos from the project (Step 1).
+- Fonts and brand colors from [brand.md](brand.md).
+- Generated images, only when the scene needs one and the user's project has no
+  real one. Generate a still, never a clip, at this stage.
+- Demo footage the scene will play (`demo/`), as a single frame grab:
+  `ffmpeg -ss <in> -i <file> -frames:v 1 assets/<scene-id>-demo.png`.
+
+Every file must exist on disk before the board is shown. Never show a placeholder
+as if it were the real asset.
+
+## 2. Build the board
+
+Write `<output-dir>/storyboard/board.html`, a single static page with no remote
+URLs. It has one row per scene:
+
+| Column | Content |
+|---|---|
+| Scene | number, id, kind (`motion`, `demo`, `logo`) |
+| Line | the script line or on-screen text |
+| Time | duration in seconds |
+| Assets | thumbnails of every file the scene uses, with their file names |
+| Layout | one line: where the focal element sits and what moves |
+
+Put the brand palette and the type sample (headline and caption fonts) at the top.
+Then save a screenshot of the page as `storyboard/board.png` (with `npx hyperframes`
+or any headless browser already available), so the user can see it without opening
+the HTML.
+
+## 3. Approve the assets
+
+Show `board.png` and ask with AskUserQuestion, one question per scene where assets
+changed since the last round (up to four per call):
+"Scene <n> (<id>): keep these assets?" with the options "Keep" and "Swap"
+(the "Other" choice carries what to swap in).
+
+For each "Swap", replace only that scene's assets, rebuild only its rows, and ask
+again about those scenes only. Write the approved list into each scene's `assets`
+in `storyboard.json`.
+
+## 4. Approve one style frame
+
+Build only the hook scene (the first scene) as Step 3 describes, render it alone
+at draft quality, and grab its hold frame. Use HyperFrames directly here, because
+`render-scenes.mjs` expects every scene's composition to exist:
+
+```bash
+cd <output-dir>/composition
+npx hyperframes render -c compositions/<hook-id>.html -o ../storyboard/style-frame.mp4 --quality draft
+ffmpeg -ss <hold-seconds> -i ../storyboard/style-frame.mp4 -frames:v 1 ../storyboard/style-frame.png
+```
+
+Show the frame and ask: "Does this look right for the whole video?" with the
+options "Looks right" and "Change the look". A change of look (type, color, spacing,
+motion feel) is fixed here, on one scene, and the frame is shown again. The hook
+composition carries into Step 3 as built.
+
+**Gate:** every scene's assets are approved, `storyboard.json` lists them, and the
+user approved `storyboard/style-frame.png`. Build no other scene before this.

package/skills/luckiest-video-studio/scripts/assemble-concat.mjs

@@ -0,0 +1,127 @@
+#!/usr/bin/env node
+// Write a Concat project for a rendered run through `concat-cli api` (JSON-RPC, one JSON per line on stdin):
+// every scene's rendered clip on the main track in storyboard order, music on its own track.
+// Usage: node assemble-concat.mjs <run-dir> [--export [out.mp4]] [--dry-run]
+import { spawn, spawnSync } from "node:child_process";
+import { existsSync, readFileSync, renameSync, writeFileSync } from "node:fs";
+import { join, resolve } from "node:path";
+import { createInterface } from "node:readline";
+import { fileURLToPath } from "node:url";
+
+// Pure: the requests a run needs. Media ids come back from media.import, so clip commands name their
+// media as { $media: key } and run() fills the real id in.
+// ponytail: demo scenes use their rendered clip, not raw footage with in/out points. Add addClip + trimClip
+// on s.source if users need to widen demo trims inside Concat.
+// musicDuration: the music file's length in seconds, so a longer track can be trimmed to the video.
+export function buildRequests(sb, runDir, exportOut = null, musicDuration = 0) {
+  const location = runDir, name = "concat", path = join(runDir, name);
+  const { width, height, fps } = sb.format;
+  // Concat defaults a new project to 1080p at 30 fps; give it the storyboard's frame and rate.
+  const video = { width, height, rateNum: Math.round(fps * 1000), rateDen: 1000 };
+  const reqs = [{ method: "version" }, { method: "project.create", location, name, video }];
+  const commands = [];
+  let t = 0;
+  for (const [i, s] of sb.scenes.entries()) {
+    const key = `${String(i + 1).padStart(2, "0")}-${s.id}`;
+    reqs.push({ method: "media.import", path, file: join(runDir, "clips", `${key}.mp4`), key });
+    commands.push({ op: "addClip", mediaId: { $media: key }, trackId: "T1", start: +t.toFixed(3) });
+    t += s.duration;
+  }
+  const music = Boolean(sb.music?.file);
+  if (music) {
+    reqs.push({ method: "media.import", path, file: join(runDir, sb.music.file), key: "music" });
+    commands.push({ op: "addClip", mediaId: { $media: "music" }, trackId: "T4", start: 0 });
+  }
+  // A batch reports the last id it minted: the music clip, when there is one, since it goes last.
+  reqs.push({ method: "edit.apply", path, command: { op: "batch", commands }, ...(music ? { key: "musicClip" } : {}) });
+  // ponytail: a track shorter than the video is not looped (render-scenes loops it). Loop here if users ask.
+  if (music && musicDuration > t + 0.001) {
+    reqs.push({ method: "edit.apply", path, command: { op: "trimClip", clipId: { $media: "musicClip" }, edge: "end", delta: -+(musicDuration - t).toFixed(3) } });
+  }
+  reqs.push({ method: "project.save", path });
+  if (exportOut) reqs.push({ method: "export.run", path, output: exportOut, codec: "h264", width, height, rateNum: video.rateNum, rateDen: video.rateDen });
+  return { path, duration: +t.toFixed(3), reqs };
+}
+
+const fillMedia = (v, ids) => JSON.parse(JSON.stringify(v), (k, x) => (x && typeof x === "object" && "$media" in x ? ids[x.$media] : x));
+
+async function run(cli, reqs) {
+  const child = spawn(cli, ["api"], { stdio: ["pipe", "pipe", "inherit"] });
+  const lines = createInterface({ input: child.stdout })[Symbol.asyncIterator]();
+  // Replies carry an id; events are notifications ({ method, params }, no id) and can arrive between
+  // replies, so they are set aside while waiting for the next reply.
+  const events = [];
+  const read = async () => {
+    const { value, done } = await lines.next();
+    if (done) throw new Error("concat-cli closed its output");
+    return JSON.parse(value);
+  };
+  const reply = async () => {
+    for (;;) {
+      const m = await read();
+      if (m.method && !("id" in m)) events.push(m);
+      else return m;
+    }
+  };
+  const event = async (names) => {
+    for (;;) {
+      const i = events.findIndex((e) => names.includes(e.method));
+      if (i >= 0) return events.splice(i, 1)[0];
+      const m = await read();
+      if (m.method && !("id" in m)) events.push(m);
+    }
+  };
+  const ids = {};
+  try {
+    for (const [n, { key, ...req }] of reqs.entries()) {
+      const { method, ...params } = fillMedia(req, ids);
+      child.stdin.write(JSON.stringify({ jsonrpc: "2.0", id: n + 1, method, params }) + "\n");
+      const res = await reply();
+      // An error reply means nothing changed; its message is Concat's reason, in plain words.
+      if (res.error) throw new Error(`${method} refused: ${res.error.message ?? JSON.stringify(res.error)}`);
+      const out = res.result ?? {};
+      if (method === "version") console.log(`concat ${out.concat ?? "?"}, api ${out.apiVersion ?? "?"}`);
+      if (key) {
+        if (!out.createdId) throw new Error(`${method} returned no id${params.file ? ` for ${params.file}` : ""}`);
+        ids[key] = out.createdId;
+      }
+      if (method === "export.run") {
+        // export.run returns at once; progress arrives as events until done or failed.
+        const ev = await event(["export.done", "export.failed"]);
+        if (ev.method === "export.failed") throw new Error(`export failed: ${JSON.stringify(ev.params)}`);
+        console.log(`exported ${params.output}`);
+      }
+    }
+  } finally {
+    child.stdin.end();
+  }
+}
+
+if (process.argv[1] === fileURLToPath(import.meta.url)) {
+  const args = process.argv.slice(2);
+  const fail = (m) => { console.error(`error: ${m}`); process.exit(1); };
+  const runDir = resolve(args.find((a) => !a.startsWith("--") && !/\.(mp4|mov|webm)$/i.test(a)) ?? ".");
+  const exportOut = args.includes("--export") ? resolve(args.find((a) => /\.(mp4|mov|webm)$/i.test(a)) ?? join(runDir, "final-concat.mp4")) : null;
+  const sb = JSON.parse(readFileSync(join(runDir, "storyboard.json"), "utf8"));
+  const musicFile = sb.music?.file && join(runDir, sb.music.file);
+  const probe = musicFile && existsSync(musicFile) && spawnSync("ffprobe", ["-v", "error", "-show_entries", "format=duration", "-of", "csv=p=0", musicFile], { encoding: "utf8" });
+  const { path, duration, reqs } = buildRequests(sb, runDir, exportOut, Number(probe?.stdout?.trim()) || 0);
+
+  if (args.includes("--dry-run")) {
+    console.log(JSON.stringify(reqs, null, 2));
+    process.exit(0);
+  }
+  for (const r of reqs) if (r.method === "media.import" && !existsSync(r.file)) fail(`missing ${r.file}; run render-scenes.mjs first`);
+  const cli = process.env.CONCAT_CLI || "concat-cli";
+  if (spawnSync(cli, ["--version"]).error) fail(`${cli} not found; install Concat from https://concatenate.pages.dev/#download or set CONCAT_CLI`);
+  // Concat refuses to create a project in a folder that already holds one. Keep the old one aside
+  // (it may carry edits made in Concat) instead of deleting it.
+  if (existsSync(path)) {
+    const aside = `${path}-${new Date().toISOString().replace(/[:.]/g, "-")}`;
+    renameSync(path, aside);
+    console.log(`moved the previous Concat project to ${aside}`);
+  }
+  await run(cli, reqs).catch((e) => fail(e.message));
+  writeFileSync(join(runDir, "project.concat.txt"), `${path}\n`);
+  console.log(`wrote ${path} (${sb.scenes.length} scenes, ${duration}s). Open it in Concat to edit and export.`);
+}

package/skills/luckiest-video-studio/scripts/assemble-concat.test.mjs

@@ -0,0 +1,36 @@
+import { test } from "node:test";
+import assert from "node:assert/strict";
+import { buildRequests } from "./assemble-concat.mjs";
+
+const sb = {
+  format: { width: 1920, height: 1080, fps: 30 },
+  scenes: [{ id: "hook", duration: 2.5 }, { id: "demo", kind: "demo", duration: 4 }, { id: "outro", duration: 3 }],
+  music: { file: "music.mp3" },
+};
+
+test("clips land in storyboard order at cumulative starts, music on its own track", () => {
+  const { path, duration, reqs } = buildRequests(sb, "/run", "/run/out.mp4");
+  assert.equal(path, "/run/concat");
+  assert.equal(duration, 9.5);
+  assert.deepEqual(reqs.slice(0, 2).map((r) => r.method), ["version", "project.create"]);
+  assert.deepEqual(reqs[1].video, { width: 1920, height: 1080, rateNum: 30000, rateDen: 1000 });
+  assert.deepEqual(reqs.filter((r) => r.method === "media.import").map((r) => r.file),
+    ["/run/clips/01-hook.mp4", "/run/clips/02-demo.mp4", "/run/clips/03-outro.mp4", "/run/music.mp3"]);
+  const { commands } = reqs.find((r) => r.method === "edit.apply").command;
+  assert.deepEqual(commands.map((c) => [c.mediaId.$media, c.trackId, c.start]),
+    [["01-hook", "T1", 0], ["02-demo", "T1", 2.5], ["03-outro", "T1", 6.5], ["music", "T4", 0]]);
+  assert.deepEqual(reqs.slice(-2).map((r) => r.method), ["project.save", "export.run"]);
+});
+
+test("a music track longer than the video is trimmed to it", () => {
+  const { reqs } = buildRequests(sb, "/run", null, 10);
+  const batch = reqs.find((r) => r.command?.op === "batch");
+  assert.equal(batch.key, "musicClip");
+  const trim = reqs.find((r) => r.command?.op === "trimClip").command;
+  assert.deepEqual(trim, { op: "trimClip", clipId: { $media: "musicClip" }, edge: "end", delta: -0.5 });
+  assert.ok(!buildRequests(sb, "/run", null, 9).reqs.some((r) => r.command?.op === "trimClip"));
+});
+
+test("no export request without --export", () => {
+  assert.ok(!buildRequests(sb, "/run").reqs.some((r) => r.method === "export.run"));
+});

package/skills/luckiest-vouch/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 ## Step 1: Figure out the intent
 

package/skills/luckiest-wishes/SKILL.md

@@ -3,7 +3,7 @@ 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>`.
+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> (say /next to do it)`. Every Next line, including fixed ones written below, ends with " (say /next to do it)", so the user can run it by typing /next.
 
 Chart grammar for any dashboard output in this skill: