luckiest-co 1.0.12 → 1.0.14

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

package/commands/charms.md

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

package/commands/finish.md

@@ -2,7 +2,7 @@
 description: Wrap up, what shipped, what changed, what's next.
 ---
 
-Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 Asking the user a question: this command tells you to use the AskUserQuestion tool
 so the user can click instead of typing. That tool only exists in Claude Code. In
@@ -33,7 +33,7 @@ Reply with a number, or tell me what to change.
 
 ## Step 1: Check that everything is done
 
-Derive the project key as described in `references/project-key.md`. Pass this same `project` value on both luckiest plan tool calls in this command (`status` here and `finish` in Step 3), so you close this project's plan and not another one.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. Pass this same `project` value on both luckiest plan tool calls in this command (`status` here and `finish` in Step 3), so you close this project's plan and not another one.
 
 Call the `status` tool from the luckiest MCP server with that `project` value.
 

package/commands/go.md

@@ -2,7 +2,7 @@
 description: Run your plan, one task at a time, checked as it goes.
 ---
 
-Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 Asking the user a question: this command tells you to use the AskUserQuestion tool
 so the user can click instead of typing. That tool only exists in Claude Code. In
@@ -33,7 +33,7 @@ Reply with a number, or tell me what to change.
 
 ## Step 1: Load the plan
 
-Derive the project key as described in `references/project-key.md`. Pass this same `project` value on every luckiest plan tool call in this command (`status`, `apply`, `verify`, `pause`), so you run this project's plan and not another one.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. Pass this same `project` value on every luckiest plan tool call in this command (`status`, `apply`, `verify`, `pause`), so you run this project's plan and not another one.
 
 Call the `status` tool from the luckiest MCP server with that `project` value. This is a zero-context resume, treat its result as the full picture of where things stand: don't assume anything about prior state beyond what it returns.
 
@@ -60,7 +60,7 @@ Research subagents (looking something up, exploring the codebase) are always all
 
 Take the ready tasks one at a time, in order. For each one:
 
-1. First, turn the task into a tight working prompt with the `luckiest-prompt-rewrite` skill, targeting whoever will do the work (yourself, or the subagent and its model from Step 2). Use that rewritten prompt to do the task. If the skill is not installed, write a clear prompt yourself and continue. Do this before every task, in both default and fast mode.
+1. If the task is being handed to a subagent (fast mode), first turn it into a tight working prompt with the `luckiest-prompt-rewrite` skill, targeting that subagent and its model from Step 2; if the skill is not installed, write a clear prompt yourself. When you are doing the task yourself, skip the rewrite and start working; the task title and its "done means..." line are the prompt.
 2. Do the work using the task's suggested skill. If that skill is installed, invoke it via the Skill tool. If it isn't installed, do the work directly without it.
 3. Check your result against the task's "done means..." line. Don't move on until it's actually met.
 4. If the result is something the user can try themselves (a page, a feature, a flow), ask with the AskUserQuestion tool so they can click instead of typing. Question: "Try it yourself, does it work?" Options: "Works" and "Needs fixes" (keep the "Other" free-text choice available). Wait for their answer.
@@ -71,6 +71,9 @@ Only move to the next ready task once the current one is applied and verified (o
 
 After a task passes and is verified, run a quick automation check. Ask yourself: was this task repeatable, rule-based, or the kind of thing that will come up again? If yes, offer it with the AskUserQuestion tool so the user can click instead of typing. Question: "This looks worth automating. Turn it into a skill you can schedule or run as a routine?" Options: "Automate it" and "Skip" (keep the "Other" free-text choice available). Only offer, never build it without a yes. If they say yes, create the skill (with the skill-builder or skill-creator skill) and set it up to run on a schedule or as a routine. If the task was a one-off, skip the offer and move on.
 
+
+Shell note: always quote file paths in shell commands. Paths with parentheses or brackets (for example `app/(public)/orders`) break zsh globbing when unquoted and waste turns on retries. Prefer the dedicated file tools (Read, Glob, Grep) over shell listing commands when either works.
+
 ## Step 4: Stop conditions
 
 Pause and ask the user before doing any of the following, even if it seems like the obvious next step:

package/commands/helpers.md

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

package/commands/home.md

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

package/commands/leaderboard.md

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

package/commands/merge.md

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

package/commands/overlaps.md

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

package/commands/plan.md

@@ -2,7 +2,7 @@
 description: Plan your next piece of work. Guided questions, then a plan Claude can run.
 ---
 
-Read `references/vocabulary.md` first and follow it for all output in this command: plain language, no em dashes, no internal terms, one next-step recommendation at the end.
+Output rules for this command: plain language, no em dashes, no internal terms, and end with exactly one next-step line in the form `Next: <one action>`. The server may return internal words; translate them and never show them: PLAN means plan, APPLY means go, UNIFY means finish, DRAFT means in progress, DOING means active, DONE means complete, UAT means testing, AC means requirements, HANDOFF means ready for review, skill_loop means status.
 
 Asking the user a question: this command tells you to use the AskUserQuestion tool
 so the user can click instead of typing. That tool only exists in Claude Code. In
@@ -37,7 +37,7 @@ Check whether `.luckiest/BRIEF.md` exists in the current project. If it exists,
 
 ## Step 2: Check for active work
 
-Derive the project key as described in `references/project-key.md`. Pass this same `project` value on every luckiest plan tool call in this command (`status` here and `plan` in Step 5), so this project gets its own plan and does not collide with another project's.
+Derive the project key once per session: run `git config --get remote.origin.url` and normalize the result to lowercase `host/owner/repo` with any `.git` suffix removed (for example `git@github.com:acme/app.git` becomes `github.com/acme/app`). If it is not a git repo, use the absolute working directory path. If there is no local shell (web chat, Cowork), omit `project` entirely. Pass this same `project` value on every luckiest plan tool call in this command (`status` here and `plan` in Step 5), so this project gets its own plan and does not collide with another project's.
 
 Call the `status` tool from the luckiest MCP server with that `project` value.
 
@@ -46,7 +46,9 @@ Call the `status` tool from the luckiest MCP server with that `project` value.
 
 ## Step 3: Run the interview
 
-Open the interview with a short line that says no plan is active and you are starting the interview.
+If the user's invocation already states the outcome they want (they passed arguments describing a goal, a feature, or a problem to solve), skip the interview question entirely. Say in one line that you are planning from what they gave you, use their stated outcome directly, and jump ahead to drafting the task list below. The approval question in Step 4 still runs; it is the only question they get.
+
+Otherwise, open the interview with a short line that says no plan is active and you are starting the interview.
 
 Then ask question 1 using the AskUserQuestion tool so the user can click an answer instead of typing one. Do not put the examples in plain text for them to copy. Present them as selectable options:
 
@@ -60,7 +62,7 @@ Use the answer (plus the brief, if present) to shape a draft task list of 3 to 7
 
 Include non-coding work too. Marketing, content, design, research, and ops tasks belong in the plan alongside code. Never drop a task just because it is not a coding task; route it to its matching skill like any other.
 
-For each draft task, call the `skill_router` tool from the luckiest MCP server. It returns `skills` (matching owned skills) and `who` (up to 3 tribe members who finished a similar task before). Attach the suggested skill(s) to the task, and attach `who` so the plan can carry who has done this kind of work.
+Route all draft tasks in ONE `skill_router` call from the luckiest MCP server: pass `prompts` as an array of every task title. It returns `results`, one entry per task with `skills` (matching owned skills) and `who` (up to 3 tribe members who finished a similar task before). Attach the suggested skill(s) to each task, and attach `who` so the plan can carry who has done this kind of work. If the server rejects `prompts` (older server), fall back to one `skill_router` call per task, issued in parallel in a single message, never one at a time.
 
 For each task, state a one-line "done means..." in chat (not in the title, not stored anywhere) so the user sees what complete looks like for that task. When `who` is not empty, add a short line naming those people, for example "Done before by: **Sam**, **Alex**."
 

package/commands/skills.md

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

package/commands/start.md

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

package/commands/status.md

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

package/commands/updates.md

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

package/commands/vouch.md

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

package/commands/wishes.md

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "luckiest-co",
-  "version": "1.0.12",
+  "version": "1.0.14",
   "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-design-website/ATTRIBUTION.md

@@ -0,0 +1,38 @@
+# Attribution
+
+This skill, `luckiest-design-website`, is the Luckiest edition of the original
+skill **"scrollcraft"** from the **scroll-craft** project
+(https://github.com/nateherkai/scroll-craft) by **Nate Herk**
+(https://github.com/nateherkai), released under the MIT License.
+
+The original work has been rebranded, security-reviewed, and improved. The
+engine (`engine/scrollcraft.js`, `engine/scrollcraft.css`), the scripts, the
+`SCROLLCRAFT_*` environment variables and the `.scrollcraft.json` workspace file
+keep their original names so the upstream mechanism runs unchanged. The
+original copyright and license are preserved verbatim below and in `LICENSE`.
+
+---
+
+## Original License (verbatim)
+
+MIT License
+
+Copyright (c) 2026 Nate Herk
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/luckiest-design-website/CHANGELOG.md

@@ -0,0 +1,104 @@
+# Changelog — luckiest-design-website
+
+## 1.0.0 — 2026-09-04
+Rebranded from scrollcraft (scroll-craft by Nate Herk, MIT, upstream v0.2.0).
+
+### Security pass
+- PASS. 29 files scanned. One low advisory, now documented in the skill body:
+  `scripts/kie.mjs` reads `KIE_AI_API_KEY` from env or the nearest `.env` and
+  sends it as a bearer token to two kie.ai hosts (`api.kie.ai` and the upload
+  host `kieai.redpandaai.co`). Only the `--ref` image the user names is
+  uploaded. Both hosts are central to the skill's stated purpose. The skill
+  now tells the agent to reference the env var name only and never ask for the
+  key in chat.
+
+### Best-practices pass
+- SKILL.md rewritten from 415 to 372 lines, third person, each reference
+  named with when to load it. `license`, `metadata.version`, and
+  `metadata.listing_id` added. `allowed-tools` kept minimal (Bash is required
+  for the doctor, encode, serve and shoot scripts).
+- Upstream `CHANGELOG.md` preserved as `UPSTREAM-CHANGELOG.md`; upstream
+  `EXAMPLES.md` preserved as `references/registry-examples.md`.
+- Engine, scripts, env vars and workspace file names kept verbatim so the
+  upstream mechanism runs unchanged. Prose self-references rebranded.
+- `scripts/doctor.mjs`: ffmpeg hint now names the macOS and Linux installs
+  next to the Windows one. The preflight was run on macOS during this rebrand
+  and works; upstream said it had only ever been run on Windows.
+
+### Improve pass (/refract)
+- Interview question 9: a dollar spend cap for generated assets. Zero routes
+  the build to the user's own footage plus CSS-only devices. The source had a
+  first-class no-spend route but never asked for the cap up front.
+- CSS-first device rule: `reveal`, `parallax`, `in` and `drift` run on
+  `animation-timeline: scroll()` / `view()` behind `@supports`, with the engine
+  as fallback; the engine keeps `scrub`, `pin`, `pan` and `--sc-p` consumers.
+- Performance budget in the verify step: LCP under 2.5s on the hero poster,
+  INP under 200ms while scrubbing, and a mobile poster-plus-CSS fallback for
+  any act that cannot hold it.
+- New triggers: "rebuild my landing page as an experience", "this looks
+  AI-made", "design my website".
+- Copy is now a step, not an afterthought: `luckiest-copywriting` writes the
+  act headlines, belief sentence and CTA label; `luckiest-copywriting-humanize`
+  is the finishing pass.
+- Head metadata and one JSON-LD block via `luckiest-schema`; an event plan
+  (act reached, peak reached, CTA click) via `luckiest-analytics`. The peak
+  reach rate is named as the page's success metric.
+- `luckiest-extract-design-system` seeds tokens from an existing site when no
+  brand kit exists. `luckiest-image` and `luckiest-video` are offered as asset
+  generators alongside kie.ai. `luckiest-cro` reviews the close act.
+- Hard rules extended with the AI-slop tells the trend pass surfaced: uniform
+  radius and card heights, Inter or system font as the display face, blue-purple
+  gradients, "Build the future" class headlines, and the INP ship-blocker.
+
+### Network hooks
+- Assist-request: when the human is unreachable, offer to raise an
+  assist-request to the tribe before self-authoring the brief.
+- Share-with-tribe: after the report, OFFER to share the fingerprint row and
+  contact sheet only. Never BRIEF.md, brand assets, client names or copy.
+- Pick-up-where-they-left: offer to seed a follow-up Luckiest plan (events
+  wired, real-phone check, one A/B test on the peak or close).
+
+### Trend pass (/newsjack + /luckiest-trends)
+- The luckiest-trends engine ran with a query plan but timed out on YouTube
+  transcript fetching before emitting evidence and saved no output. The
+  newsjack CLI is not installed. Signals below came from host web search on
+  2026-09-04 and are best-effort on freshness.
+- CSS scroll-driven animations (`animation-timeline: scroll()` / `view()`) at
+  roughly 84% global support, compositor-driven, Chrome 115+, Firefox 132+,
+  Safari 18+. Acted on as the CSS-first device rule. Sources: MDN CSS
+  scroll-driven animations guide; CSSAWWWARDS "Scroll Timelines Guide (2026)";
+  dev.to "Creating Complex Scroll-driven Animations with Pure CSS in 2026".
+  Retrieved 2026-09-04.
+- Safari 26.2 (released 2025-12-12) ships LCP and the Event Timing API behind
+  INP, so iOS can now be measured; INP is the most-failed Core Web Vital
+  (about 43% of sites over 200ms) and scrollytelling video scrub is a known
+  offender on phones. Acted on as the performance budget and the INP
+  ship-blocker. Sources: DebugBear "Firefox And Safari Now Support Two Core
+  Web Vitals Metrics"; RUMvision "Safari catching up: INP and LCP in 26.2";
+  scrollytelling.ai examples review. Retrieved 2026-09-04.
+- "AI slop" web design is being named by its tells: Inter or system fonts,
+  blue-purple gradients, "Build the future" headlines, uniform 16px radius,
+  identical card heights, distributional convergence. Acted on as new hard
+  rules and new triggers. Source: 925 Studios "AI Slop Web Design: Complete
+  Guide to Spotting and Fixing Generic Websites (2026)". Retrieved 2026-09-04.
+
+### Thumbnail
+- Routes to the `nodes` scene via "design" in the title (also "structure",
+  "design", "system" in the description). No hash fallback.
+
+### Recommendations not implemented (next versions)
+- R1. Ship a `scripts/vitals.mjs` that reads LCP and INP from the shoot run,
+  so the budget is measured by the harness rather than by hand. Small
+  Playwright addition to `shoot.mjs`.
+- R2. Emit the CSS-first devices as a documented `engine/scrollcraft-css.css`
+  layer with `@supports` fallbacks, so builds do not hand-write the same
+  `animation-timeline` blocks.
+- R3. Replace the kie.ai-only generator with a provider switch in `kie.mjs`
+  (kie.ai, fal, Replicate) so `luckiest-image` and `luckiest-video` routes
+  share the encode pipeline instead of ending at a file handoff.
+- R4. A `--brand <dir>` flag on `workspace.mjs` that reads
+  `luckiest-extract-design-system` tokens straight into the `:root` block of
+  `template.html`.
+- R5. An eval fixture: one recorded interview plus expected BRIEF.md, grammar
+  choice and gate result, so a regression in the procedure is caught without
+  a real build.

package/skills/luckiest-design-website/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Nate Herk
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.