luckiest-co 1.0.47 → 1.0.48

package/skills/brainstorm/SKILL.md

@@ -13,6 +13,31 @@ Start by understanding the current project context, then ask questions one at a
 Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
 </HARD-GATE>
 
+## Your First Message
+
+Before replying, ask what you actually know about what they want, and why.
+If everything that matters is in the request ("make the icon cornflower
+blue"), the request is the design: say it back in one line and get a yes. If something
+non-trivial is missing, your first message is two things, in this order:
+
+1. One line saying that if they'd rather skip the questions and have you just
+   start, they can say so. If they do, state the design and any significant
+   how-it-gets-made choice (platform, language, medium) in a few plain lines,
+   and proceed on their yes.
+2. One open question that gets them describing a real moment or a concrete
+   picture: "What's the moment you find yourself wishing this existed?"
+
+**Say your defaults out loud.** Find out early which choices about platform,
+language, libraries, or materials they want to make and which they hand to
+you. Any choice you make goes in the design as your call, never as something
+they agreed to.
+
+**Spikes.** A quick throwaway build is often the cheapest way to learn what
+they want or whether something works. Offer one when it would help. With
+their yes it may be built: it stays labeled throwaway, skips the plan and
+the full test pass, and keeping what it produced is a new request that comes
+back through the gate above.
+
 ## Anti-Pattern: "This Is Too Simple To Need A Design"
 
 Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
@@ -22,11 +47,11 @@ Every project goes through this process. A todo list, a single-function utility,
 You MUST create a task for each of these items and complete them in order:
 
 1. **Explore project context** — check files, docs, recent commits
-2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+2. **Ask clarifying questions** — one at a time, open questions before any menu, understand purpose/constraints/success criteria
 3. **Propose 2-3 approaches** — with trade-offs and your recommendation
 4. **Present design** — in sections scaled to their complexity, get user approval after each section
 5. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
-6. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
+6. **Builder check** — a fresh subagent reads the spec as its builder and lists what it would still have to guess (see below)
 7. **User reviews written spec** — ask user to review the spec file before proceeding
 8. **Transition to implementation** — invoke writing-plans skill to create implementation plan
 
@@ -40,7 +65,7 @@ digraph brainstorming {
     "Present design sections" [shape=box];
     "User approves design?" [shape=diamond];
     "Write design doc" [shape=box];
-    "Spec self-review\n(fix inline)" [shape=box];
+    "Builder check" [shape=box];
     "User reviews spec?" [shape=diamond];
     "Invoke writing-plans skill" [shape=doublecircle];
 
@@ -50,8 +75,8 @@ digraph brainstorming {
     "Present design sections" -> "User approves design?";
     "User approves design?" -> "Present design sections" [label="no, revise"];
     "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Spec self-review\n(fix inline)";
-    "Spec self-review\n(fix inline)" -> "User reviews spec?";
+    "Write design doc" -> "Builder check";
+    "Builder check" -> "User reviews spec?";
     "User reviews spec?" -> "Write design doc" [label="changes requested"];
     "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
 }
@@ -67,7 +92,7 @@ digraph brainstorming {
 - Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
 - If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
 - For appropriately-scoped projects, ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
+- Start with open questions that get them describing; offer a short menu only when they're stuck, and propose something concrete when they say "just guess"
 - Only one question per message - if a topic needs more exploration, break it into multiple questions
 - Focus on understanding: purpose, constraints, success criteria
 
@@ -107,22 +132,30 @@ digraph brainstorming {
 - Use elements-of-style:writing-clearly-and-concisely skill if available
 - Commit the design document to git
 
-**Spec Self-Review:**
-After writing the spec document, look at it with fresh eyes:
+**Builder Check:**
+After writing the spec document, dispatch a fresh subagent with
+`builder-check-prompt.md` in this skill directory. When you tell the user
+you're writing it up, say a reviewer will read it first and you may come back
+once with a few questions. Sort what the builder asks into three piles:
+
+- **Answered already** by the conversation or the project: put the answer in
+  the document.
+- **Minor:** a sensible builder could settle it without changing what gets
+  built. Settle it yourself and mark it in the document as your call.
+- **Theirs:** only the user can answer it, and the answer changes what gets
+  built. Bring these in one message, most important first.
 
-1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
-2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
-3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?
-4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.
+That is the only round of questions the check produces. Without a subagent
+tool, read the document as that builder yourself, and still fix placeholders,
+contradictions, and ambiguity inline.
 
-Fix any issues inline. No need to re-review — just fix and move on.
 
 **User Review Gate:**
-After the spec review loop passes, ask the user to review the written spec before proceeding:
+After the builder check, ask the user to review the written spec before proceeding:
 
 > "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
 
-Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
+Wait for the user's response. If they request changes, make them and re-run the builder check. Only proceed once the user approves.
 
 **Implementation:**
 
@@ -132,8 +165,18 @@ Wait for the user's response. If they request changes, make them and re-run the
 ## Key Principles
 
 - **One question at a time** - Don't overwhelm with multiple questions
-- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **Get them describing** - Open questions first, a short menu only when they're stuck
 - **YAGNI ruthlessly** - Remove unnecessary features from all designs
 - **Explore alternatives** - Always propose 2-3 approaches before settling
 - **Incremental validation** - Present design, get approval before moving on
 - **Be flexible** - Go back and clarify when something doesn't make sense
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "I'll offer options to save them effort" | Options steer. Ask them to describe it first. |
+| "I'll fill in sensible defaults" | Good. Say them out loud. A default they never heard is one they couldn't reject. |
+| "I should explain the process first" | Ask your question. The process shows itself. |
+| "They said 'sounds good' to the idea" | Approval covers what you showed them. A design you haven't written isn't approved. |
+| "The spike works, I'll keep building on it" | Keeping it is a new request. Back through the gate. |

package/skills/brainstorm/builder-check-prompt.md

@@ -0,0 +1,23 @@
+# Builder Check Prompt
+
+Dispatch a fresh general-purpose subagent with this prompt once the written
+design exists. Fill in the domain and the document path.
+
+```
+You are a talented [DOMAIN, e.g. "software engineer", "event planner"].
+You've been handed a design document and asked to put together a plan to
+build what it describes. You will not be able to talk to the person who
+wrote it.
+
+Read [DOCUMENT_PATH].
+
+Report only the questions you'd still need answered before you could plan
+this well: places where you'd have to guess and a wrong guess would matter.
+For each, give the question and why the answer changes the plan. Rank them
+by importance.
+
+Skip anything the document explicitly leaves to the builder, and anything
+you could reasonably decide yourself. Skip nitpicks about wording.
+
+If nothing important is left, say "nothing important left".
+```

package/skills/churn-prevention/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog — luckiest-churn-prevention
 
+## 1.1.1 — 2026-10-16
+From coreyhaines31/marketingskills at 1efedbc (issue #174, MIT).
+
+- Paddle Billing webhook names corrected (`transaction.payment_failed`, `subscription.past_due`, `subscription.canceled`).
+
 ## 1.1.0 — 2026-07-06
 Skill updater pass: analytics integration.
 

package/skills/churn-prevention/SKILL.md

@@ -3,7 +3,7 @@ name: churn-prevention
 description: "When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers or wants to build systems to prevent it. For post-cancel win-back email sequences, see luckiest-emails. For in-app upgrade paywalls, see luckiest-paywalls."
 license: See ATTRIBUTION.md
 metadata:
-  version: "1.1.0"
+  version: "1.1.1"
   listing_id: luckiest-churn-prevention
   author: luckiest
 ---
@@ -14,9 +14,9 @@ This skill provides expert guidance on SaaS retention and churn prevention. Its
 
 ## Staying current
 
-On activation, call the Luckiest MCP check_updates tool with { listingId: "b4e5958d-e47d-4e84-a936-0ed6cfc99317", installedSemver: "1.1.0" }. 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.
+On activation, call the Luckiest MCP check_updates tool with { listingId: "b4e5958d-e47d-4e84-a936-0ed6cfc99317", installedSemver: "1.1.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-churn-prevention", skill_version: "1.1.0", 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.
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-churn-prevention", skill_version: "1.1.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.
 
 ## Before Starting
 

package/skills/churn-prevention/evals/evals.json

@@ -88,6 +88,20 @@
         "Does not attempt to write a full email sequence"
       ],
       "files": []
+    },
+    {
+      "id": 7,
+      "prompt": "Our Paddle Billing dunning handler listens for subscription.payment_failed and subscription.cancelled but never runs. A failed transaction has no subscription_id, and another active subscription has a scheduled cancellation next month. Which events should we configure, and should both customers lose access now?",
+      "expected_output": "Should use the linked dunning playbook and diagnose the invalid Paddle Billing event names. Should recommend transaction.payment_failed for payment attempts, subscription.past_due for overdue subscription state, and subscription.canceled for effective cancellation. Should distinguish one-off transaction failures using subscription_id and explain that a scheduled cancellation emits subscription.updated before subscription.canceled at its effective date. Should not treat either case as immediate subscription cancellation or confuse Paddle Classic alerts with Billing events.",
+      "assertions": [
+        "Corrects the payment event to transaction.payment_failed",
+        "Uses subscription.canceled with the Billing spelling",
+        "Uses subscription.past_due for overdue subscription state",
+        "Does not classify a failed transaction without subscription_id as subscription churn",
+        "Keeps scheduled cancellation distinct from effective cancellation",
+        "References current Paddle Billing documentation and separates Classic alert names"
+      ],
+      "files": []
     }
   ]
 }

package/skills/churn-prevention/references/dunning-playbook.md

@@ -316,7 +316,12 @@ Final:   Mark subscription as unpaid after last retry
 **Managed dunning:**
 - Paddle handles retries and dunning automatically
 - Limited customization (Paddle manages the relationship)
-- Webhook: `subscription.payment_failed`, `subscription.cancelled`
+- **Paddle Billing webhooks** (dot-separated `event_type` names):
+  - `transaction.payment_failed` reports a failed payment attempt. Use its `subscription_id` to associate a subscription renewal; a failed one-off transaction is not subscription churn.
+  - `subscription.past_due` reports that the subscription is past due.
+  - `subscription.canceled` reports an effective cancellation. A cancellation scheduled for the next billing period emits `subscription.updated` first; retain access according to the current subscription state until that change takes effect.
+- Configure notification subscriptions for these exact names. `subscription.payment_failed` and `subscription.cancelled` are not Paddle Billing event types; do not mix Billing webhooks with the separate Paddle Classic alert names.
+- Verify the [payment-failure](https://developer.paddle.com/webhooks/transactions/transaction-payment-failed/) and [cancellation](https://developer.paddle.com/webhooks/subscriptions/subscription-canceled/) contracts before wiring account state changes.
 - Best for hands-off approach
 
 ### Recurly

package/skills/coder-brainstorming/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog — luckiest-coder-brainstorming
 
+## 1.4.0 — 2026-10-16
+
+- Rebuilt-brainstorming ideas from obra/superpowers at bb92a77 (v7.0.0, MIT): first message offers to skip the questions and opens with one open question, open questions before any menu, defaults said out loud, throwaway spikes with a gate exception, a builder-check subagent (`builder-check-prompt.md`) in place of the spec self-review, and a Red Flags table. Removed the unused `spec-document-reviewer-prompt.md`.
+- Visual companion server: content containing `$&` or `$'` no longer corrupts the page (function replacement).
+
+## 1.3.0 — 2026-10-12
+- Explore step runs the `luckiest-coder-components` lookup when the work involves
+  UI components, so reusable matches shape the proposed approaches.
+- `check_updates` and `report_usage` -> 1.3.0.
+
 ## 1.2.0 — 2026-09-22
 Practices adopted from BuilderOS, Compound Engineering, and firstmate.
 

package/skills/coder-brainstorming/SKILL.md

@@ -3,7 +3,7 @@ name: coder-brainstorming
 description: Use BEFORE any creative or build work — creating features, building components, adding functionality, or modifying behavior. Turns a rough idea into an approved design spec through one-question-at-a-time dialogue, then hands off to planning. Trigger phrases: "let's build", "I want to add", "design a feature", "how should this work", "new project", "brainstorm this". Gates all implementation until a design is approved.
 license: See ATTRIBUTION.md
 metadata:
-  version: "1.2.0"
+  version: "1.4.0"
   listing_id: luckiest-coder-brainstorming
   author: luckiest
 ---
@@ -18,6 +18,31 @@ Start by understanding the current project context, then ask questions one at a
 Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
 </HARD-GATE>
 
+## Your First Message
+
+Before replying, ask what you actually know about what they want, and why.
+If everything that matters is in the request ("make the icon cornflower
+blue"), the request is the design: say it back in one line and get a yes. If something
+non-trivial is missing, your first message is two things, in this order:
+
+1. One line saying that if they'd rather skip the questions and have you just
+   start, they can say so. If they do, state the design and any significant
+   how-it-gets-made choice (platform, language, medium) in a few plain lines,
+   and proceed on their yes.
+2. One open question that gets them describing a real moment or a concrete
+   picture: "What's the moment you find yourself wishing this existed?"
+
+**Say your defaults out loud.** Find out early which choices about platform,
+language, libraries, or materials they want to make and which they hand to
+you. Any choice you make goes in the design as your call, never as something
+they agreed to.
+
+**Spikes.** A quick throwaway build is often the cheapest way to learn what
+they want or whether something works. Offer one when it would help. With
+their yes it may be built: it stays labeled throwaway, skips the plan and
+the full test pass, and keeping what it produced is a new request that comes
+back through the gate above.
+
 ## Anti-Pattern: "This Is Too Simple To Need A Design"
 
 Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
@@ -28,13 +53,13 @@ Every project goes through this process. A todo list, a single-function utility,
 
 You MUST create a task for each of these items and complete them in order:
 
-1. **Explore project context** — check files, docs, recent commits
+1. **Explore project context** — check files, docs, recent commits. If the work involves UI components, run the luckiest-coder-components lookup and bring any reusable match into the approaches
 2. **Offer the visual companion just-in-time** — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.
-3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Ask clarifying questions** — one at a time, open questions before any menu, understand purpose/constraints/success criteria
 4. **Propose 2-3 approaches** — with trade-offs and your recommendation
 5. **Present design** — in sections scaled to their complexity, get user approval after each section
 6. **Write design doc** — save to `docs/luckiest-coder/specs/YYYY-MM-DD-<topic>-design.md` and commit
-7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
+7. **Builder check** — a fresh subagent reads the spec as its builder and lists what it would still have to guess (see below)
 8. **User reviews written spec** — ask user to review the spec file before proceeding
 9. **Transition to implementation** — invoke luckiest-coder-writing-plans skill to create implementation plan
 
@@ -48,7 +73,7 @@ digraph brainstorming {
     "Present design sections" [shape=box];
     "User approves design?" [shape=diamond];
     "Write design doc" [shape=box];
-    "Spec self-review\n(fix inline)" [shape=box];
+    "Builder check" [shape=box];
     "User reviews spec?" [shape=diamond];
     "Invoke luckiest-coder-writing-plans skill" [shape=doublecircle];
 
@@ -58,8 +83,8 @@ digraph brainstorming {
     "Present design sections" -> "User approves design?";
     "User approves design?" -> "Present design sections" [label="no, revise"];
     "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Spec self-review\n(fix inline)";
-    "Spec self-review\n(fix inline)" -> "User reviews spec?";
+    "Write design doc" -> "Builder check";
+    "Builder check" -> "User reviews spec?";
     "User reviews spec?" -> "Write design doc" [label="changes requested"];
     "User reviews spec?" -> "Invoke luckiest-coder-writing-plans skill" [label="approved"];
 }
@@ -75,7 +100,7 @@ digraph brainstorming {
 - Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
 - If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
 - For appropriately-scoped projects, ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
+- Start with open questions that get them describing; offer a short menu only when they're stuck, and propose something concrete when they say "just guess"
 - Only one question per message - if a topic needs more exploration, break it into multiple questions
 - Focus on understanding: purpose, constraints, success criteria
 
@@ -115,22 +140,29 @@ digraph brainstorming {
 - Use elements-of-style:writing-clearly-and-concisely skill if available
 - Commit the design document to git
 
-**Spec Self-Review:**
-After writing the spec document, look at it with fresh eyes:
+**Builder Check:**
+After writing the spec document, dispatch a fresh subagent with
+`builder-check-prompt.md` in this skill directory. When you tell the user
+you're writing it up, say a reviewer will read it first and you may come back
+once with a few questions. Sort what the builder asks into three piles:
 
-1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
-2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
-3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?
-4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.
+- **Answered already** by the conversation or the project: put the answer in
+  the document.
+- **Minor:** a sensible builder could settle it without changing what gets
+  built. Settle it yourself and mark it in the document as your call.
+- **Theirs:** only the user can answer it, and the answer changes what gets
+  built. Bring these in one message, most important first.
 
-Fix any issues inline. No need to re-review — just fix and move on.
+That is the only round of questions the check produces. Without a subagent
+tool, read the document as that builder yourself, and still fix placeholders,
+contradictions, and ambiguity inline.
 
 **User Review Gate:**
-After the spec review loop passes, ask the user to review the written spec before proceeding:
+After the builder check, ask the user to review the written spec before proceeding:
 
 > "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
 
-Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
+Wait for the user's response. If they request changes, make them and re-run the builder check. Only proceed once the user approves.
 
 **Implementation:**
 
@@ -141,12 +173,22 @@ Wait for the user's response. If they request changes, make them and re-run the
 ## Key Principles
 
 - **One question at a time** - Don't overwhelm with multiple questions
-- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **Get them describing** - Open questions first, a short menu only when they're stuck
 - **YAGNI ruthlessly** - Remove unnecessary features from all designs
 - **Explore alternatives** - Always propose 2-3 approaches before settling
 - **Incremental validation** - Present design, get approval before moving on
 - **Be flexible** - Go back and clarify when something doesn't make sense
 
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "I'll offer options to save them effort" | Options steer. Ask them to describe it first. |
+| "I'll fill in sensible defaults" | Good. Say them out loud. A default they never heard is one they couldn't reject. |
+| "I should explain the process first" | Ask your question. The process shows itself. |
+| "They said 'sounds good' to the idea" | Approval covers what you showed them. A design you haven't written isn't approved. |
+| "The spike works, I'll keep building on it" | Keeping it is a new request. Back through the gate. |
+
 ## Visual Companion
 
 A browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.
@@ -169,7 +211,7 @@ If they agree to the companion, read the detailed guide before proceeding:
 ## Staying current
 
 On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "a11fbe77-8a4e-47b7-b3f2-b70657c8e7f3", installedSemver: "1.2.0" }`.
+`{ listingId: "a11fbe77-8a4e-47b7-b3f2-b70657c8e7f3", installedSemver: "1.4.0" }`.
 If it returns `upToDate: false`, surface the `notice` to the user. Do nothing if `upToDate: true`.
 
-When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-brainstorming", skill_version: "1.2.0", 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.
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-brainstorming", skill_version: "1.4.0", 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.

package/skills/coder-brainstorming/builder-check-prompt.md

@@ -0,0 +1,23 @@
+# Builder Check Prompt
+
+Dispatch a fresh general-purpose subagent with this prompt once the written
+design exists. Fill in the domain and the document path.
+
+```
+You are a talented [DOMAIN, e.g. "software engineer", "event planner"].
+You've been handed a design document and asked to put together a plan to
+build what it describes. You will not be able to talk to the person who
+wrote it.
+
+Read [DOCUMENT_PATH].
+
+Report only the questions you'd still need answered before you could plan
+this well: places where you'd have to guess and a wrong guess would matter.
+For each, give the question and why the answer changes the plan. Rank them
+by importance.
+
+Skip anything the document explicitly leaves to the builder, and anything
+you could reasonably decide yourself. Skip nitpicks about wording.
+
+If nothing important is left, say "nothing important left".
+```

package/skills/coder-brainstorming/scripts/server.cjs

@@ -259,7 +259,7 @@ function isFullDocument(html) {
 }
 
 function wrapInFrame(content) {
-  return renderBranding(frameTemplate).replace('<!-- CONTENT -->', content);
+  return renderBranding(frameTemplate).replace('<!-- CONTENT -->', () => content);
 }
 
 function getNewestScreen() {

package/skills/coder-debugging/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog — luckiest-coder-debugging
 
+## 1.2.1 — 2026-10-16
+
+- Secret-presence example prints only SET or UNSET and never the value (from obra/superpowers at bb92a77 (v7.0.0, MIT)).
+
 ## 1.2.0 — 2026-09-22
 Practices adopted from BuilderOS, Compound Engineering, and firstmate.
 

package/skills/coder-debugging/SKILL.md

@@ -3,7 +3,7 @@ name: coder-debugging
 description: Use when hunting the root cause of any bug, test failure, crash, or unexpected behavior — before proposing or attempting a fix. Trigger phrases include "debug this", "why is this failing", "find the root cause", "this test is flaky", "the build broke", "it works sometimes", or "/luckiest-coder-debugging". Enforces a four-phase root-cause-first process (investigate, pattern-match, hypothesize, implement) and blocks symptom fixes.
 license: See ATTRIBUTION.md
 metadata:
-  version: "1.2.0"
+  version: "1.2.1"
   listing_id: luckiest-coder-debugging
   author: luckiest
 ---
@@ -95,11 +95,11 @@ You MUST complete each phase before proceeding to the next.
    ```bash
    # Layer 1: Workflow
    echo "=== Secrets available in workflow: ==="
-   echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
+   echo "IDENTITY: $([ -n "${IDENTITY:-}" ] && echo SET || echo UNSET)"
 
    # Layer 2: Build script
    echo "=== Env vars in build script: ==="
-   env | grep IDENTITY || echo "IDENTITY not in environment"
+   printenv IDENTITY >/dev/null 2>&1 && echo "IDENTITY in environment" || echo "IDENTITY not in environment"
 
    # Layer 3: Signing script
    echo "=== Keychain state: ==="
@@ -315,7 +315,7 @@ From debugging sessions:
 ## Staying current
 
 On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "5b9728f7-04b0-4be9-9962-3453d4a11d9a", installedSemver: "1.2.0" }`.
+`{ listingId: "5b9728f7-04b0-4be9-9962-3453d4a11d9a", installedSemver: "1.2.1" }`.
 If it returns `upToDate: false`, surface the `notice` to the user. Do nothing if `upToDate: true`.
 
-When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-debugging", skill_version: "1.2.0", 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.
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-debugging", skill_version: "1.2.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.

package/skills/coder-requesting-code-review/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog — luckiest-coder-requesting-code-review
 
+## 1.1.1 — 2026-10-16
+
+- BASE_SHA example uses `cut` instead of `awk` (from obra/superpowers at bb92a77 (v7.0.0, MIT)).
+
 ## 1.1.0 — 2026-07-06
 Skill updater pass: analytics integration.
 

package/skills/coder-requesting-code-review/SKILL.md

@@ -3,7 +3,7 @@ name: coder-requesting-code-review
 description: Use when you have finished a task, implemented a major feature, fixed a complex bug, or are about to merge to main and want a fresh reviewer to catch issues before they cascade. Trigger phrases include "review this before I merge", "get a code review", "check my changes", "is this ready to merge". Dispatches a reviewer subagent with crafted context (a git SHA range), not your session history.
 license: See ATTRIBUTION.md
 metadata:
-  version: "1.1.0"
+  version: "1.1.1"
   listing_id: luckiest-coder-requesting-code-review
   author: luckiest
 ---
@@ -59,7 +59,7 @@ Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md
 
 You: Let me request code review before proceeding.
 
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | cut -d' ' -f1)
 HEAD_SHA=$(git rev-parse HEAD)
 
 [Dispatch code reviewer subagent]
@@ -112,7 +112,7 @@ See template at: [code-reviewer.md](code-reviewer.md)
 ## Staying current
 
 On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "010a144f-99ed-4b6e-a43e-9ab51574c45b", installedSemver: "1.1.0" }`.
+`{ listingId: "010a144f-99ed-4b6e-a43e-9ab51574c45b", installedSemver: "1.1.1" }`.
 If it returns `upToDate: false`, surface the `notice` to the user. Do nothing if `upToDate: true`.
 
-When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-requesting-code-review", skill_version: "1.1.0", 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.
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-requesting-code-review", skill_version: "1.1.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.

package/skills/coder-subagent-driven-development/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog — luckiest-coder-subagent-driven-development
 
+## 1.2.1 — 2026-10-16
+
+- `sdd-workspace` writes its `.gitignore` only when none exists, so a repo's committed one is kept (from obra/superpowers at bb92a77 (v7.0.0, MIT)).
+
 ## 1.2.0 — 2026-09-22
 Practices adopted from BuilderOS, Compound Engineering, and firstmate.
 

package/skills/coder-subagent-driven-development/SKILL.md

@@ -3,7 +3,7 @@ name: coder-subagent-driven-development
 description: Use when executing an implementation plan of mostly-independent tasks in the current session — dispatches a fresh implementer subagent per task, a spec+quality review after each, and a broad whole-branch review at the end. Trigger on "execute this plan", "run the plan with subagents", "implement these tasks one by one", or after writing a plan when you want same-session execution with review gates rather than a parallel session.
 license: See ATTRIBUTION.md
 metadata:
-  version: "1.2.0"
+  version: "1.2.1"
   listing_id: luckiest-coder-subagent-driven-development
   author: luckiest
 ---
@@ -435,7 +435,7 @@ is unavailable.
 ## Staying current
 
 On activation, call the Luckiest MCP `check_updates` tool with
-`{ listingId: "7b994606-94cb-45a9-876d-1b5ecb856596", installedSemver: "1.2.0" }`.
+`{ listingId: "7b994606-94cb-45a9-876d-1b5ecb856596", installedSemver: "1.2.1" }`.
 If it returns `upToDate: false`, surface the `notice` to the user. Do nothing if `upToDate: true`.
 
-When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-subagent-driven-development", skill_version: "1.2.0", 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.
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-coder-subagent-driven-development", skill_version: "1.2.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.

package/skills/coder-subagent-driven-development/scripts/sdd-workspace

@@ -18,5 +18,7 @@ set -euo pipefail
 root=$(git rev-parse --show-toplevel)
 dir="$root/.luckiest-coder/sdd"
 mkdir -p "$dir"
-printf '*\n' > "$dir/.gitignore"
+# Create-only: a repo may commit its own .gitignore here; overwriting it would
+# revert that on every run.
+[ -e "$dir/.gitignore" ] || printf '*\n' > "$dir/.gitignore"
 cd "$dir" && pwd

package/skills/cold-email/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog — luckiest-cold-email
 
+## 1.3.0 — 2026-10-16
+From coreyhaines31/marketingskills at 1efedbc (issue #174, MIT).
+
+- New references: deliverability, LinkedIn outreach, multichannel cadence, outbound plays, reply handling. Sending setup (secondary domains, list verification, tracking off) folded into Deliverability; reply classification folded into Handling the Reply; new Beyond Email section.
+- Benchmarks: vendor-sourced ranges, reply rate ~3.4% average, drop open rate as a metric; personalization with AI section.
+- Two new evals. Skipped upstream's tools-registry table.
+
 ## 1.2.0 — 2026-10-08
 Upstream sync with coreyhaines31/marketingskills dda3841 (issue #112).