Juanwang Holiday Planner

<objective> Create, review, and update a saveable single-file HTML holiday growth-plan dashboard. The skill turns a user's holiday goals into a phased daily plan, supports daily check-ins, and can write phase-level AI reviews back into the HTML data bundle.

The product voice is Chinese-first and warm: it helps users stop vague flag-setting without selling anxiety, peer pressure, or unhealthy transformation promises. </objective>

<essential_principles>

• Single HTML is the deliverable: output exactly one .html file. Use a personalized safe filename by default (juanwang-{nickname}-{goal-keyword}-{startDate}.html) and respect an explicit user filename after sanitizing it and adding .html if needed. Do not create zip files, preview images, QR codes, manifest.json, or sw.js for normal delivery.
• Start date is required: never invent a start date. If the user does not provide a concrete YYYY-MM-DD start date, ask for it before generating a plan.
• Nickname is optional: ask for a preferred nickname/name at intake when natural, store it in config.user.name, and fall back to 小卷 without blocking generation.
• No fake progress: new plans initialize with checkins: {}, reviews: {}, selected Day 1, 0 streak, 0% completion, and no placeholder dashboard data.
• Data drives UI: dates, calendars, streaks, completion rates, phase review readiness, and report stats must be computed from APP_DATA.dailyTasks and checkins.
• Health-first workload: protect sleep, recovery, and sustainable effort. If health data declines or the user reports overload, reduce future load before adding tasks.
• Low-friction execution is the core: every generated plan must help the user start when motivation is low through If-Then plans, 2-minute starter tasks, timeboxes, buffer, stage reviews, and small-win feedback.
• No anxiety marketing: avoid “弯道超车”, “卷死同学”, shame, public-pressure tactics, extreme weight loss, and miracle-result promises.
• Mood is emoji data: mood options are exactly 😄, 🙁, 😝, 😭, 😡; store the selected emoji string directly in checkins[date].mood.

</essential_principles>

<routing> Route by user intent and then follow the selected workflow exactly:

If intent is mixed, prioritize in this order: validate existing data → phase review → adjust existing plan → generate new plan. Ask one concise clarification only when the required artifact or intent is missing. </routing>

<reference_index> Load only the references required by the selected workflow:

• references/product-principles.md — product scope, users, tone, and delivery model
• references/app-data-schema.md — APP_DATA, localStorage, review data, and compatibility rules
• references/failure-mechanisms.md — why holiday plans fail and the product responses that lower execution friction
• references/planning-methodology.md — phase design, daily task construction, If-Then plans, timeboxing, buffer, AAR/PDCA
• references/safety-and-tone.md — prohibited language, health boundaries, review tone
• references/html-runtime-contract.md — template/runtime requirements and validation invariants

</reference_index>

<workflows_index>

</workflows_index>

<success_criteria> A task handled by this skill succeeds when:

• Generated plans deliver one HTML file with no PWA dependency and no fake progress.
• Generated plans include the P0 low-friction system: scenario-bound If-Then, daily 2-minute starter, realistic timebox with buffer, 7-10 day review cadence, and small-win feedback language.
• Validation confirms Day 1 initialization, dynamic dates, dynamic phase review readiness, and five emoji mood options.
• Phase reviews use only real synced data, preserve existing checkins/reviews, and keep a supportive, non-shaming tone.

</success_criteria>

juanwang-holiday-planner

卷王·假期成长规划 — 用 AI 编程助手把模糊的假期目标，变成一份可打卡、可复盘、可保存的 单文件 HTML 假期成长仪表盘。

不靠意志力，靠可执行的规划。产品语气温暖、反焦虑：不贩卖「弯道超车」「卷死同学」式压力，优先睡眠、恢复与可持续节奏。

---

在线预览

想先看生成效果，可以打开这份示例网页：卷王·假期成长规划示例。

这是一份 60 天计划的实际生成页面，用来预览「规划 / 打卡 / 仪表盘 / 复盘」等核心交互；正式使用时，Skill 会根据你的开始日期、目标和可用时间生成新的个性化单文件 HTML。

<p> <img src="./assets/preview-plan.png" alt="规划页预览：阶段路线图和每日任务" width="220"> <img src="./assets/preview-checkin.png" alt="打卡页预览：今日任务、健康打卡和心情记录" width="220"> <img src="./assets/preview-dashboard.png" alt="仪表盘预览：关键指标和 60 天打卡日历" width="220"> <img src="./assets/preview-report.png" alt="复盘页预览：勋章墙、数据汇总和 AI 复盘总结" width="220"> </p>

---

快速开始

你 不需要会写代码。装好 Skill 后，在对话里说明假期目标并 必须提供开始日期；AI 会按本仓库规则生成一个个性化命名的单文件 HTML，双击即可在浏览器打开（手机也可传文件后用浏览器打开）。

路径 A：已安装 Skill

1. 新开一次 AI 对话（让 Skill 生效）。 2. 复制下面模板，改成你的信息，发送给 AI。 3. 等待生成 单个 HTML 文件，默认文件名类似 juanwang-小卷-英语运动-2026-07-01.html。

/juanwang-holiday-planner 帮我做一份暑假成长规划

开始日期: 2026-07-01
假期长度: 45 天
昵称: 小周（可选）
主要方向: 英语 + 运动恢复节奏
具体目标: 每天背 20 个四级词，每周跑 2 次
副目标: 读完一本非虚构书（可选）
每天可用时间: 约 2 小时
期望文件名: 小周暑假英语运动计划（可选）

触发方式因环境而异：优先用 `/juanwang-holiday-planner`；若未注册斜杠命令，可在对话里说明「请严格按 juanwang-holiday-planner skill 生成单文件 HTML 计划」，或用 `@` 引用已安装目录下的 SKILL.md。

重要：若未提供 YYYY-MM-DD 格式的开始日期，Skill 会要求你补充，不会擅自编造日期。

路径 B：尚未安装 Skill

1. 先安装（推荐一条命令，见下文 安装方式）。 2. 新开一次 AI 对话。 3. 复制 [路径 A](#路径-a已安装-skill) 中的对话模板，改成你的信息后发送。

---

安装方式

思路：让 AI 能读到本仓库的 `SKILL.md` 及 `workflows/`、`references/`、`templates/` 等配套文件。

npx skills install 与 npx skills add 等价（install 是 add 的别名）。CLI 会从 GitHub 拉取仓库并写入各 Agent 约定的 skills 目录，不必先手动 clone。

以下命令假设仓库已发布为 archlizheng/juanwang-holiday-planner。若你 fork 了仓库，把 owner/repo 换成自己的即可。

推荐：一条命令安装

安装到当前项目（便于团队共享）：

npx skills install archlizheng/juanwang-holiday-planner -y

安装到本机所有项目（个人常用）：

npx skills install archlizheng/juanwang-holiday-planner -g -y

仅安装到 Cursor：

npx skills install archlizheng/juanwang-holiday-planner -a cursor -y

仅安装到 Codex：

npx skills install archlizheng/juanwang-holiday-planner -a codex -y

安装后请 新开对话。Skill 名称为 `juanwang-holiday-planner`（与 SKILL.md 的 name 字段一致）。

更新与查看

更新已安装的 skill：

npx skills update juanwang-holiday-planner

仅查看本仓库里有哪些 skill、不实际安装：

npx skills install archlizheng/juanwang-holiday-planner --list

备选：手动克隆或复制

若环境不支持 skills CLI，可将本仓库克隆或复制到 Agent 的 skills 目录：

目录内须包含 `SKILL.md` 及完整的 workflows/、references/、templates/、scripts/。

---

你会得到什么

生成物是 一个 HTML 文件，默认会按昵称、目标和开始日期生成安全文件名；如果你提供「期望文件名」，Skill 会清理危险字符并自动补上 .html 后缀。文件内含：

新计划 不会预填假进度：checkins 与 reviews 初始为空，Day 1 选中，连续天数与完成率为 0。

---

还能做什么

在已安装 Skill 的前提下，你可以继续对话：

---

字段说明（照抄格式最稳）

---

验证（开发者 / 维护者）

在 skill 目录下执行：

node scripts/validate.mjs templates/juanwang-skill.html
node scripts/smoke-test.mjs templates/juanwang-skill.html

---

仓库结构

• SKILL.md — 路由与核心原则
• workflows/ — 生成、调整、复盘、校验流程
• references/ — 产品原则、数据 schema、规划方法论、安全语气、运行时契约
• scripts/ — validate.mjs（静态不变量）、smoke-test.mjs（运行时逻辑测试）
• templates/juanwang-skill.html — 生成时唯一使用的 HTML 模板

请勿将 legacy PWA 文件、二维码、预览图、zip 包或 .DS_Store 纳入发布包。

---

Author release checklist

发布新版本前确认：

• YAML frontmatter 中 name 为小写且与目录名一致；description 为第三人称并含中文触发词
• SKILL.md 使用 XML 结构，正文无 markdown 标题，且少于 500 行
• 所有 workflow、reference、template、script 文件存在
• 上述两条 validate / smoke-test 命令均通过
• 发布包仅包含上文「仓库结构」所列资源

---

许可证

MIT

<app_data_schema> APP_DATA must be valid JSON injected into the HTML template as:

/*__APP_DATA_START__*/
const APP_DATA = { ... };
/*__APP_DATA_END__*/
const STATE_KEY = computeStateKey(); // juanwang_state_v1_{startDate}_{goalHash}

Required top-level fields:

{
  "config": {
    "output": {
      "fileNameBase": "juanwang-小卷-英语运动-2026-07-01"
    },
    "user": {
      "name": "小卷",
      "duration": 30,
      "mainGoal": {
        "category": "卷健康 | 卷学习 | 卷实习 | 卷兴趣 | 卷玩",
        "subGoal": "具体子目标",
        "specific": "用户可读的具体目标"
      },
      "sideGoals": [
        {"category": "卷学习", "subGoal": "英语四级"}
      ],
      "startDate": "YYYY-MM-DD",
      "identityAnchor": "optional gentle identity sentence",
      "availableDailyMinutes": 120
    }
  },
  "phases": [],
  "dailyTasks": [],
  "checkins": {},
  "reviews": {}
}

config.output.fileNameBase is optional for backward compatibility and must not include .html. For new plans, set it from the safe filename base used for delivery. Prefer user-requested filenames when provided; otherwise use juanwang-{nickname}-{goal-keyword}-{startDate}. If omitted in older files, runtime falls back to config.user.name, config.user.mainGoal, and config.user.startDate.

Required phase fields:

• id: number, stable phase id starting at 1
• title: Chinese phase name
• icon: current icon id such as sprout, leaf, tree, rocket, trophy
• range: e.g. Day 1-7
• theme: phase theme
• tip: warm phase-level prompt

Optional config.user methodology fields such as identityAnchor, availableDailyMinutes, realisticDailyMinutes, or riskScenarios may be included when useful. config.user.name should use the user's preferred nickname/name when provided, otherwise 小卷; nickname is not a hard gate. The runtime must not depend on methodology fields.

Required dailyTasks[] fields:

• day: 1-based day number
• date: concrete YYYY-MM-DD, computed from startDate
• phaseId: matching phase id
• mainTask: 25-60 minute concrete next physical action with a timebox
• starterTask: 2-minute starter action
• elasticTask: optional ~10-25 minute action, explicitly says 允许放弃
• ifThenPlan: high-risk scenario fallback bound to a specific trigger
• estimatedMinutes: number
• tip: daily warm prompt; may include starter and If-Then summary
• healthTarget: {steps, sleepTarget, waterCups, exerciseMinutes}

Initialization rules:

• New plan: checkins: {} and reviews: {}
• UI selected day defaults to Day 1
• Do not inject sample checkins or fake reviews

localStorage key is computed at runtime as juanwang_state_v1_{startDate}_{goalHash} so multiple plans do not overwrite each other.

localStorage shape:

{
  "checkins": {
    "YYYY-MM-DD": {
      "starterDone": true,
      "mainDone": true,
      "elasticDone": false,
      "mood": "😄",
      "note": "...",
      "health": {
        "steps": 8000,
        "sleepTime": "23:30",
        "waterCups": 8,
        "exerciseMinutes": 20
      }
    }
  },
  "selectedDay": 1,
  "reviews": {
    "1": {
      "text": "<p>...</p>",
      "generatedAt": "ISO timestamp",
      "version": "vYYYYMMDD-HHMM"
    }
  }
}

Compatibility rules:

• Preserve existing checkins and reviews when modifying a synced HTML.
• Use icon as the phase display field; do not reintroduce legacy emoji as the primary field.
• Phase end day is max(dailyTasks[].day where phaseId === phase.id), never a hardcoded formula.

Injection safety:

• The initial APP_DATA block written at generation time is NOT auto-escaped (only the in-app "sync to HTML" path escapes via .replace(/<\//g, '<\\/')). When you write APP_DATA into the template, escape every </ in string values (goals, notes, tips, If-Then text) to <\/. An unescaped </script> anywhere in APP_DATA terminates the script block and breaks the page. scripts/validate.mjs enforces <script>/</script> balance as a backstop.

</app_data_schema>

<failure_mechanisms> Core belief: 计划失败不是意志力失败，而是系统设计失败。The skill must lower execution friction instead of asking the user to become more disciplined.

P0 product response stack:

If-Then quality bar:

• Bad: “如果状态不好，就调整心态继续努力。”
• Good: “如果今晚 22:30 以后才想起雅思任务，就不补完整任务，只背 5 个单词并录 30 秒口语。”
• Good: “如果已经打了 2 局王者还想继续，就先把手机放到客厅充电，做完 2 分钟启动版后再决定是否继续。”

2-minute starter quality bar:

• It is not half of the main task; it is the body-level switch that makes starting painless.
• IELTS reading: 打开题目，只圈标题和 3 个关键词。
• IELTS speaking: 打开录音，读 1 个题目并说 30 秒。
• Guitar: 把吉他拿出来，按 2 次 C 和弦。
• Health: 穿好鞋，走到楼下。

Review quality bar: Phase reviews answer these questions using real checkins only: 1. 哪些任务用户做得动？ 2. 哪些任务阻力最大？ 3. 崩盘场景是否被 If-Then 接住？ 4. 下一阶段要减少什么？ 5. 下一阶段保留哪个最小动作？

If completion is low, the default recommendation is smaller tasks, clearer cues, fewer side goals, or more buffer. Do not recommend compensatory overwork. </failure_mechanisms>

<html_runtime_contract> The HTML template must remain a self-contained browser file.

Must not contain:

• <link rel="manifest" href="manifest.json">
• navigator.serviceWorker.register(...)
• beforeinstallprompt install banner logic
• hardcoded Day 8 default selection
• fake checkins in new-plan APP_DATA
• hardcoded phase review end days such as Day 7/15/23/30 in runtime logic

Must contain:

• /*__APP_DATA_START__*/ … /*__APP_DATA_END__*/ boundary markers around const APP_DATA = ...;
• const STATE_KEY = computeStateKey(); with per-plan fingerprint (startDate + goal hash)
• data exchange UI for export JSON, sync to HTML, and import JSON (sync must work on file:// without fetch)
• getFileNameBase() that uses config.output.fileNameBase first and falls back to nickname, goal keyword, and start date; JSON export and sync-to-HTML download must use this same base
• check-in UI renders starterTask (stores starterDone) and ifThenPlan
• mood buttons for exactly 😄, 🙁, 😝, 😭, 😡
• getTodayDay() auto-aligns selected day; phase review readiness uses progress day, not manual selected day
• dynamic calculations for streak (backwards from today; starter counts), completion rates, dashboard stats, calendar title, phase countdown, and phase review readiness

Validation scenarios:

• A new 60-day plan starting 2026-07-01 yields Day 1 = 2026-07-01 and Day 60 = 2026-08-29
• Initial dashboard displays 0 streak, 0 check-in days, 0.0% completion, and “暂无数据” for mood summary
• Saving Day 1 main task changes streak to 1 and completion rate to 100.0% when it is the only checkin
• Setting selectedDay to the last day of a phase makes exactly that phase review ready

</html_runtime_contract>

<planning_methodology> Core planning thesis: 用户不是缺计划，用户缺的是在低状态下依然能启动的系统。Every methodology below must become a generation rule, not a theory label.

Input collection:

• Duration: 30 / 45 / 60 / 90 days or a user-provided number
• Start date: required YYYY-MM-DD; ask if missing and do not default to today/tomorrow
• Main direction: 卷玩 / 卷学习 / 卷实习 / 卷兴趣 / 卷健康
• Specific main goal and measurable outcome
• Optional side goals: maximum 2; side goals must not crowd out the main goal
• Optional available daily time and current baseline; if provided, schedule only 70%-80% of it
• Optional identity anchor: “这个假期结束时，你希望自己变成什么样的人？” If absent, infer one gentle sentence from the goals
• Optional high-risk failure scenarios: e.g. 熬夜, 手机刷太久, 王者太久, 下雨, 家里临时安排, 情绪低落

Five-layer methodology stack and generation rules:

Phase splitting:

• 30 days: default 4 phases: Day 1-7, Day 8-15, Day 16-23, Day 24-30
• 31-60 days: 4-6 phases, usually 7-10 day blocks where possible; avoid one long 15+ day phase without review
• >60 days: 6-9 phases; may include a trophy closing phase
• First phase is deliberately lighter for rhythm building
• Every 7-10 days, include a low-load review/recovery day or make the phase ending day lighter
• For all durations, compute review readiness from actual task phase membership

Daily task design:

• Main task: concrete action + quantity + timebox, usually 25-60 minutes. Prefer “做 1 个 IELTS Listening Section 1 并错题复盘 10 分钟” over “提升听力”.
• Starter task: a 2-minute action that makes starting easy. It must be easier than the main task and executable even at low motivation.
• Elastic task: optional 10-25 minutes, explicitly marked as 允许放弃; side goals usually live here.
• If-Then plan: scenario-specific fallback for the user's risk pattern; bind it to one real trigger and one tiny replacement action.
• Health target: conservative progression for steps, water, exercise, and sleep; never trade sleep for extra tasks.
• Tip: encourage the starter and small win, not “加油坚持”.

Workload and buffer rules:

• Default to realistic planning, not the user’s optimistic estimate.
• If user reports available time, schedule only 70%-80% and leave 20%-30% as buffer. Example: 120 minutes available → 60-75 minutes main task + 15-25 minutes optional elastic task + remaining buffer.
• If no available time is provided, keep the first week light: one main timebox plus one optional task only.
• Make the plan barely challenging: current ability × 1.0-1.1, not “爆改”.
• Main goal owns the main task; side goals should usually appear as elastic or low-frequency tasks.
• If the user is behind or health is down, shrink future tasks before adding catch-up work.
• Never design punitive make-up days or compensation marathons.

If-Then generation rules:

• Use the user’s own collapse scenarios first.
• If no scenarios are provided, include common holiday risks: late-night scrolling, long gaming sessions, family interruptions, low mood, and weather.
• The fallback action should preserve continuity, not complete the full task.
• Good format: “如果 [specific trigger], 那么 [tiny physical action]，并允许今天只算启动版。”

2-minute starter examples:

• IELTS reading: 打开题目，只圈标题和 3 个关键词。
• IELTS listening: 播放音频前 30 秒，写下听到的 3 个词。
• IELTS speaking: 打开录音，读 1 个题目并说 30 秒。
• Guitar: 把吉他拿出来，按 2 次 C 和弦。
• Health: 穿好鞋，走到楼下；或倒一杯水并站立拉伸 1 分钟。

Review method: Use AAR/PDCA in warm prose, but prioritize adjustment over summary: 1. Original intent for the phase 2. What actually happened, using specific numbers from checkins 3. At least one concrete progress signal or small win 4. Which task/trigger created the most friction 5. Whether If-Then and starter tasks helped the user restart 6. One or two lower-friction next actions for the next phase

Small-win feedback rules:

• Do not define the user by completion rate.
• Mention “没有完全断掉”, “启动版也算保留节奏”, “作息提前了”, “某个时间锚点有效” when supported by data.
• If there is no data, say “暂无数据，先从 Day 1 的 2 分钟启动版开始” rather than inventing progress.

</planning_methodology>

<product_principles> Product name: 卷王·假期成长规划

Value proposition: 不靠意志力，靠可执行的规划。 The skill turns vague holiday goals into a practical daily dashboard with check-ins and stage reviews.

Primary users:

• High-school graduates, incoming high-school students, and incoming college students
• College students or young adults who repeatedly over-plan and under-execute
• Parents may configure plans, but the plan should serve the learner's autonomy

Core deliverable:

• One .html file with a personalized safe filename. Default format: juanwang-{nickname}-{goal-keyword}-{startDate}.html; if the user explicitly requests a filename, sanitize it and add .html if needed.
• The file contains CSS, JS, APP_DATA, check-in UI, dashboard, and data exchange UI
• Users can double-click it on desktop or send it to a phone and open it with a browser
• Do not generate zip files, preview screenshots, QR codes, manifest.json, or sw.js

Main tabs in the HTML: 1. 规划: phase roadmap, daily task list, date labels, task click-to-check-in 2. 打卡: day switcher, main/elastic task checks, health data, mood, note 3. 仪表盘: real streak, completion rates, check-in days, health stats, calendar, recent trend 4. 复盘: medals, data summary, phase-level review cards </product_principles>

<safety_and_tone> Voice:

• Chinese-first, warm, direct, lightly self-aware
• Use second person “你”
• Prefer “先开始”, “允许慢一点”, “每一步都算数”, “启动版也算保留节奏” over pressure language

Do not use:

• “弯道超车”, “卷死同学”, “同龄人正在抛弃你”
• “变态计划”, “邪修逆袭”, “爆改人生”
• “震惊”, “绝绝子”, “刷爆”
• Public commitment or shame as motivation
• Completion-rate shaming in reviews

Health boundaries:

• Do not create extreme weight-loss targets such as “30 天瘦 10 斤”
• Sleep, hydration, and recovery outrank extra tasks
• For minors, avoid body-anxiety framing; use health, energy, routine, and strength language

Phase review tone:

• Start with what the user completed or learned
• Use concrete numbers, not moral judgments
• Explain gaps as rhythm/environment/task-size problems
• Suggest reducing friction or lowering load before asking for more discipline
• Always identify at least one specific small win when data supports it; if data does not support a win, say “暂无数据，先从 2 分钟启动版开始”

</safety_and_tone>

<required_reading> Read these before adjusting a plan: 1. references/app-data-schema.md 2. references/failure-mechanisms.md 3. references/planning-methodology.md 4. references/safety-and-tone.md 5. references/html-runtime-contract.md </required_reading>

<process> 1. Parse the synced HTML: extract APP_DATA, checkins, selected day, and reviews. If localStorage data is missing, ask the user to sync to HTML first. 2. Identify history boundary: treat days with checkins as history. Do not alter those daily tasks unless the user explicitly asks for a historical correction. 3. Diagnose load and friction: use completion, health, notes, and the user's stated issue to identify failed mechanisms: intention-behavior gap, emotion avoidance, goal-action mismatch, planning fallacy, or completion shame. 4. Choose the lowest-friction fix: prefer smaller main tasks, clearer 2-minute starters, stronger scenario-bound If-Then plans, more buffer, fewer side goals, or lighter review days before changing the goal itself. 5. Adjust only future tasks: preserve day numbers, dates, phase ids where possible, checkins, and reviews. Keep the main goal prioritized. 6. Write back HTML: replace APP_DATA with the adjusted future tasks and preserved history. 7. Validate: confirm no historical checkins/reviews were dropped and the HTML still passes deliverable validation. </process>

<success_criteria>

• Past completed/check-in days remain unchanged.
• Future tasks are more executable, lower-friction, and not punitive.
• Adjustments preserve or improve daily 2-minute starters, If-Then plans, timeboxes, and buffer.
• Health downturns produce lower load, not higher pressure.
• The adjusted HTML remains a single file with preserved data.

</success_criteria>

<required_reading> Read these before writing a phase review: 1. references/app-data-schema.md 2. references/failure-mechanisms.md 3. references/planning-methodology.md 4. references/safety-and-tone.md 5. references/html-runtime-contract.md </required_reading>

<process> 1. Require synced data: if the user provides an original HTML without APP_DATA.checkins, ask them to open the file and use 📦 数据交换 → 同步到 HTML first. 2. Parse APP_DATA: extract JSON with /const APP_DATA = (\{[\s\S]*?\});/ (between /*__APP_DATA_START__*/ and /*__APP_DATA_END__*/ when present) and parse it. Do not invent missing checkins. 3. Find progress: use the latest checkin date when checkins exist; otherwise use selectedDay if present, or Day 1. 4. Find reviewable phases: for each phase, compute end day from dailyTasks; skip phases with existing reviews[phaseId] unless the user explicitly asks to rewrite. 5. Analyze friction and small wins: compute completion, starter/continuity signals when available, health trends, mood/notes, and repeated collapse scenarios. If no checkins exist, state that there is no data and do not generate a fake review. 6. Write review text: 200-300 Chinese characters per phase, 4-5 <p> paragraphs (literal <p>...</p> HTML tags, not escaped entities), with AAR/PDCA content and specific checkin numbers. Each review must name at least one concrete progress signal, one friction source, whether If-Then/starter tasks helped, and 1-2 lower-friction next actions. If completion is low, recommend smaller tasks or fewer side goals before extra discipline. 7. Write back HTML: merge new reviews into APP_DATA.reviews, preserve checkins and existing reviews, update generated metadata if present, and output a new timestamped HTML. </process>

<success_criteria>

• Review uses only parsed user data.
• Existing checkins and reviews are preserved.
• No phase is reviewed before its dynamically computed end day.
• Review tone is supportive and non-shaming.
• Review reinforces small wins and gives load-reduction suggestions when friction is high.

</success_criteria>

<required_reading> Read these before generating a new plan: 1. references/product-principles.md 2. references/app-data-schema.md 3. references/failure-mechanisms.md 4. references/planning-methodology.md 5. references/safety-and-tone.md 6. references/html-runtime-contract.md </required_reading>

<process> 1. Collect required inputs: duration, start date, main direction, specific main goal, up to 2 side goals, optional nickname/name, optional desired filename, optional available daily time/baseline, optional identity anchor, and optional high-risk scenarios. If start date is missing, ask for it and stop. Do not block generation for missing optional fields; infer gentle defaults. If nickname is missing, use 小卷. 2. Create the low-friction strategy: convert the user’s goals and collapse scenarios into a P0 execution system: identity anchor, realistic workload, 2-minute starters, If-Then fallbacks, timeboxes, buffer, and review cadence. 3. Create phases: split the duration into phase ranges, choose phase icons, themes, and warm tips. Prefer 7-10 day review loops and make the first phase/light review days deliberately easier. Keep phase ids stable and sequential. 4. Create daily tasks: for every day, generate date, phaseId, mainTask, starterTask, elasticTask, ifThenPlan, estimatedMinutes, tip, and healthTarget. Every mainTask must be a next physical action with a timebox; every starterTask must be completable in 2 minutes; every ifThenPlan must bind to a real or default risk scenario. 5. Apply workload buffer: if the user reports available time, use only 70%-80% of it; otherwise keep the first week to one main timebox plus one optional elastic task. Mark elastic tasks as optional/允许放弃. 6. Build APP_DATA: include config, phases, dailyTasks, checkins: {}, and reviews: {}. Do not include sample progress. Store the nickname in config.user.name (小卷 fallback). Store config.output.fileNameBase as the sanitized filename base without .html: use the user's desired filename if provided, otherwise juanwang-{nickname}-{goal-keyword}-{startDate}. Preserve compatible fields; optional methodology notes may live under config.user or copy text, not required schema fields. 7. Create the HTML: copy templates/juanwang-skill.html, replace only the content between /*__APP_DATA_START__*/ and /*__APP_DATA_END__*/ (keep the markers), and write exactly one personalized .html file using config.output.fileNameBase + ".html". Filename safety rules: remove path separators and dangerous characters (/ \ : * ? " < > |), collapse spaces/punctuation into -, keep Chinese/English/numbers/-/_, trim edge -, cap near 80 characters, and avoid duplicate .html. When injecting APP_DATA, escape every </ inside string values as <\/ (a goal or note containing </script> MUST be written as <\/script>) — the initial block is not auto-escaped, and an unescaped </script> will close the script block early and break the whole page. 8. Validate (mandatory gate, do not skip): run node scripts/validate.mjs <path> and node scripts/smoke-test.mjs <path>; both must pass before delivery. If validate reports a <script>/</script> mismatch, locate the literal </ in your APP_DATA, escape it to <\/, and re-run. Then do the browser render check in workflows/validate-deliverable.md: open the file and confirm no raw source text leaks onto the page. 9. Deliver: provide the absolute path to the generated personalized .html file and tell the user they can double-click it or send it to a phone and open it in a browser. </process>

<success_criteria>

• User provided a concrete start date.
• Generated HTML contains exactly one initialized plan and no fake checkins.
• The plan includes scenario-bound If-Then plans, 2-minute starters, realistic timeboxes, buffer, and 7-10 day review loops.
• Day 1 and final day dates match duration and start date.
• Exactly one personalized .html file is delivered.

</success_criteria>

<required_reading> Read these before validation: 1. references/app-data-schema.md 2. references/failure-mechanisms.md 3. references/planning-methodology.md 4. references/html-runtime-contract.md </required_reading>

<process> 1. Run validation scripts: node scripts/validate.mjs <html> (static invariants) and node scripts/smoke-test.mjs <html> (runs real template logic: today mapping, streak, review merge, progress day). Run both on the template and on any generated personalized .html file. Fix all reported errors before delivery. 2. Check package shape: market package should have SKILL.md, workflows/, references/, scripts/ (validate.mjs + smoke-test.mjs), and templates/juanwang-skill.html. Do not include zip, preview image, QR code, manifest, or service worker as delivery assets. 3. Check SKILL.md: frontmatter name is lowercase and matches the skill folder name; description says when to use it; body uses XML tags and no markdown headings; routed files exist; SKILL.md stays under 500 lines. 4. Browser smoke test (required before delivery): actually open the generated HTML in a browser (or headless Chrome with --virtual-time-budget so the fadeIn animation settles), and confirm:

• the page renders fully with NO raw JS/source text leaking onto the page — a literal </script> anywhere in the script block (even inside a JS comment or string) closes the script early and breaks the whole page; validate.mjs guards this by checking <script>/</script> stay balanced
• new plan opens on today (not a stale selected day), 0 streak, 0% completion
• starter-only check-in counts toward streak
• manual jump to Day 30 does not mark all phases ready for review
• sync-to-HTML download works without fetch (including file://) and uses {fileNameBase}-v{timestamp}.html
• embedded APP_DATA.reviews survives when localStorage reviews are empty

</process>

<success_criteria>

• All package, schema, runtime, behavior, and low-friction methodology checks pass.
• Any failure includes the exact file and invariant to fix.

</success_criteria>