@orrisai/show-me-the-money 2.3.1 → 2.4.0

package/README.md

@@ -8,7 +8,7 @@
 [![Latest release](https://img.shields.io/github/v/release/iamzifei/show-me-the-money?label=release&color=green)](https://github.com/iamzifei/show-me-the-money/releases)
 [![License: CC BY-NC 4.0](https://img.shields.io/badge/license-CC%20BY--NC%204.0-orange.svg)](LICENSE)
 
-**Current version: `v2.3.1`** · [What's new →](#-whats-new-in-v231)
+**Current version: `v2.4.0`** · [What's new →](#-whats-new-in-v240)
 
 [English](README.md) | [中文](README.zh-CN.md)
 
@@ -51,6 +51,76 @@ Works with **Claude Code**, **Codex CLI**, **Gemini CLI**, and other agents that
 
 ---
 
+## ✨ What's New in v2.4.0
+
+**The "ship without nuking production" release.** Six things landed, all folded into existing skills — no new commands to remember, no skill-count explosion.
+
+### 1. Operating modes + edit perimeter + panic stop (in `/money-ops`)
+
+Autonomy without guardrails is how solo founders break production at 2am. The ops layer now declares an **operating mode** — `open` / `staging` / `production` — and every destructive command (rm -rf, force push, DROP TABLE, kubectl delete, bulk Stripe operations) requires a confirmation in the higher modes. Add an **edit perimeter** to lock a debugging session to one subtree, and call `/money-ops stop` to halt every scheduled agent and outreach loop instantly.
+
+```
+mode: production
+→ rm -rf production_users requires typing "yes-delete-production_users"
+→ npm publish requires explicit version confirmation
+→ Outreach batches > 10 recipients require explicit batch approval
+```
+
+### 2. Narrowest-bet pressure test (in `/money-discover`)
+
+The 6 forcing questions surface the smallest version someone would pay for. v2.4 adds a **Phase 4.5 pressure test** that forces the wedge to be **demonstrable tomorrow** — not "in 2-3 weeks of prep". Output is a one-line falsifiable bet: "By {date}, I will put {artifact} in front of {named buyer} to test {specific price} for {one thing it does}. If no signal by {date+7}, the wedge is wrong."
+
+This is the #1 reason solo founders end up at week 4 of "almost ready to show someone".
+
+### 3. Term-by-term audit + fuzzy-to-measurable (in `/money-strategy`)
+
+Layer 1 of the premise audit now runs a loop: spot every load-bearing fuzzy word in the pitch, probe it ("how would a stranger measure this?"), and convert it to a measurable substitute. Every goal becomes `<verb> <metric> <threshold> <by date>` before strategy starts.
+
+If the user can't convert their goals to measurable form, the strategy refuses to proceed and routes back to `/money-discover` Phase 4.5 first. No more strategizing on top of vague terms.
+
+### 4. Hook + title pattern library + Release-notes mode (in `/money-content`)
+
+Stage 4.8 adds a **pattern library** — 12 hook patterns and 15 title patterns indexed by reader state (scrolling / searching / decision-making) plus platform-specific patterns for XHS and WeChat. A title must satisfy BOTH a library pattern AND 2+ mechanisms from the existing impact matrix before shipping.
+
+Plus a new **Release-notes mode**: when `/money-product` ships a version, this mode generates three-tier release notes (one-line ship tweet, product email, full CHANGELOG entry + blog post). Release-note emails have the highest conversion rate of any content type — skipping them leaves free→paid upgrades on the table.
+
+### 5. Design system contract + ship lifecycle (in `/money-product`)
+
+A new **Phase 0** writes `DESIGN.md` to the project root before any UI code — aesthetic stance, type/color/spacing tokens, motion rules, AND the rejection list (what the system explicitly does NOT do). Solves the "portfolio of 4 products that all look unrelated" problem.
+
+A new **Phase 5.5 ship lifecycle** turns deployment into a 5-step protocol: VERSION bump (semver) → CHANGELOG entry → pre-deploy verification → deploy + tag → release-notes delivery. Skipping a step is what causes "production incidents" — every step has a refuse-if-missing gate.
+
+### 6. STRIDE threat model + Tech-triage mode (in `/money-quality`)
+
+The security audit now runs BOTH OWASP Top 10 AND a STRIDE pass (spoofing / tampering / repudiation / information disclosure / DoS / elevation-of-privilege) — catches the architectural assumptions that OWASP misses. 3+ STRIDE threats at P0/P1 means NOT ready to charge real money, regardless of OWASP score.
+
+New **Tech-triage mode** for when something is technically broken — failing test, slow query, mystery 500. A 5-step loop (restate → boundary → reproduce → hypothesize-then-test → fix + regression test + `/money-learn` row). Refuses to start guessing or grep before the symptom is restated precisely.
+
+### 7. Custom reviewer personas + architecture lens (in `/money-panel` + `/money-review-operator`)
+
+`/money-panel --add "Enterprise IT buyer: needs SOC2 before signing"` inserts a domain-expert reviewer into the gauntlet. Useful when the four built-in lenses (investor / customer / operator / skeptic) don't capture the specific reviewer your plan needs to survive — enterprise procurement, privacy lawyer, open-source maintainer, regulated-industry compliance.
+
+`/money-review-operator` gets a Q5: **Architecture & data-flow stress test** — five failure modes a solo operator can't escape from (hidden ops cost, data shape lock-in, single point of failure, cost-curve mismatch, debug accessibility). 2+ red flags here flips the verdict to NEEDS HIRE regardless of the other questions.
+
+### 8. Portfolio learnings — cross-project knowledge (in `/money-learn`)
+
+Learnings used to be project-local. v2.4 adds a **portfolio layer** at `~/.smtm/portfolio/learnings.jsonl` that auto-loads into EVERY money-* skill in EVERY project. Run `/money-learn promote <L-id>` to lift a validated, replicated, domain-general pattern from one project to the portfolio. Demote if it turns out to be context-specific.
+
+A solo operator running 6 products discovers patterns that apply to all of them ("Stripe webhook idempotency keys must be checked even when the API call is idempotent"). Those don't belong locked to one product — they belong in the operator's portfolio brain.
+
+### 9. Auto-update command (in `/money-upgrade`)
+
+`/money-upgrade` is now a true auto-updater. One command:
+- Checks npm for the latest version
+- Shows the delta + headline changes
+- Downloads + replaces installed skills
+- Reads the CHANGELOG and surfaces what's new
+- Prompts to restart Claude Code
+
+No more "version compare by hand" or "did I run install or update". One command, idempotent.
+
+---
+
 ## ✨ What's New in v2.3.1
 
 **Polish patch following the v2.3.0 atom launch.** Five things landed:
@@ -300,35 +370,35 @@ cd ~/.claude/skills/show-me-the-money && node install.js
 | **Save** | `/money-save` | Checkpoint the current business state to `~/.smtm/sessions/{project}/` |
 | **Restore** | `/money-restore` | Resume from a prior saved state — pick up exactly where the last session left off |
 | **Report** | `/money-report` | Merge all saved states into a deliverable markdown report |
-| **Learn** | `/money-learn` | Manage atomic project learnings (auto-loaded into every other skill) |
+| **Learn** | `/money-learn` | Manage atomic project learnings + portfolio learnings shared across every project |
 | **Skillify** | `/money-skillify` | Codify a successful workflow into a project-local reusable skill |
-| **Upgrade** | `/money-upgrade` | Update to the latest version |
+| **Upgrade** | `/money-upgrade` | Auto-update: checks npm, downloads, replaces, reads CHANGELOG, prompts to restart |
 
 ### Discover · Strategy · Diagnose · Review
 
 | Skill | Command | What It Does |
 |-------|---------|-------------|
-| **Discover** | `/money-discover` | Find and validate profitable business ideas with competitive intelligence |
-| **Strategy** | `/money-strategy` | Premise deconstruction + market research + business model stress test |
+| **Discover** | `/money-discover` | Find and validate profitable business ideas; ends with a tomorrow-shippable narrowest-bet statement |
+| **Strategy** | `/money-strategy` | Term-by-term clarity audit + fuzzy-to-measurable goals + market research + business model stress test |
 | **Diagnose** | `/money-diagnose` | Deep diagnosis when business is stuck — root cause, not symptoms (with Iron Law phase gate) |
-| **Panel** | `/money-panel` | Run all four reviewers, find agreement, surface only taste decisions |
+| **Panel** | `/money-panel` | Run all four reviewers (+ optional `--add` custom personas), find agreement, surface only taste decisions |
 | **Investor Review** | `/money-review-investor` | VC-mode review with funding viability verdict |
 | **Customer Review** | `/money-review-customer` | Named-ICP customer review with willingness-to-pay verdict |
-| **Operator Review** | `/money-review-operator` | Solo-founder execution feasibility review |
+| **Operator Review** | `/money-review-operator` | Solo-founder execution feasibility + architecture & data-flow stress test |
 | **Skeptic Review** | `/money-review-skeptic` | Devil's advocate red-team review |
 
 ### Build · Quality
 
 | Skill | Command | What It Does |
 |-------|---------|-------------|
-| **Product** | `/money-product` | Build, deploy, QA test, and monitor MVP |
-| **Quality** | `/money-quality` | Code review, security audit, performance check, pre-launch gates |
+| **Product** | `/money-product` | DESIGN.md design contract, build, ship lifecycle (VERSION + CHANGELOG + release notes), deploy, QA, canary |
+| **Quality** | `/money-quality` | Code review, OWASP + STRIDE security, performance, pre-launch gates, tech-triage debugging mode |
 
 ### Grow
 
 | Skill | Command | What It Does |
 |-------|---------|-------------|
-| **Content** | `/money-content` | Content pipeline with authenticity audit and headline impact matrix |
+| **Content** | `/money-content` | Content pipeline with authenticity audit, headline impact matrix, hook + title pattern library, release-notes mode |
 | **Outreach** | `/money-outreach` | Cold email sequences and partnership outreach |
 | **Social** | `/money-social` | Social media management with hook-writing frameworks |
 | **SEO** | `/money-seo` | SEO + GEO optimization for search engines and AI |
@@ -338,7 +408,7 @@ cd ~/.claude/skills/show-me-the-money && node install.js
 
 | Skill | Command | What It Does |
 |-------|---------|-------------|
-| **Ops** | `/money-ops` | 24/7 autonomous operations with health scoring and safety guardrails |
+| **Ops** | `/money-ops` | 24/7 autonomous operations, health scoring, operating modes (open/staging/production), edit perimeter, panic stop |
 | **Finance** | `/money-finance` | Revenue tracking and financial reports |
 | **Retro** | `/money-retro` | Weekly retrospective: decided / shipped / stalled / unused-skills / focus |
 

package/README.zh-CN.md

@@ -8,7 +8,7 @@
 [![Latest release](https://img.shields.io/github/v/release/iamzifei/show-me-the-money?label=release&color=green)](https://github.com/iamzifei/show-me-the-money/releases)
 [![License: CC BY-NC 4.0](https://img.shields.io/badge/license-CC%20BY--NC%204.0-orange.svg)](LICENSE)
 
-**当前版本：`v2.3.1`** · [更新内容 →](#-v231-更新内容)
+**当前版本：`v2.4.0`** · [更新内容 →](#-v240-更新内容)
 
 [English](README.md) | [中文](README.zh-CN.md)
 
@@ -51,6 +51,76 @@ Show Me The Money 是一套开源的 [Claude Code](https://claude.ai/code) 技
 
 ---
 
+## ✨ v2.4.0 更新内容
+
+**"自动化但不会把生产环境干爆"的一版。** 落地 9 项改进，**全部融进现有技能** —— 没有新命令要记、没有技能数量膨胀。
+
+### 1. 运行模式 + 编辑边界 + 紧急停止（`/money-ops`）
+
+自动化没有护栏，就是凌晨两点把生产环境炸了的快速通道。Ops 层现在声明一个**运行模式** —— `open` / `staging` / `production` —— 在更高级别的模式下，每一个破坏性命令（rm -rf、强制推送、DROP TABLE、kubectl delete、Stripe 批量操作）都需要明确确认。可以设置**编辑边界**把调试会话锁在一个子目录里；调 `/money-ops stop` 立刻停掉所有定时智能体和外展循环。
+
+```
+mode: production
+→ rm -rf production_users 需要输入 "yes-delete-production_users"
+→ npm publish 需要明确确认版本号
+→ 超过 10 个收件人的外展批次需要明确批量审批
+```
+
+### 2. 最窄一注压力测试（`/money-discover`）
+
+6 个强制问题已经找出"最小可付费的版本"。v2.4 加了一个 **Phase 4.5 压力测试**，逼迫这个最窄版本必须**明天就能展示** —— 不是"再准备 2-3 周"。输出是一句可证伪的赌注："到 {日期} 前，我会把 {一个工件} 摆到 {具名买家} 面前，测试他们是否愿意为 {一件事} 付 {具体价格}。如果到 {日期+7天} 还没信号，就是赌错了。"
+
+这是独立创业者卡在"差不多准备好可以给人看了"第 4 周最大的原因。
+
+### 3. 逐词审计 + 模糊转可测量（`/money-strategy`）
+
+前提审计 Layer 1 现在跑一个循环：找出 pitch 里每一个承重的模糊词，追问（"陌生人要怎么测量这句话？"），并把它转换成可测量的替代。每一个目标都要变成 `<动词> <指标> <阈值> <截止时间>` 才能进入正式策略。
+
+如果用户没法把目标转成可测量形式，策略环节会拒绝继续，直接回路到 `/money-discover` 的 Phase 4.5。不能在含糊措辞上面继续做策略。
+
+### 4. Hook + 标题模式库 + 发布说明模式（`/money-content`）
+
+Stage 4.8 新增了一个**模式库** —— 12 种 hook 模式 + 15 种标题模式，按读者状态（滑动中 / 搜索中 / 决策中）索引，外加针对 XHS 和微信的平台专属模式。一个标题必须**同时**命中库里的某个模式 **且** 触发现有冲击力矩阵里 2+ 个心理机制，才能放出。
+
+外加一个新的**发布说明模式**：当 `/money-product` 出版本时，自动生成三层发布说明（一行航班 tweet / 产品邮件 / 完整 CHANGELOG + 博客）。发布说明邮件是所有内容类型中转化率最高的 —— 不写就是白白漏掉免费→付费升级。
+
+### 5. 设计系统契约 + 出版生命周期（`/money-product`）
+
+新的 **Phase 0** 在写任何 UI 代码之前写 `DESIGN.md` —— 美学站位、字体/颜色/间距 token、动效规则，以及**拒绝清单**（这套系统明确**不做**什么）。解决"组合里 4 个产品看起来毫无亲缘关系"的问题。
+
+新的 **Phase 5.5 出版生命周期**把部署变成 5 步协议：版本号 bump（semver）→ CHANGELOG 条目 → 部署前验证 → 部署 + tag → 发布说明分发。跳过一步就是"生产事故"的成因 —— 每一步都有"缺失则拒绝"的门禁。
+
+### 6. STRIDE 威胁模型 + 技术分诊模式（`/money-quality`）
+
+安全审计现在跑 OWASP Top 10 **和** STRIDE（仿冒 / 篡改 / 抵赖 / 信息泄露 / 拒绝服务 / 提权）两遍 —— 抓住 OWASP 漏掉的架构性假设。3+ 个 STRIDE 威胁停在 P0/P1，意味着**不能**开始向真实用户收钱，跟 OWASP 分数无关。
+
+新的**技术分诊模式**面向技术层面坏了的场景 —— 测试挂、查询慢、神秘的 500。5 步循环（重述症状 → 找边界 → 复现 → 先假设再验证 → 修复 + 回归测试 + `/money-learn` 留痕）。在精确重述症状之前拒绝瞎猜、拒绝 grep 源码。
+
+### 7. 自定义评审角色 + 架构审视（`/money-panel` + `/money-review-operator`）
+
+`/money-panel --add "Enterprise IT buyer: 签合同前必须 SOC2"` 把一个领域专家评审塞进 gauntlet。当内置 4 个角度（投资人 / 客户 / 操盘手 / 怀疑论者）不足以覆盖你的方案需要的特定视角时用 —— 企业采购、隐私律师、开源维护者、受监管行业合规。
+
+`/money-review-operator` 加了 Q5：**架构与数据流压力测试** —— 独立操盘手逃不掉的 5 种失败模式（隐藏运营成本、数据形状锁定、单点故障、成本曲线错配、调试可达性）。2+ 项红灯就把判决拉到 NEEDS HIRE，无视其他问题的得分。
+
+### 8. 组合学习 —— 跨项目知识沉淀（`/money-learn`）
+
+Learnings 之前只能项目内本地。v2.4 加了一个**组合层** `~/.smtm/portfolio/learnings.jsonl`，自动加载到**每个项目**的**每个 money-* 技能**里。跑 `/money-learn promote <L-id>` 把一条已验证、已复现、领域通用的项目级 pattern 提到组合层。如果发现它只在原来的项目里成立，可以降级。
+
+跑 6 个产品的独立操盘手会发现一些放之四海皆准的 pattern（"Stripe webhook idempotency key 必须显式检查，即使 API 本身幂等"）。这些不该锁在单一产品里 —— 它们属于操盘手的"组合大脑"。
+
+### 9. 自动更新命令（`/money-upgrade`）
+
+`/money-upgrade` 现在是真正的自动更新器。一条命令：
+- 查询 npm 上的最新版本
+- 显示版本差 + 重点变更
+- 下载 + 替换已安装的技能
+- 读 CHANGELOG 摘要更新内容
+- 提示重启 Claude Code
+
+不再"手动比对版本号"或"我应该跑 install 还是 update"。一条命令，幂等。
+
+---
+
 ## ✨ v2.3.1 更新内容
 
 **v2.3.0 原子发布之后的打磨补丁。** 落地 5 件事：
@@ -301,35 +371,35 @@ cd ~/.claude/skills/show-me-the-money && node install.js
 | **保存** | `/money-save` | 把当前业务状态检查点写入 `~/.smtm/sessions/{project}/` |
 | **恢复** | `/money-restore` | 从先前的检查点续接，无需重新解释 |
 | **报告** | `/money-report` | 把所有保存的状态合并成可交付的 markdown 报告 |
-| **学习** | `/money-learn` | 管理项目级原子学习（自动注入每个其他技能） |
+| **学习** | `/money-learn` | 管理项目级原子学习 + 跨项目共享的组合学习层 |
 | **固化技能** | `/money-skillify` | 把一段成功的工作流固化为项目级可复用技能 |
-| **升级** | `/money-upgrade` | 更新到最新版本 |
+| **升级** | `/money-upgrade` | 自动更新：查 npm、下载、替换、读 CHANGELOG、提示重启 |
 
 ### 发现 · 策略 · 诊断 · 评审
 
 | 技能 | 命令 | 功能 |
 |------|------|------|
-| **发现** | `/money-discover` | 发现并验证盈利商机 + 竞品情报 |
-| **策略** | `/money-strategy` | 前提解构 + 市场研究 + 商业模式压力测试 |
+| **发现** | `/money-discover` | 发现并验证盈利商机 + 竞品情报；末尾给出明天就能展示的"最窄一注"赌注 |
+| **策略** | `/money-strategy` | 逐词清晰度审计 + 模糊转可测量目标 + 市场研究 + 商业模式压力测试 |
 | **诊断** | `/money-diagnose` | 业务卡住时找根因，不是症状（带 Iron Law 阶段门） |
-| **评审委员会** | `/money-panel` | 4 个评审一起跑，只把品味分歧抛给你 |
+| **评审委员会** | `/money-panel` | 4 个评审一起跑（+ 可选 `--add` 自定义角色），只把品味分歧抛给你 |
 | **投资人评审** | `/money-review-investor` | VC 视角的融资可行性评判 |
 | **客户评审** | `/money-review-customer` | 指定 ICP 视角的付费意愿评判 |
-| **操盘手评审** | `/money-review-operator` | 独立创始人执行可行性评判 |
+| **操盘手评审** | `/money-review-operator` | 独立创始人执行可行性 + 架构与数据流压力测试 |
 | **质疑者评审** | `/money-review-skeptic` | 红队式质疑评审 |
 
 ### 构建 · 质量
 
 | 技能 | 命令 | 功能 |
 |------|------|------|
-| **产品** | `/money-product` | 构建、部署、QA、监控 MVP |
-| **质量** | `/money-quality` | 代码审查、安全审计、性能检查、上线前门禁 |
+| **产品** | `/money-product` | DESIGN.md 设计契约、构建、出版生命周期（VERSION + CHANGELOG + 发布说明）、部署、QA、金丝雀 |
+| **质量** | `/money-quality` | 代码审查、OWASP + STRIDE 安全、性能、上线前门禁、技术分诊调试模式 |
 
 ### 增长
 
 | 技能 | 命令 | 功能 |
 |------|------|------|
-| **内容** | `/money-content` | 内容管线 + 真实性审计 + 标题影响力矩阵 |
+| **内容** | `/money-content` | 内容管线 + 真实性审计 + 标题影响力矩阵 + Hook & 标题模式库 + 发布说明模式 |
 | **外展** | `/money-outreach` | 冷邮件序列、合作伙伴拓展 |
 | **社交** | `/money-social` | 社交媒体管理 + Hook 写作框架 |
 | **SEO** | `/money-seo` | SEO + GEO 优化（含 AI 搜索） |
@@ -339,7 +409,7 @@ cd ~/.claude/skills/show-me-the-money && node install.js
 
 | 技能 | 命令 | 功能 |
 |------|------|------|
-| **运营** | `/money-ops` | 全天候运营 + 健康评分 + 安全护栏 |
+| **运营** | `/money-ops` | 全天候运营 + 健康评分 + 运行模式（open/staging/production）+ 编辑边界 + 紧急停止 |
 | **财务** | `/money-finance` | 收入追踪、财务报告 |
 | **复盘** | `/money-retro` | 周复盘：决定 / 出货 / 卡住 / 未用技能 / 焦点 |
 

package/VERSION

@@ -1 +1 @@
-2.3.1
+2.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orrisai/show-me-the-money",
-  "version": "2.3.1",
+  "version": "2.4.0",
   "description": "AI agent skills that build and run your business autonomously — from idea to revenue, 24/7. Works with Claude Code, Codex CLI, and Gemini CLI.",
   "keywords": [
     "ai-agent",

package/skills/money-content/SKILL.md

@@ -30,6 +30,7 @@ Ranked by revenue impact:
 5. **Documentation** — Reduce churn, improve activation
 6. **Case studies** — Social proof for sales
 7. **Video scripts** — YouTube/TikTok/short-form content
+8. **Release notes** — Convert existing users on every ship (see "Release-notes mode" below)
 
 ## Pipeline: Research → Write → Diagnose → Optimize → Publish
 
@@ -209,11 +210,130 @@ Before finalizing any title/headline, evaluate it against these psychological me
 - [ ] Uses concrete nouns and verbs, not abstract concepts
 - [ ] Creates a question in the reader's mind that can only be answered by reading
 
+### Stage 4.8: Hook & Title Pattern Library
+
+After the hook and headline checks pass, run the candidate against the curated pattern library. The mechanisms matrix tells you WHY a headline works; the pattern library gives you proven SHAPES that have already worked in the wild. Use both — patterns without mechanisms are templates; mechanisms without patterns are theory.
+
+#### Hook patterns (short-form video and social opening)
+
+12 patterns, each indexed by the situation it fits. Match the candidate hook to the closest pattern. If no pattern fits, the hook may need more work — or it may be a new shape worth saving (run `/money-learn add` to log it).
+
+| Pattern | Skeleton | Best for | Example |
+|---|---|---|---|
+| **Result-first reversal** | "I {achieved X}. The way I got there was {opposite of expected}." | Big result + counterintuitive path | "I hit $10K MRR in 6 weeks. I never wrote a single blog post." |
+| **Single-number anchor** | "{Specific number}. {What the number means}." | Data-heavy stories | "$4,327. That's what one customer paid me last week — and I never spoke to them." |
+| **The thing nobody admits** | "Nobody talks about this, but {industry truth}." | Insider takes | "Nobody talks about this, but the top SEO tools all share the same database." |
+| **Yesterday's failure** | "Yesterday I {specific failure}. Here's what I'm changing." | Personal authenticity | "Yesterday I lost a $5K deal because I demoed before qualifying. Here's the new opener." |
+| **N years, one lesson** | "I spent {N} years doing X. Here's the one thing I'd tell my younger self." | Authority + lesson | "I spent 8 years writing code in big tech. The one thing I'd tell my younger self: stop optimizing the wrong loop." |
+| **Setup → flip** | "Everyone says {X}. But {X} is actually {opposite}." | Contrarian takes | "Everyone says raise prices. But for our segment, raising prices killed conversions." |
+| **Watch what happens** | "{Specific action}. {What happened next}." | Story-driven | "I changed one word in our checkout copy. Conversion went from 3.1% to 4.8%." |
+| **The question they're afraid to ask** | "Should you {decision}? Most people are afraid to ask. Here's the honest answer." | Decision content | "Should you quit your day job to ship your side project? Here's the honest math." |
+| **Two roads** | "Two roads. {Road A leads to result Y}. {Road B leads to result Z}. Pick one." | Decision content | "Two roads. Stay in cold outreach and grind. Or wait 9 months for SEO. Pick one." |
+| **The price of {X}** | "The price of {decision/inaction} is {specific cost}." | Loss-aversion | "The price of waiting one more quarter to charge for your beta is roughly $14,000 in lost revenue." |
+| **Reverse credentials** | "I'm not a {expected authority}. But {what I know that they don't}." | Outsider authority | "I'm not a VC. But I've sold three startups for $20M+ each by ignoring everything VCs told me." |
+| **The receipt** | "{Bold claim}. Receipts: {specific evidence}." | Proof-driven | "Cold email still works in 2026. Receipts: 47 booked meetings last quarter, $186K closed." |
+
+#### Title patterns (blog posts, X threads, XHS posts)
+
+15 patterns organized by what the reader is doing the moment they encounter the title:
+
+**For scrollers (need to be stopped):**
+| Pattern | Skeleton | Example |
+|---|---|---|
+| Number + specific noun | "{Specific number} {specific things} that {specific outcome}" | "7 onboarding emails that doubled our trial-to-paid conversion" |
+| Time-bound result | "From {start state} to {end state} in {timeframe}" | "From $0 to $10K MRR in 90 days (with screenshots)" |
+| Anti-advice | "Why I stopped {common practice}" | "Why I stopped using TypeScript on solo projects" |
+| The cost of habit | "What {common thing} is really costing you" | "What your free tier is really costing you" |
+
+**For searchers (already typed a query):**
+| Pattern | Skeleton | Example |
+|---|---|---|
+| Definitional + use | "{Topic}, explained for {specific audience}" | "RAG, explained for backend engineers who already know caching" |
+| Comparison | "{A} vs {B}: which one for {specific use case}" | "Postgres vs DynamoDB: which one for a 2-person SaaS" |
+| Decision framework | "How to choose {thing} (the {N}-question test)" | "How to choose a payment processor (the 5-question test)" |
+| Step-by-step | "{Verb} {outcome} in {N} steps" | "Set up Stripe webhooks for subscriptions in 4 steps" |
+
+**For decision-makers (need a confident take):**
+| Pattern | Skeleton | Example |
+|---|---|---|
+| Strong opinion | "{Industry truth} is wrong. Here's why." | "The 'launch on Product Hunt' playbook is wrong. Here's what I'd do instead." |
+| Receipts post | "I {tried/did X}. Here's what happened (with numbers)." | "I switched from Vercel to Cloudflare. Here's what happened (with numbers)." |
+| Insider take | "What {role} actually look at when {decision}" | "What technical founders actually look at when picking a CRM" |
+| Pattern naming | "The {memorable name} trap" | "The 'one more feature' trap (and how to spot it in week 2)" |
+
+**For platform-specific situations:**
+| Pattern | Skeleton | Best on |
+|---|---|---|
+| 我 + 数字 + 反差 | "我 {做了什么} 之后，{反直觉结果}" | XHS (中文) |
+| 别再 + 行为 | "别再 {主流做法} 了" | XHS, WeChat |
+| 一句话点破 | "{一个反直觉判断}" | X thread opener, XHS |
+
+#### Pattern + Mechanism = Final Title
+
+A strong final title satisfies BOTH:
+- One pattern from the library (proven shape)
+- Two+ mechanisms from the impact matrix at Stage 4.7 (psychological pull)
+
+Output for every candidate title:
+
+| Candidate | Pattern | Mechanisms | Status |
+|---|---|---|---|
+| "Why I stopped using TypeScript on solo projects" | Anti-advice | Cognitive dissonance, Social identity | ✅ Ship |
+| "5 things to consider when choosing TypeScript" | (no clean pattern match) | Information gap (weak) | ❌ Rewrite |
+| "TypeScript on solo projects: a 6-month receipt" | Receipts post | Specificity, Authority contrast | ✅ Ship |
+
 ### Stage 5: Publishing
 - Format content for the target platform
 - Schedule posts using the content calendar
 - Set up tracking (UTM parameters, conversion goals)
 
+## Release-Notes Mode
+
+When a new product version ships, release notes are content with the highest conversion rate in the entire pipeline — every existing user reads them, and well-written ones move ≥1% of free users to paid on every ship. Run this mode when called via `/money-content release-notes` or when `/money-product` ships a version.
+
+### Inputs (auto-fetched)
+
+- **VERSION** — current and previous version from the repo
+- **CHANGELOG.md** — raw commit/PR titles between the two versions
+- **The deploy log** — from `/money-product` (what shipped, what got fixed)
+- **Recent learnings** — `~/.smtm/projects/{slug}/learnings.jsonl`, filtered to `conversion` and `retention`
+
+### The three-tier output
+
+Generate three release-note variants from the same input, because different distribution channels need different lengths.
+
+#### Tier 1 — The one-line ship tweet (X, in-app banner)
+- ≤180 chars including emoji
+- Lead with the one user benefit (not the feature)
+- Include the version: "v2.4.0"
+
+> Example: "v2.4.0 → Stripe webhooks now auto-retry on 5xx. No more silently-lost payments at 2am. 🛡"
+
+#### Tier 2 — The product email (existing customers)
+- Subject line: written using a pattern from the library (typically "Time-bound result" or "Anti-advice")
+- 80-150 words
+- Opening sentence: the user benefit, in user language
+- Middle: 2-3 bullets of what changed (mapped to user pain, not feature)
+- Closing: ONE call-to-action — upgrade path, docs link, or a question that prompts reply
+
+#### Tier 3 — The full notes (CHANGELOG.md entry + blog post)
+- 300-500 words
+- Sections: "What's new" (benefit-first), "What we fixed" (one line per fix), "What we learned" (the story of why this ship matters)
+- For SaaS: ALWAYS include the upgrade prompt for free users in the "What's new" section, framed as access not pressure
+
+### The "should we name this version?" check
+
+Major versions deserve names (gives the marketing surface area). Minor patches don't. Use this filter:
+
+| If the ship includes... | Then... |
+|---|---|
+| A new core feature (not just an improvement) | Name it. The name becomes the marketing handle for 2-4 weeks. |
+| Breaking changes to API or UI | Name it AND publish a migration note. |
+| 3+ small but related fixes that improve a single user journey | Optional name. Worth a short post regardless. |
+| Pure infra / refactor / dependency bump | Don't name. Single line in CHANGELOG. Don't email. |
+
+Names should be one or two words, lowercase if technical (`fastpath`), titlecase if product-facing (`Quiet Mode`). Avoid trendy adjectives — they age fast.
+
 ## Content-to-Format Matching
 
 Match content type to the optimal format based on topic:

package/skills/money-discover/SKILL.md

@@ -125,6 +125,27 @@ This reveals UX assumptions and real-world friction.
 
 Avoid ideas that ride temporary hype. Look for compounding value — network effects, data moats, switching costs.
 
+## Phase 4.5: Narrowest-Bet Pressure Test
+
+Q4 surfaced the smallest version someone would pay for. Before moving to strategy, prove that version is **demonstrable tomorrow**, not "in 2-3 weeks of prep". Most stuck founders skip this and end up at week 4 of "almost ready to show someone".
+
+Force the founder to answer all four below. If any answer slides past tomorrow, the wedge is still too wide — narrow until it fits.
+
+| Pressure point | Forcing question | Pass if |
+|---|---|---|
+| **Demo-able tomorrow** | What's the smallest artifact you could put in front of a real prospect within 24 hours? | A wireframe + Stripe payment link, a 60-second Loom of a no-code prototype, or a manual-fulfillment offer page |
+| **One thing it does** | If you had to remove every feature except one, which one stays? | A single sentence answer. If the answer has "and" in it, it's two features |
+| **One named buyer** | Which specific human — by name, role, or company type — would you DM tonight to test this? | First name + how you'd reach them within 24h |
+| **One-week kill-switch** | If you can't get a single paying signal in 7 days, what does that prove? | A specific falsifiable read, not "I'll know it when I see it" |
+
+If all four pass: the wedge is demonstrable. Move on. If any one fails: keep cutting — the wedge is still hiding behind preparation work.
+
+Output a one-line **narrowest-bet statement** in the format:
+
+> "By **{tomorrow's date}**, I will put **{one demo artifact}** in front of **{one named buyer}** to test whether they'll pay **{specific price}** for **{the one thing it does}**. If no signal by **{date + 7 days}**, the wedge is wrong."
+
+This sentence is the strategy team's anchor for everything that follows. Every later decision either supports or contradicts this bet.
+
 ## Phase 5: Deep Dive & Competitive Intelligence
 
 After validation, run a rigorous competitive analysis. The goal is NOT to "understand the market" — it's to find ONE benchmark worth studying in detail and map the exact path to replicate their success.

package/skills/money-learn/SKILL.md

@@ -43,6 +43,10 @@ These are atomic patterns. Each gets one row in `learnings.jsonl`. They're auto-
 | `/money-learn list <project>` | List learnings for another project |
 | `/money-learn prune` | Interactive: review old/contradicted learnings, mark as superseded or remove |
 | `/money-learn export` | Output all learnings as a markdown table |
+| `/money-learn promote <L-id>` | Promote a project-local learning to the portfolio layer (see below) |
+| `/money-learn portfolio` | Show portfolio-wide learnings shared across every project |
+| `/money-learn portfolio search <query>` | Search portfolio-wide learnings |
+| `/money-learn portfolio demote <L-id>` | Move a portfolio learning back to a single project (if it turned out to be context-specific) |
 
 **Natural-language equivalents**:
 - "Remember this", "Log this learning", "This is a pattern worth keeping"
@@ -125,6 +129,61 @@ This is how the library stays signal-dense.
 
 ---
 
+## Portfolio learnings (cross-project sharing)
+
+A solo operator running multiple products discovers patterns that apply across all of them — not just to one. Examples:
+
+- "$39 converts better than $29" probably only applies to one product's ICP. **Project-local.**
+- "Cold email subject lines that name a specific revenue number outperform benefit-based subjects 4:1" applies to every cold-outreach campaign. **Portfolio-wide.**
+- "Stripe webhook idempotency keys MUST be checked even when the underlying API call is idempotent" applies to every Stripe integration. **Portfolio-wide.**
+
+The portfolio layer captures the second kind. Stored at `~/.smtm/portfolio/learnings.jsonl` (the same schema as project-local), it auto-loads into EVERY money-* skill in EVERY project, before the project-local learnings are loaded.
+
+### Promotion criteria
+
+A project-local learning should be promoted to the portfolio when ALL of:
+
+1. **Validated** confidence — emerging or hypothesis don't qualify
+2. **Replicated** — observed in at least 2 different projects (or the founder believes it would apply to any future project of the same shape)
+3. **Domain-general** — describes a tactic, channel, tool behavior, or operator pattern; NOT a specific ICP, price point, or product-specific finding
+
+Run `/money-learn promote <L-id>` to move a project learning to the portfolio. The skill confirms by re-reading the learning aloud, asks if it really generalizes, and writes to the portfolio file. The original project learning stays in place with a `promoted_to_portfolio: true` flag — so a future audit can trace where it originated.
+
+### Load order
+
+When a money-* skill starts up, learnings are merged in this order (later sources override earlier ones for the same pattern):
+
+1. Atom corpus (read-only, ships with the package)
+2. Portfolio learnings (`~/.smtm/portfolio/learnings.jsonl`)
+3. Project learnings (`~/.smtm/projects/{slug}/learnings.jsonl`)
+
+A project-specific finding always trumps a portfolio finding for that project — but the portfolio pattern is loaded for context. The agent surfaces both, marking the source:
+
+> 📚 Loaded 6 relevant patterns (4 portfolio, 2 project-local). Notably:
+> - L-port-3a8f (portfolio, validated, channel): "Subject lines with specific revenue numbers outperform benefit-based 4:1 across cold-email campaigns"
+> - L-a7k2 (project, validated, pricing): "$39 converts 30% better than $29 in our ICP"
+
+### Demotion
+
+If a learning turns out to be context-specific after all (e.g., the portfolio learning fails to replicate in a new project), demote it:
+
+```
+/money-learn portfolio demote L-port-3a8f --back-to <project-slug>
+```
+
+This moves the row back to a project-local file and removes it from portfolio auto-loading. The provenance is preserved — the row keeps a `was_portfolio: true` flag.
+
+### When NOT to promote
+
+Resist promoting learnings that feel general but aren't:
+
+- Pricing observations: almost always ICP-specific
+- "Channel X works" — works for what offer? Resist generalization
+- Tool preferences: founder's taste, not portfolio truth
+- One-off wins: a single replication does not equal portfolio-grade
+
+Rule of thumb: if you're about to start a new product, would the learning legitimately apply on day 1? If yes → promote. If you'd want to re-validate first → leave project-local.
+
 ## Auto-loading into other skills
 
 Every other `money-*` skill that does substantive work should load recent learnings before generating output. The standard pattern (added to those skills' preambles):

package/skills/money-ops/SKILL.md

@@ -210,16 +210,75 @@ When a critical alert fires:
 4. **Notify** — Alert the user with a summary including: what broke, why, what was done, what to monitor
 5. **Review** — Root cause analysis and prevention. Document in a post-mortem: timeline, impact, root cause, fix, prevention
 
+## Operating Mode Switches
+
+Autonomy without guardrails is how solo founders nuke production at 2am. Before doing destructive work, declare the **operating mode** the session is running in. Every skill that touches money, customer data, or live systems reads this setting and adjusts behavior.
+
+### The three modes
+
+| Mode | When to use | What changes |
+|---|---|---|
+| **`open`** | Local dev, prototypes, throwaway repos | No prompts. Anything goes. Default for greenfield work. |
+| **`staging`** | Pre-production work, customer-zero environments, anything where a screwup costs ≤1 hour to recover | Destructive commands require one confirmation. Edit perimeter optional. |
+| **`production`** | Live customer-facing systems, anything touching payments, real customer email blasts | Destructive commands require typed confirmation. Edit perimeter strictly enforced. Multi-customer outreach capped at 10 recipients without explicit batch approval. |
+
+Set the mode at the top of the session: `mode: production` in the user's first message, in a CLAUDE.md, or via `/money-ops set-mode production`. The mode persists for the conversation.
+
+### Destructive command gate
+
+In `staging` or `production` mode, the following commands MUST surface a one-line "about to run X — confirm?" before execution:
+
+- `rm -rf` of anything outside `/tmp` or `node_modules`
+- `git push --force`, `git reset --hard`, `git checkout -- .`, `git branch -D`
+- `DROP`, `TRUNCATE`, `DELETE` SQL without a narrow `WHERE`
+- `kubectl delete`, `terraform destroy`, `wrangler delete`
+- `vercel rm`, `supabase db reset`, `stripe products archive` (bulk)
+- Cron / `/schedule` deletions in bulk
+- Any `npm publish`, `gh release create`, or `git tag` that targets a published version
+
+The confirmation prompt restates the exact target and the blast radius. "About to delete the `prod_subscribers` table (47,318 rows). Confirm with 'yes-delete-prod_subscribers' to proceed."
+
+In `production` mode the confirmation MUST be the exact target string typed back — not a generic "yes". This is the single biggest reduction in fat-finger incidents per session.
+
+### Edit perimeter
+
+For complex debugging sessions where a side-fix in an unrelated file would create noise, the user may set an **edit perimeter** — a directory the session is allowed to modify. Edits outside the perimeter are refused with a one-line "outside perimeter: `<path>`. Set a wider perimeter or remove the constraint."
+
+| Command | Effect |
+|---|---|
+| `/money-ops perimeter <path>` | Lock edits to that subtree |
+| `/money-ops perimeter` (no arg) | Show current perimeter |
+| `/money-ops perimeter clear` | Remove the perimeter |
+
+The perimeter is session-scoped, not persistent — a new conversation starts with no perimeter.
+
+### Panic stop
+
+If something is going wrong and the user wants every autonomous behavior to halt immediately, the panic command stops all scheduled agents, all `/loop` runs, and all in-flight outreach batches owned by this project:
+
+```
+/money-ops stop
+```
+
+It does NOT roll back anything that already shipped — that's `/money-product` rollback territory. It just stops the next cycle from firing. Use this when:
+- An outreach sequence is hitting the wrong segment
+- A scheduled deployment is being canary-flagged repeatedly
+- Stripe webhooks are erroring in a loop and creating noise
+- The user is just done for the day and wants everything quiet
+
+After a panic stop, `/money-ops resume` brings scheduled agents back online — but only after the user types `resume` explicitly. No accidental restarts.
+
 ## Setup Wizard
 
 When the user types `/money-ops` for the first time:
 
 1. **Audit current state** — What skills have been run? What's already set up?
 2. **Select operations** — Which operations does the user want automated?
-3. **Configure schedule** — Set timezone and preferred hours
-4. **Set up monitoring** — Configure health checks and alert channels
-5. **Test run** — Execute each operation once to verify it works
-6. **Activate** — Start the autonomous schedule
+3. **Pick operating mode** — `open` / `staging` / `production` (see above)
+4. **Configure schedule** — Set timezone and preferred hours
+5. **Set up monitoring** — Configure health checks and alert channels
+6. **Test run** — Execute each operation once to verify it works
+7. **Activate** — Start the autonomous schedule
 
 ## Provisioned Infrastructure
 

package/skills/money-panel/SKILL.md

@@ -29,6 +29,8 @@ Output: ONE final verdict with the disagreements explicitly named, plus a punch
 | `/money-panel <path-to-plan.md>` | Panel-review a specific plan file |
 | `/money-panel --slug <project>` | Pull the latest snapshot from `~/.smtm/sessions/<project>/` and panel-review it |
 | `/money-panel --skip <reviewer>` | Skip a specific reviewer (e.g., `--skip skeptic`). Use sparingly — the whole point is the four-angle gauntlet |
+| `/money-panel --add <persona>` | Add a custom reviewer persona to the gauntlet (see "Custom personas" below) |
+| `/money-panel --only <persona>[,<persona>...]` | Run only the named reviewers. Useful when re-running after a fix to a specific dimension |
 
 **Natural-language equivalents**:
 - "Panel review", "Run all reviews", "Review gauntlet", "Stress test this plan"
@@ -194,6 +196,47 @@ Based on the verdict:
 
 ---
 
+## Custom personas (`--add` flag)
+
+The four built-in reviewers cover business viability. Some plans need additional lenses — an enterprise procurement buyer, a hardware-supply expert, a privacy lawyer, a community manager, an open-source maintainer. Use `--add` to insert a domain expert into the gauntlet without changing the four core reviewers.
+
+### Syntax
+
+```
+/money-panel --add "<role>: <one-sentence brief>"
+```
+
+Example:
+
+```
+/money-panel --add "Enterprise IT buyer: I need SOC2, SSO, and DPA before signing"
+/money-panel --add "Open-source maintainer: I'm wary of vendoring this dependency"
+```
+
+### How a custom persona is run
+
+For each `--add` persona, run a mini-review with this structure:
+
+1. **Role context**: Restate the persona as a one-paragraph self-introduction. Include incentives — what they're rewarded for, what they're punished for, what their day actually looks like.
+2. **Three questions**: Generate three questions ONLY that persona would ask of this plan. Not generic — questions that only make sense from that role.
+3. **Verdict in their language**: Output a verdict using the persona's own framing (an enterprise buyer doesn't say "shippable", they say "would I expense this through procurement").
+4. **The one thing the user is missing**: One sentence — the single thing the plan doesn't address that this persona considers a blocker.
+
+The custom persona's verdict joins the matrix but doesn't count toward the 12-point score. It surfaces as a separate "additional perspectives" section. Use it for stress-testing, not gating.
+
+### Common custom personas worth adding
+
+| Plan type | Custom personas worth adding |
+|---|---|
+| Enterprise SaaS | "Enterprise IT buyer", "Compliance officer", "Procurement lead" |
+| Consumer app | "Casual user with no patience", "Privacy-conscious user", "Power user who customizes everything" |
+| Developer tool | "Senior engineer evaluating dependencies", "Open-source maintainer", "Platform-team lead at a 50-person company" |
+| Marketplace | "Two-sided market expert", "Liquidity-first investor" |
+| Hardware / supply chain | "Operations / fulfillment lead", "Manufacturing partner" |
+| Regulated industry | "Domain-specific lawyer (healthcare / finance / education)" |
+
+For each plan type, the default `--add` set is roughly two extra personas. More than two adds noise; one rarely catches enough.
+
 ## After the panel
 
 If 🟢 or 🟡: hard-recommend `/money-save` to lock the verdict. Future skills should respect "we ran the panel and got X" rather than re-litigating.

package/skills/money-product/SKILL.md

@@ -38,6 +38,53 @@ Accept one of:
 
 The user only needs to confirm choices and provide any API keys or credentials they want to use.
 
+## Phase 0: Design System Contract
+
+Before writing any UI code, write `DESIGN.md` at the project root. This is the source-of-truth for every visual decision and prevents the most common solo-founder failure: a portfolio of 4 products that all look unrelated because each was built from a different starter template at a different time.
+
+If a `DESIGN.md` already exists in the repo, **read it and follow it** — don't re-derive choices the user already locked in. If one doesn't exist, generate one and ask the user to confirm before building.
+
+### `DESIGN.md` skeleton
+
+```markdown
+# Design System — {product name}
+
+## Aesthetic stance
+One sentence on the visual feel (e.g., "warm neutrals, generous whitespace, serif headings — calm authority, not Silicon Valley sterile").
+
+## Type
+- Heading: {font, weight, sizes for h1/h2/h3}
+- Body: {font, weight, line-height, max-width}
+- Mono: {font, when to use}
+
+## Color
+- Surface: {hex} — page background
+- Surface alt: {hex} — cards, raised areas
+- Text: {hex primary} / {hex muted}
+- Accent: {hex} — single accent, used sparingly
+- Success / warning / danger: {hex / hex / hex}
+
+## Spacing
+- Base unit: {N}px
+- Section vertical rhythm: {value}
+- Card padding: {value}
+
+## Motion
+- Default transition: {duration / easing}
+- What animates and what doesn't (rule, not list)
+
+## What this system rejects
+3-5 bullet points of "we don't do X" — gradients, glassmorphism, neon, etc. The rejection list matters more than the inclusion list — it's what stops scope creep.
+```
+
+Three rules for the design system:
+
+1. **One accent color.** Multiple accents read as "no point of view".
+2. **Type hierarchy uses size + weight only**, not color. Colored headings age badly.
+3. **Reject list is mandatory.** If `DESIGN.md` has no "what this system rejects" section, every contributor (including you in 3 months) will drift toward whatever's trendy that week.
+
+After writing `DESIGN.md`, every UI choice in this skill — buttons, cards, hero layouts, pricing tables — must trace back to a line in the file. If something doesn't fit, update `DESIGN.md` first, then build.
+
 ## Phase 1: Architecture Decision
 
 Based on the product type, select the optimal stack:
@@ -168,6 +215,70 @@ After deployment, verify:
 - [ ] Mobile experience is smooth
 - [ ] Schema markup validates (schema.org validator)
 
+## Phase 5.5: Ship Lifecycle
+
+Shipping isn't `vercel deploy`. It's a five-step lifecycle that turns a working build into a version users can be told about. Run every step, in order, every time. Most "production incidents" happen because a step was skipped.
+
+### Step 1 — Version bump
+
+Read `VERSION` (create as `0.1.0` if missing). Bump using semver:
+
+| Change | Bump |
+|---|---|
+| Backwards-compatible patch, internal refactor, fix | patch (`x.y.Z`) |
+| New user-facing feature, additive API | minor (`x.Y.0`) |
+| Breaking change to API, URL, or data model | major (`X.0.0`) |
+
+Write the new version to `VERSION` and commit it as part of the ship — never separately.
+
+### Step 2 — CHANGELOG entry
+
+Append (don't overwrite) a new entry to `CHANGELOG.md` at the top, under the new version header. Pull commit titles since the previous tag and group them:
+
+```markdown
+## v2.4.0 — 2026-05-11
+
+### Added
+- {short user-facing description of additions}
+
+### Fixed
+- {short description of fixes}
+
+### Changed
+- {short description of changes}
+```
+
+If a commit can't be grouped into Added/Fixed/Changed, it probably shouldn't ship in a public release — fold it into the next one.
+
+### Step 3 — Pre-deploy verification
+
+Run, in order, and refuse to proceed if any step fails:
+
+- [ ] `/money-quality` standard check (or ship check if charging real money)
+- [ ] All tests pass locally and in CI
+- [ ] `VERSION` and `CHANGELOG.md` updated, committed
+- [ ] No secrets or `.env` files in the diff
+- [ ] If schema changed: migration written AND tested against a copy of production
+- [ ] If pricing or payment flow changed: tested in Stripe test mode end-to-end
+
+### Step 4 — Deploy
+
+Deploy to production. Tag the commit with the version (`v2.4.0`). Push the tag. Open a PR if one isn't already merged. After deploy:
+
+- Note the deploy timestamp
+- Capture baseline metrics for canary (Phase 7)
+- Trigger `/money-content release-notes` to draft the three-tier user comms (see `money-content` "Release-Notes Mode")
+
+### Step 5 — Release notes delivery
+
+Once `/money-content release-notes` returns the three tiers:
+
+- Tier 1 (one-line) → post to in-app banner, X, status page
+- Tier 2 (email) → send to existing users (use `/money-outreach` with the "release-notes" template, not the cold-outreach template)
+- Tier 3 (full notes) → append to CHANGELOG.md (already done in Step 2) + publish as a blog post via `/money-content`
+
+The release-notes delivery is not optional for ships that include user-facing changes. The conversion rate on release-note emails is the highest of any content type — skipping them is leaving free→paid upgrades on the table.
+
 ## Phase 6: Quality Assurance
 
 After the launch checklist passes, run systematic QA testing. Don't ship what you haven't tested in a real browser.

package/skills/money-quality/SKILL.md

@@ -192,7 +192,11 @@ The pre-launch comprehensive audit. Includes everything from Standard, plus:
 - Missing indexes on frequently queried columns?
 - Any query taking >100ms?
 
-### 7. Security Audit (OWASP Top 10)
+### 7. Security Audit (OWASP Top 10 + STRIDE threat model)
+
+Run BOTH passes — OWASP catches the well-known classes of bug; STRIDE catches the architectural assumptions that turn one bug into a breach.
+
+#### OWASP Top 10 (vulnerability classes)
 
 | Check | How | Status |
 |-------|-----|--------|
@@ -205,6 +209,26 @@ The pre-launch comprehensive audit. Includes everything from Standard, plus:
 | CSRF | Check: tokens on state-changing requests, SameSite cookies | ✅/❌ |
 | Dependencies | Run `npm audit` / `pip audit` / `govulncheck` — check for known CVEs | ✅/❌ |
 
+#### STRIDE threat model (architectural exposure)
+
+For each component that handles auth, payments, or user data, ask the six STRIDE questions. Each "yes" is a finding to address; each "we accept this risk" is a decision the user has to actively make.
+
+| Threat | Question | Common in solo SaaS |
+|---|---|---|
+| **S**poofing identity | Can someone claim to be another user? | Magic links sent without rate limits; OAuth without state validation; webhook endpoints without signature verification |
+| **T**ampering with data | Can someone modify data they shouldn't? | Trusting client-sent prices in Stripe Checkout; allowing user to PATCH their own subscription tier; mutable database fields without audit logs |
+| **R**epudiation | Can a user deny doing something with no record? | No audit log of plan changes, refunds, or account deletions; no record of which admin took which action |
+| **I**nformation disclosure | Can someone read data they shouldn't? | Predictable IDs in URLs; verbose error messages leaking schema; environment-variable leaks in client bundles |
+| **D**enial of service | Can someone make the service unavailable? | No rate limit on signup or password reset; unbounded LLM-call costs from one bad actor; unbounded image-upload size |
+| **E**levation of privilege | Can a regular user become an admin? | Admin-flag in client-readable cookie; admin endpoints sharing the auth middleware of public ones; webhook handlers running with elevated permissions |
+
+For each "yes":
+1. Note the threat type, the component, and the specific path
+2. Classify severity (P0: live exposure / P1: works with one chained mistake / P2: requires multiple chained mistakes)
+3. Add to the Ship Check report under "Security findings" with the explicit threat type tag (e.g., `[STRIDE-T]` for tampering)
+
+If 3+ STRIDE threats are open at P0/P1, the product is NOT ready to charge real money — regardless of how the OWASP table looks. STRIDE catches the things OWASP misses.
+
 ### 8. Accessibility Audit (WCAG 2.1 AA)
 
 - [ ] All images have alt text
@@ -250,6 +274,74 @@ Remaining items (non-blocking):
 
 ---
 
+## Tech Triage Mode (when something is broken)
+
+`/money-diagnose` handles business-level "I'm stuck" — slow growth, wrong ICP, channel doesn't convert. **Tech Triage Mode** handles the technical version: a failing test, a slow query, an unexplained 500, a flaky CI run, a feature that "works on my machine".
+
+Trigger via `/money-quality triage` or by describing the symptom directly ("the signup flow returns 500 in production but not staging").
+
+### The triage loop
+
+Do NOT start guessing. Do NOT start grepping the codebase. Do NOT propose fixes. Follow the loop in order — each step is cheap, and the first three usually reveal the answer.
+
+#### Step 1 — Restate the symptom precisely
+
+Force a one-paragraph statement of:
+- What command/URL/action triggers the bug
+- What the user expected to happen
+- What actually happens (exact error message, stack trace, screenshot)
+- What's known to be different between "works" and "doesn't work" (env, browser, account, data)
+
+If any of those four is missing, ask for it before proceeding. ~30% of triage sessions end at this step because the symptom turned out to be different from what was first reported.
+
+#### Step 2 — Find the boundary
+
+The bug exists between something that works and something that doesn't. Find the boundary:
+
+| Boundary axis | Diagnostic |
+|---|---|
+| Time | When was the last known-good run? `git log` between known-good and now is the suspect set |
+| Environment | Works in dev, fails in prod → env vars, build config, runtime version |
+| Data | Works for user A, fails for user B → data-shape difference, edge case on B's row |
+| Code path | Works on URL X, fails on URL Y → route handler difference, middleware difference |
+| Concurrency | Works in isolation, fails under load → race condition, connection pool, rate limit |
+
+Pick the one most likely. Spend ≤10 minutes on each before switching.
+
+#### Step 3 — Reproduce locally
+
+A bug you can't reproduce, you can't fix — you can only hope. Reproduce with the smallest possible inputs:
+
+- Strip everything not in the minimal repro
+- Run it in a clean state (no cache, fresh DB, fresh process)
+- If you can't reproduce in 30 minutes: it's likely environmental — go back to Step 2 with environment as the axis
+
+Once reproducing: capture the exact command and inputs that trigger the failure. This becomes the regression test, regardless of root cause.
+
+#### Step 4 — Hypothesize, then test (not the other way)
+
+Most "obvious" fixes are wrong because the hypothesis was never explicit. Force the format:
+
+> "I think the bug is caused by **{specific cause}**. If I'm right, then **{specific change}** will fix it AND **{prediction about another signal}** will also be true."
+
+If the prediction doesn't pan out, the hypothesis was wrong — don't just patch the symptom. Restart Step 4 with a new hypothesis.
+
+#### Step 5 — Fix, regression-test, document
+
+- Smallest fix that resolves the verified root cause
+- Add the regression test from Step 3
+- Note the bug in the project's `learnings.jsonl` via `/money-learn add` — category `tech`, with the specific cause and the smallest reproducer. Future-you will hit a similar bug and want this trail.
+
+### What to refuse in triage mode
+
+- "Try restarting it" — fine in panic; not in triage
+- "Maybe it's a Heisenbug" — Heisenbugs are race conditions you haven't proven
+- "Let's add error handling" without knowing what error — that hides the bug, doesn't fix it
+- "Just wrap it in try/catch" — same
+- Big refactors prompted by a small bug — fix the bug, log the refactor as a separate task
+
+The triage loop ends with three artifacts: the root cause stated in one sentence, the minimal regression test, and the `/money-learn` row. Without all three, the bug isn't really fixed — it's just suppressed.
+
 ## Continuous Quality (Integration with /money-ops)
 
 After the initial ship check, set up ongoing quality monitoring:

package/skills/money-review-operator/SKILL.md

@@ -82,6 +82,25 @@ If the User Profile doesn't include hours-per-week and cash runway, ask for both
 - 🔴 channels for solo without help: Enterprise sales, conference circuit, large paid-ads spend management, multi-platform content empire, building a sales team
 - **If the plan's primary channel is 🔴 for solo, that's NEEDS HIRE territory.**
 
+### Q5: Architecture & data-flow stress test
+
+A plan that's solo-shippable on paper can still trap the founder in 6 months of maintenance work if the architecture is wrong. Audit the proposed tech against five failure modes a solo operator can't escape from:
+
+| Failure mode | Question | Solo-killer if... |
+|---|---|---|
+| **Hidden ops cost** | What service runs that requires the founder's attention to keep alive? | Anything self-hosted that isn't trivially restartable. Anything requiring scheduled human action (manual backups, manual cert rotation, manual cron-job inspection) |
+| **Data shape lock-in** | What's the data model commitment in week 1? | A schema that assumes a use case which may not be the actual use case after first 10 customers — re-shaping data later is the #1 solo-founder time sink |
+| **Single point of failure** | If one third-party API goes down, does the whole product become unusable? | Yes, AND there's no graceful degradation, AND the founder has no fallback |
+| **Cost-curve mismatch** | At 100x current usage, what does the infra cost? | The cost curve goes superlinear (per-user database charges, per-request LLM costs at default models, per-MB egress) and there's no way to throttle |
+| **Debug accessibility** | When something breaks at 3am, what does the founder need to debug it? | The answer is "ssh into the box and grep logs" — not viable for solo. Needs centralized logs, error tracking, and a status URL the founder can hit from their phone |
+
+For each, classify:
+- 🟢 OK — solo-survivable as-is
+- 🟡 Survivable with one specific change (name the change)
+- 🔴 Not solo-survivable past 100 customers without changing this
+
+If 2+ are 🔴, the operator verdict shifts to 🟠 NEEDS HIRE or 🟡 SHIPPABLE WITH DESCOPE regardless of how the other questions went. Architecture debt at the wrong layer is the failure mode most solo plans don't see until month 4.
+
 ---
 
 ## Output structure
@@ -125,6 +144,17 @@ If the User Profile doesn't include hours-per-week and cash runway, ask for both
 
 {Verdict on whether the GTM plan is executable solo.}
 
+### 5. Architecture & data-flow stress test
+| Failure mode | Status | Note |
+|---|---|---|
+| Hidden ops cost | 🟢 / 🟡 / 🔴 | |
+| Data shape lock-in | 🟢 / 🟡 / 🔴 | |
+| Single point of failure | 🟢 / 🟡 / 🔴 | |
+| Cost-curve mismatch | 🟢 / 🟡 / 🔴 | |
+| Debug accessibility | 🟢 / 🟡 / 🔴 | |
+
+{Verdict on whether the architecture is solo-survivable.}
+
 ---
 
 ## What you'd actually ship in 8 weeks

package/skills/money-strategy/SKILL.md

@@ -218,6 +218,30 @@ Common traps:
 
 If key terms can't be defined precisely, the idea needs narrowing, not strategizing.
 
+#### Term-by-Term Audit Loop
+
+For every load-bearing word in the pitch, run this loop until each term has a measurable substitute. Stop when no more vague terms remain or after 5 rounds (whichever comes first).
+
+1. **Spot it** — Underline the word. Examples: "easy", "smart", "intelligent", "best-in-class", "premium", "community-driven", "viral".
+2. **Probe it** — Ask the user: "If a stranger had to verify this is true without trusting your word, what would they measure?"
+3. **Convert it** — Replace the word with the measurable substitute the user offered. If the user can't offer one, the term is decoration — strike it from the pitch.
+4. **Re-read** — Read the whole sentence with the substitute in place. If the sentence now sounds embarrassingly small, that's the real proposition. Decide whether to ship the small thing or change the proposition.
+
+The output of this loop is a one-paragraph pitch in which every claim is either measurable, time-bounded, or named to a specific person. Vague words have been either swapped or deleted. This rewritten pitch becomes the input to Layers 2-4.
+
+#### Fuzzy-to-Measurable Conversion
+
+Before exiting Layer 1, every goal the user mentioned must be converted to a measurable outcome in the format `<verb> <metric> <threshold> <by date>`:
+
+| Original (fuzzy) | Converted (measurable) |
+|---|---|
+| "Get more customers" | "Acquire 50 paying users at ≥$29/mo by 2026-08-01" |
+| "Build a community" | "Get 200 verified-email subscribers reading 2+ posts/mo by month 3" |
+| "Become the best in the space" | "Rank in top 3 Google results for 'X' by month 6, with ≥5% CTR" |
+| "Ship a great product" | "Ship feature X passing the QA tier 'Ship Check' with ≥9/10 score by date Y" |
+
+If the user resists conversion ("I just want to make it big"), that resistance IS the signal — the strategy is not yet ready. Output: "Goal is not yet measurable. Run `/money-discover` Phase 4.5 (Narrowest-Bet Pressure Test) to extract a falsifiable one-week bet, then return for strategy."
+
 ### Layer 2: Assumption Audit (Inversion Method)
 
 List every assumption the business idea relies on. For each, apply Kahneman's pre-mortem: "Imagine this assumption is wrong. What happens?"

package/skills/money-upgrade/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: money-upgrade
-description: "Upgrade show-me-the-money skills to the latest version. Use when the user wants to update skills, check for new versions, or says 'upgrade money', 'update skills', or 'latest version'."
+description: "Auto-update the show-me-the-money skill suite to the latest version. One command checks npm for a new version, downloads it, replaces the installed skills, and shows what changed. Use when the user wants to update skills, check for new versions, or says 'upgrade money', 'update skills', 'latest version', 'auto-update', or 'check for updates'."
 disable-model-invocation: true
 ---
 
-# Money Upgrade — Version Management
+# Money Upgrade — Auto-Updater
 
-Upgrade the show-me-the-money skill suite to the latest version.
+One command updates every money-* skill to the latest published version. No manual file copying, no version comparison by hand, no risk of partial installs.
 
 ## Language Selection
 
@@ -18,82 +18,150 @@ If the user's message contains a `[Language: ...]` tag, use that language for al
 
 Default to English if the user doesn't specify. All subsequent output must be in the chosen language.
 
-## Quick Update (Recommended)
+## What this skill does
 
-The fastest way to update is the built-in CLI command. It checks for a new version,
-downloads it, and re-installs all skills in one step:
+When the user invokes `/money-upgrade`, run the three steps in order:
+
+1. **Read the installed version** — `cat ~/.claude/skills/money/../../VERSION` if the file exists, otherwise read from the package metadata
+2. **Check npm for the latest version** — `npm view @orrisai/show-me-the-money version`
+3. **If outdated, run the auto-updater** — `npx @orrisai/show-me-the-money@latest update`
+
+The CLI (`bin/cli.js`) handles the actual work: download, version compare, backup, install. This skill is the user-facing wrapper that decides when to call it.
+
+## The full auto-update command
+
+This is the single command that does everything — version check, download, replace, verify:
 
 ```bash
-npx @orrisai/show-me-the-money update
+npx @orrisai/show-me-the-money@latest update
 ```
 
-If you prefer more control, follow the manual steps below.
+Run it for the user. It prints the before/after versions, lists which skills were re-installed, and exits cleanly.
 
-## Manual Upgrade Process
+## Workflow
+
+### Step 1 — Print current state
 
-### Step 1: Check Current Version
-Read the VERSION file from the installed skill directory:
-```bash
-cat ~/.claude/skills/money/../../VERSION 2>/dev/null || echo "Unknown"
 ```
+Current installation:
+  Version: v{current}
+  Location: ~/.claude/skills/
+  Skills installed: {count}
 
-Or check via CLI:
-```bash
-npx @orrisai/show-me-the-money version
+Checking npm for updates...
 ```
 
-### Step 2: Check Latest Version
-```bash
-npm view @orrisai/show-me-the-money version
+### Step 2 — Check for updates
+
+Run `npm view @orrisai/show-me-the-money version` (no arguments needed). Capture stdout. Compare to the local VERSION.
+
+If equal, exit with:
+
+```
+✅ You're on the latest version (v{version}). Nothing to update.
 ```
 
-### Step 3: Compare Versions
-- If current == latest: "You're on the latest version (vX.X.X)."
-- If current < latest: Proceed to upgrade.
+If different (local < remote), proceed to Step 3.
+
+### Step 3 — Run the updater
 
-### Step 4: Backup Current Installation
 ```bash
-BACKUP_DIR=~/.claude/skills-backup/money-$(date +%Y%m%d-%H%M%S)
-mkdir -p "$BACKUP_DIR"
-for dir in money money-discover money-strategy money-product money-content money-outreach money-social money-seo money-ads money-ops money-finance money-upgrade; do
-  [ -d ~/.claude/skills/$dir ] && cp -r ~/.claude/skills/$dir "$BACKUP_DIR/"
-done
-echo "Backup saved to $BACKUP_DIR"
+npx @orrisai/show-me-the-money@latest update
 ```
 
-### Step 5: Install Latest Version
+The CLI prints its own progress. After it returns, verify success:
+
+- Check that VERSION now matches the latest npm version
+- Confirm all skill directories are present in `~/.claude/skills/`
+
+### Step 4 — Show what changed
+
+After update succeeds, fetch the release notes for the new version and summarize:
+
 ```bash
-npx @orrisai/show-me-the-money@latest install
+curl -s https://raw.githubusercontent.com/iamzifei/show-me-the-money/v{version}/CHANGELOG.md | head -80
+```
+
+If CHANGELOG.md isn't available, fall back to the README's "What's new" section. Present the highlights in 5-10 bullets — not the full diff.
+
+### Step 5 — Remind to restart
+
+```
+✅ Updated to v{new}.
+
+To pick up the new skills, restart Claude Code (or run /reload-plugins if available).
+
+What's new in this version:
+- [bullet 1]
+- [bullet 2]
+- ...
+
+Run /money to start using the updated suite.
 ```
 
-### Step 6: Verify Installation
-- Check that all 12 skill directories exist in `~/.claude/skills/`
-- Read the new VERSION file
-- Confirm the upgrade was successful
+## Manual fallback
 
-### Step 7: Show Changelog
-Display what's new in this version (from the GitHub releases page or CHANGELOG).
+If the auto-updater fails (npm offline, registry issue, permission error), fall back to the manual path. Read the error message and surface ONE specific reason it failed — not a wall of generic recovery options.
+
+Common failures and the response:
+
+| Failure | Diagnostic | Response |
+|---|---|---|
+| `npm: command not found` | Node/npm not installed | "Install Node.js from nodejs.org first, then re-run `/money-upgrade`." |
+| Network unreachable | No internet or npm registry down | "Can't reach npm registry. Check your network — registry status: https://status.npmjs.org." |
+| EACCES on `~/.claude/skills/` | Permission denied on the skills dir | "Permission denied writing to `~/.claude/skills/`. Run `sudo chown -R $(whoami) ~/.claude/` then re-run." |
+| Tag exists but install fails | Likely a publish race or a broken release | "Latest release has an install issue. Run `npx @orrisai/show-me-the-money@{previous-stable}` to pin to the prior version." |
 
 ## Rollback
 
-If the upgrade fails or causes issues:
+If the new version breaks something, roll back to the previous version explicitly:
+
 ```bash
-# Find the latest backup
-ls -la ~/.claude/skills-backup/
-
-# Restore from backup
-BACKUP_DIR=~/.claude/skills-backup/money-XXXXXXXX-XXXXXX
-for dir in "$BACKUP_DIR"/*/; do
-  dir_name=$(basename "$dir")
-  rm -rf ~/.claude/skills/$dir_name
-  cp -r "$dir" ~/.claude/skills/$dir_name
-done
-echo "Rolled back to backup version."
+# 1. Find the previous stable version on npm
+npm view @orrisai/show-me-the-money versions --json | tail -20
+
+# 2. Install that specific version
+npx @orrisai/show-me-the-money@{previous-version} install
 ```
 
-## Cleanup
+The auto-updater does NOT auto-rollback on failure — it leaves the installation in whatever state the failed install ended at. If the user reports a regression after update, run the two-step rollback above and then file an issue at https://github.com/iamzifei/show-me-the-money/issues.
 
-Remove old backups (keep last 3):
-```bash
-cd ~/.claude/skills-backup && ls -dt money-* | tail -n +4 | xargs rm -rf
+## When to auto-update vs ask first
+
+Default: ask before updating. The user invoked `/money-upgrade`, so they want to update — but show the version delta first and let them confirm. Example:
+
+```
+Current: v2.3.1
+Latest:  v2.4.0  ← 1 minor version behind
+
+New in v2.4.0:
+- Tech-triage mode for technical debugging
+- DESIGN.md design system contract in money-product
+- Ship lifecycle: VERSION + CHANGELOG + release notes flow
+- Cross-project portfolio learnings via /money-learn promote
+- STRIDE threat model in money-quality
+- Operating modes + edit perimeter + panic stop in money-ops
+
+Proceed with update? [y/n]
 ```
+
+**Skip the confirmation** only if the user explicitly said `--yes`, `--auto`, or "just update it" in their message.
+
+## Principles
+
+- **One command, one outcome** — Don't ask the user to copy multiple shell snippets
+- **Show the delta before changing anything** — Version numbers + headline changes, not full diffs
+- **Don't auto-rollback** — Failed installs surface as failures; rollback is an explicit user action
+- **Restart prompt at the end** — Skills don't always reload mid-session; remind the user
+- **Read the CHANGELOG, not the commit log** — Users care about behavior changes, not implementation churn
+
+---
+
+## Value Quantification (Required at End of Output)
+
+| | |
+|---|---|
+| ⏱ **Time saved** | ~10-15 minutes vs the manual upgrade path (compare versions, backup, install, verify, read release notes) |
+| ⚠️ **Risks avoided** | (1) Partial install where some skills update and others don't; (2) backing up the wrong directory and losing project-local skills; (3) running an old skill alongside a new one and getting inconsistent behavior |
+| ✅ **What you got** | A clean update from v{current} → v{new}, the relevant CHANGELOG bullets, and the restart prompt |
+| 🚧 **Without this skill** | Most users put off the update for weeks, run old skills against new docs/atoms, and surface mystery bugs that turn out to be "you're on v2.1, that field was renamed in v2.3" |