name: mini-program-engineering-suite description: >- Orchestrate evidence-first engineering for WeChat and other mini programs from a vague idea or existing repository through project discovery, product specification, architecture, implementation, debugging, device adaptation, verification, and release readiness. Use when users ask to build a mini program from zero to one, take over an existing mini-program project, deliver a cross-stage feature, diagnose project status, coordinate development and testing, or judge whether a mini program is ready to upload or release. Enforces fact discovery, change boundaries, stage gates, evidence-calibrated status, sensitive-information redaction, and continuity after side questions. license: MIT compatibility: Requires Python 3.9+ for bundled scripts; framework adapters are optional and discovered read-only. metadata: version: "3.1.13" author: "Mini Program Engineering Suite contributors" maintainers: "Mini Program Engineering Suite contributors" language: "zh-CN" created: "2026-08-12" last_reviewed: "2026-09-01" review_interval_days: "90"

/mini-program-engineering-suite — 小程序工程开发套件

把小程序任务视为一条有阶段、有门禁、有证据的工程链路。先确认当前事实，再决定路由和动作；只把已经有证据支持的状态报告给用户。

启动顺序

1. 读取当前项目及上级目录中的 AGENTS.md、CLAUDE.md 或同类规则文件。
2. 读取 共享工程门禁、证据状态模型、判断与确认规则 和 脱敏规则。涉及中断恢复、资产或验证证据时，再分别读取 中断恢复协议、资产谱系记录 和 证据可采信规则；接管未知技术栈时可运行只读 scripts/capability_doctor.py 并按 验证能力矩阵 选择既有工具；涉及文档或对外输出时，再读取 公开与内部文档边界。
3. 判断这是新项目、已有项目，还是没有项目目录的咨询任务。
4. 已有项目若尚未建立本轮事实图，先使用 项目接管 Skill。在完成只读接管前，不修改代码。
5. 建立或恢复任务计划，记录原目标、当前阶段、完成证据和未完成项。

判断当前阶段

使用 路由与状态机 判断当前阶段。允许跳过与任务无关的阶段，但必须说明依据；不能因为已经写了代码就跳过验证。

当目标组件尚未实现时，明确报告套件当前能力边界；可以继续做安全的只读发现与任务拆解，但不要伪装成已调用不存在的组件。已实现组件既可由主 Skill 编排，也可独立使用；组件只交换阶段产物，不直接调用彼此脚本。

编排工程任务

新项目从 0 到 1

按 discovery → specification → architecture → implementation → verification → release-ready 推进。先澄清核心用户、问题和最小闭环，再选择技术方案。没有用户授权时，不提交审核、不发布、不创建付费资源。

已有项目开发或修复

先执行项目接管，获得事实图、风险、未知项和改动边界。只在范围明确后实施；对错误先复现并定位根因，对共享契约补相应验证。

发布前判断

分别核对源码、当前分支、构建产物、开发者工具加载版本、平台上传记录与正式环境证据。任一层缺少证据时，只报告到已经证明的状态。

执行门禁

• 未读取事实源，不修改已有项目。
• 未确认产品语义，不新增按钮、入口、状态、付费、广告或数据规则。
• 高影响视觉方案先给预览或候选方案，用户确认后再集成。
• 数据、权限、外部服务和不可逆操作先说明影响、失败策略与回滚条件。
• 工具异常、超时或中止后的在途动作先保持 unknown，刷新本地与外部事实，不盲目重放写操作。
• 资产变体与证据材料分别记录谱系、指纹、适用范围和不能证明的内容。
• 已实现必须进入与风险匹配的验证；本地通过不能推导出真机、云端或发布通过。
• 对外输出和安装包运行 python3 scripts/scan_sensitive_content.py <path> --format json。

中途问题与连续执行

用户提出中途问题时，先回答问题，再判断它是否改变原目标。若没有改变，恢复原计划与未完成步骤；若改变，更新计划并说明受影响阶段。不得把中途问题当成默默终止原任务的理由。

输出契约

阶段性或最终汇报至少包含：

1. 当前结论与工程阶段。
2. 已完成的动作及对应证据。
3. 未执行、未验证或待用户确认的内容。
4. 当前改动边界与残余风险。
5. 下一步动作。

使用 证据状态模型 中的状态词。用户明确验收前，不使用 accepted（已正式验收）；没有平台正式证据时，不使用 released（已正式发布）。

能力地图

• 基础层（3.0 新增，领域无关，可独立分发）：evidence-first-engineering —— 证据状态模型、工程门禁、判断与确认规则、脱敏规则与四个交付模板的通用版本，位于 foundation/；本套件是其第一个垂直应用，scripts/check_foundation_equivalence.py 保证通用版与 shared/ 原版不分叉。
• 项目接管 Skill：只读建立项目事实图、技术栈、风险、未知项和改动边界。
• 产品规格 Skill：将模糊想法收敛为范围、流程、状态矩阵与可测试验收标准，不发明产品逻辑。
• 工程架构 Skill：把稳定产品语义映射为模块、状态源、数据、接口、权限、失败策略与 ADR。
• 微信平台适配 Skill：只读核对工具、构建、权限、隐私和发布证据层；时效性规则查微信官方当前资料。
• 平台事实层（按目标平台路由，doctor 的 target_platforms 决定入口）：
  • 微信：platforms/wechat/（证据层、核对清单、隐私矩阵、规则地图 与 核验标注；支持确定性漂移检测）；
  • 支付宝：规则地图 与 核验标注（官方文档为客户端渲染 SPA，确定性指纹不可观测，保鲜依赖运行时查官方与用户上报，规则地图标 manual-only）；
  • 抖音：规则地图 与 核验标注（官方文档为客户端渲染同构壳页，确定性指纹不可观测文章内容，同样标 manual-only）；
  • 未收录平台：无平台事实层，平台触点步骤一律查官方当前资料并保持 unknown，不猜测。
• 工程流程层遇到平台触点时引用对应平台事实层，不内置平台规则；事实标注规范、检测模式与「运行时只读 / 刷新走 PR」的基线治理边界见 platforms/README.md。
• 工程实现 Skill：在明确边界内保护用户改动，以测试驱动小步实施并交付验证入口。
• 界面与真机适配 Skill：按参考目标处理预览、确认、集成、屏幕/内容边界、手势和真机证据。
• 问题调试 Skill：从最小复现、竞争假设与判别实验定位根因，并覆盖同类状态回归。
• 工程验证 Skill：按风险分层执行静态、单元、集成、状态、真机、云端和发布验证，报告已执行、未执行与残余风险。
• 发布治理 Skill：核对版本、构建、安全、权限隐私、回滚和各发布层证据；默认只读，外部动作逐项授权。

每个组件均包含独立的 agents/openai.yaml、工作流参考和可复用交付模板，可脱离主套件安装和触发；主 Skill 负责跨阶段编排、计划连续性和证据状态一致性。

共享模板与门禁

• 项目接管模板：统一接管输出。
• 实施计划模板：记录范围、步骤与门禁。
• 验证报告模板：区分检查范围与证据层级。
• 发布清单模板：核对发布链路，但不授权外部操作。
• 共享工程门禁、证据状态模型、判断与确认规则、脱敏规则 和 公开与内部文档边界：统一约束所有组件。

维护脚本与公开包

• VERSION：套件语义版本事实源。
• scripts/validate_suite.py：检查主 Skill、九个分 Skill、共享层、公开文档、版本事实源、链接、frontmatter、界面元数据和占位内容。
• scripts/check_i18n_readme_structure.py：检查六种语言 README 的核心章节顺序，防止安装、验证、包完整性、版本和许可说明漂移。
• scripts/scan_sensitive_content.py：扫描公开包候选中的真实 AppID、云环境 ID、凭证形态、用户路径、邮箱、手机号、JWT、COS bucket、私钥块与二进制命中。
• scripts/export_public_package.py：按明确公共路径清单执行全候选敏感扫描和确定性导出，未知文件默认拒绝，并生成相对路径哈希清单。
• scripts/verify_public_package.py：只读取收到的公共包，独立复算文件大小与 SHA-256，并拒绝缺失、篡改、新增、非法路径或损坏清单。
• scripts/summarize_evaluations.py：把发布门禁的评测产物汇总为只含结论、关键指标与审计元数据的公开摘要，不含提示词、回复或夹具内容。
• 评测证据说明：说明三层评测、判定与独立签署各自能证明什么，以及各版本公开摘要政策。
• scripts/capability_doctor.py：只读识别原生/Taro/uni-app、既有脚本、测试依赖、分包和工具事实；不执行命令、不安装依赖、不输出配置值。
• install.sh：从源码或已导出的公开包中安装套件，默认不覆盖已有目录，项目级安装必须显式传入目标项目路径。
• .github/workflows/ci.yml 与 .github/workflows/release.yml：分别守住常规变更门禁和版本化发布包门禁；Release 附带压缩包、package-manifest.json 与 SHA256SUMS。

可靠性方法论资源

• 中断恢复协议：中断后把在途动作保持为 unknown，刷新事实并阻止盲目重放。
• 资产谱系记录：追踪原始/衍生资产、处理、目标槽位、文件指纹、批准和替换关系。
• 证据可采信规则：判断证据来源、版本、完整性、适用结论和不能证明的内容。
• scripts/capability_doctor.py：只读识别原生/Taro/uni-app、既有脚本、测试依赖、分包和工具事实；不执行命令、不安装依赖、不输出配置值。
• 质量证据矩阵：记录包体/分包、启动/首屏、运行错误和发布后观察窗。

小程序开发工程技能套件

小程序开发工程技能套件 是一套面向 Agent 的技能套件，专为小程序从 0 到 1 开发、已有项目接管和上线前治理设计。它把「先弄清楚要做什么、怎么做、做到哪一步、有没有证据」这条链路拆成可执行的工程流程，帮助不熟悉小程序开发的人在 Agent 辅助下少踩坑、少返工、不越权。

英文名：Mini Program Engineering Skill Suite。

核心亮点

• 三平台事实层：微信 / 支付宝 / 抖音的平台规则单一事实源，capability doctor 自动识别项目技术栈与目标平台；检测能力如实分级——微信支持确定性指纹监测，支付宝 / 抖音依赖执行时查官方与用户上报，不假装能自动检测（见平台规则保鲜）。
• 平台规则保鲜流水线：执行层即时对齐官方现行文档，内容层每周自动漂移检测（指纹比对 → 抽取 → 影子审计 → 裁决 issue）；本地安装的版本稍旧，也不会导致任务按过期规则执行（见平台规则保鲜）。
• 真实 Agent CLI 全量验证：发布门禁的三层评测（结构 / 路由 / 行为）与独立签署在真实 Agent CLI 会话中全量执行——早期版本经 Codex CLI 实测验收，现行评测引擎可插拔（Codex CLI / Claude Code / Gemini / OpenAI 兼容 API），跨引擎通过是更强证据（见验证与 EVALUATIONS.md）。
• 证据优先工程纪律：状态必须由匹配证据支撑，没有证据就如实标注 unknown；3.0 起这套纪律沉淀为领域无关的基础技能层 foundation/，可被任何 Agent 工程套件复用（见设计原则）。
• 分层评测 + 独立签署：tier1 结构 / tier2 路由 / tier3 行为三层评测、with-skill 与 baseline 独立判定、held-out 批冻结前不可用于调参，门禁全 PASS 才发布（见 EVALUATIONS.md）。
• 供应链级发布治理：SHA256 + 双 manifest + fail-closed 出包 + 接收端复验 + 敏感信息扫描清零，六语言 README 结构一致性由脚本守护（见包完整性）。

32 秒看懂这套技能

如果你想先快速了解这套 Skill 解决什么问题、从哪里沉淀出来、适合怎么用，可以先看这个 32 秒说明视频。

https://github.com/user-attachments/assets/d382951e-5175-48be-b0c0-44ba210706f1

视频仅用于说明这套 Skill 的定位、来源和使用边界。

项目状态

本仓库是这套套件的公开项目主页，已通过 MIT License 开源发布。任何人都可以查看、使用、修改和再分发，具体条款见 LICENSE。

它解决了什么问题

做小程序这件事，对没接触过的人来说远比看上去复杂。真正难的往往不是写某一段代码，而是从一开始就不知道该先确认什么、哪些决策会影响后面、什么时候该停下来验证，以及上线前哪些事不能凭感觉跳过。

工具链分散、平台规则琐碎、上线审核环环相扣。无论你是第一次做小程序的产品经理 / 创业者，还是临时接手老项目的开发者，往往会在这些地方反复踩坑：

• 环境装到一半报错、配置前后不一致；
• 上线之后才发现权限漏配，临时补隐私协议；
• UI 在不同机型上严重错位，真机表现和模拟器完全两个样子；
• 提审版本和发布版本混淆，误把没验收的代码送审；
• 误操作把没确认的改动推到了线上，要紧急回滚……

小程序开发工程技能套件 把这些容易踩坑的环节打包成 Agent 可以直接执行的工程能力：先梳理目标和边界，再形成产品规格和工程方案，然后小步实现、分层验证、收口发布风险。它不替你做商业和产品决定，但能让一个不懂小程序开发的人在 Agent 的辅助下走完从 0 到 1 的关键路径，知道下一步该做什么、为什么做、做到什么程度才算有证据。

真实项目来源：语宠精灵

这套 Skill 不是从抽象教程里写出来的，而是从真实微信小程序「语宠精灵」的长期开发协作中提炼出来的。它沉淀的是小程序从 0 到 1 的产品拆解、工程实施、验证验收、发布准备和证据管理方法。

「语宠精灵」仅作为真实来源案例展示。本仓库只公开可复用的小程序开发工程方法，不包含该小程序源码、AppID、云资源、私有配置、业务数据、审核状态或内部开发记录。小程序二维码仅用于体验真实案例，扫码结果以微信平台当前状态为准。

它帮助 Agent 做到这些事

• 接手项目：先摸清现有的项目状态再动手改，避免破坏已有功能；
• 澄清需求：把模糊的产品想法转成可以验收的明确规格；
• 沉淀决策：把已经定了的产品决策落到架构、数据、接口、权限和兜底逻辑上；
• 安全改代码：在保留原有成果的前提下，做小颗粒、可回滚的改动；
• 逐级验证：把 UI 预览、用户确认、集成验证、机型适配、最终验收当成互相不等价的环节；
• 用证据排错：依据真实证据定位问题，而不是凭感觉猜；
• 如实汇报：老老实实报告当前验证到了哪一步，不夸大也不省略；
• 平台规则保鲜：执行发布、提审、隐私申报等平台触点步骤时，按官方现行规则执行，不被套件内置的旧规则带偏（见下文「平台规则保鲜」）。

平台规则保鲜

平台规则会持续变化，任何写死在技能里的规则都会过期。这套套件从 2.0 起采用「执行层即时保鲜，内容层受控进化」：

• 执行时永远以官方为准：涉及上传、提审、审核、发布、隐私申报、配额等平台触点步骤时，Agent 会先核对套件记录的平台事实是否仍然新鲜（每条事实带核验日期与来源指纹）；过期或高风险步骤直接查官方现行文档再执行。因此你本地安装的版本稍旧，也不会导致任务按过期规则执行——版本旧只影响查官方的频率，不影响正确性。
• 套件内容受控升级：维护方通过漂移检测工具（对官方文档做指纹比对）发现规则变化后，经多轮独立审计提交更新；你可以在 Issues 用 Platform rule drift 模板上报你发现的规则变化（自愿，预填好格式）。
• 想用最新版教材：从 Releases 下载新包并 install.sh --force 重装即可；套件永远不会静默自动更新你的本地安装。

平台事实与规则地图位于仓库 platforms/ 目录，当前覆盖微信、支付宝、抖音三个平台：微信支持确定性指纹监测（每周自动漂移检测）；支付宝与抖音的官方文档为客户端渲染，确定性指纹无法观测内容变化，如实标注为 manual-only——保鲜依赖执行时查官方与用户上报，不假装能自动检测。未收录的平台一律查官方并保持 unknown，不猜测。

能力清单

设计原则

• 事实先于动作：没摸清现状，别动项目。
• 证据对齐状态：报什么状态，就得有什么状态被真实验证过。
• 环节边界明确：预览、实现、构建、上传、审核、验收、上线、回滚 —— 这些环节互相不可替代。
• 外部动作独立授权：上传、提交审核、发布、云端改动、仓库公开放开等外部写动作，分别独立授权。
• 私有信息隔离：对外分发的包，必须先过脱敏和敏感信息检查。
• 真机才是真相：本地检查、静态检查、模拟器都不能替代真机、体验版、生产环境的真实证据。
• 平台规则保鲜：执行以官方现行规则为准，套件内置规则只作缓存不作权威（2.0 起）。

适用场景

这套套件适合在以下场景里辅助 Agent 完成小程序工程任务 —— 尤其是当项目已经累积了产品决策、UI 约定、平台约束和发布风险之后。

典型的使用场景包括：

• 接手一个陌生的小程序仓库；
• 从零开始规划一个新小程序；
• 在不破坏已有验收成果的前提下实现一个新功能；
• 检查项目当前是否到了可以上传、提审或发布的状态；
• 把反复出现的工程判断沉淀成可复用的 Agent 行为。

使用方法

1. 安装到支持 Agent Skill 的应用

推荐优先从 GitHub Releases 下载已经导出的公开包；如果你想查看源码、参与修改或让 Agent 自动处理，也可以克隆本仓库到支持 SKILL.md 或项目规则的 Agent 应用目录中。

如果你不想手动执行命令，可以先把下面这句话复制给自己正在使用的 Agent。只要它有联网、Git 和本地文件写入权限，它通常可以自动判断安装位置并完成安装：

https://github.com/NocodeMrLi/mini-program-engineering-skill-suite.git 帮我安装这个技能

如果 Agent 无法访问本地文件系统，或你想自己控制安装位置，可以使用下面的安装器或命令行方式。

安装器示例：

git clone https://github.com/NocodeMrLi/mini-program-engineering-skill-suite.git
cd mini-program-engineering-skill-suite
bash install.sh --target auto

如果要安装到某个项目的 GitHub Copilot 或 Cursor 规则目录，请显式传入项目路径：

bash install.sh --target codex
bash install.sh --target agents
bash install.sh --target copilot --project /path/to/your-mini-program-project
bash install.sh --target cursor --project /path/to/your-mini-program-project

其中 --target codex 对应 ~/.codex/skills，--target agents 对应 ~/.agents/skills。

安装器默认不覆盖已有目录；需要替换时加 --force，旧目录会先移动为带时间戳的备份。

通用安装示例：

git clone https://github.com/NocodeMrLi/mini-program-engineering-skill-suite.git \
  ~/.agents/skills/mini-program-engineering-suite

Claude Code 示例：

git clone https://github.com/NocodeMrLi/mini-program-engineering-skill-suite.git \
  ~/.claude/skills/mini-program-engineering-suite

GitHub Copilot 项目级安装示例：

mkdir -p .github/skills
git clone https://github.com/NocodeMrLi/mini-program-engineering-skill-suite.git \
  .github/skills/mini-program-engineering-suite

2. 在新会话中调用

安装后重新打开一个 Agent 会话，直接描述任务即可。支持显式调用主 Skill：

/mini-program-engineering-suite 我想从 0 到 1 做一个微信小程序，请先帮我梳理产品范围和开发步骤。

也可以直接描述阶段任务，让 Agent 路由到对应组件：

帮我接手这个小程序项目，先只读看清现状，不要改代码。

这个小程序准备提审了，帮我做发布前检查，但不要上传、不要提交审核。

3. 按阶段交付

推荐把任务拆成「产品规格 → 架构方案 → 实现 → UI / 真机适配 → 验证 → 发布准备」几个阶段推进。每一阶段都要求 Agent 说明：

• 当前结论是什么；
• 依据哪些文件、测试、截图、日志或平台证据；
• 哪些内容还没有验证；
• 下一步需要你确认什么。

已有项目一定先做只读项目摸排，再决定是否修改。上传、提交审核、发布、云端改动、仓库权限变更等外部动作，都需要单独授权。

它不会做什么

这套套件不会自动安装项目依赖、创建云端资源、上传包、提交审核、发布版本，或改动线上状态。它可以准备好证据和操作指引，但每个外部动作都仍需独立授权。

验证

当前套件版本在发布前会经过：结构校验、敏感信息扫描、对公包导出的确定性检查、清单核对、路由评估、行为评估和独立终审。

CI 还强制全仓脚本语句覆盖率不低于 85%，评估门禁、SemVer 建议器、敏感扫描和接收端复验四个关键模块的分支覆盖率不低于 90%。patch 版本复用历史评测时，必须提交由仓库信任公钥验证的签名声明，绑定候选 tag、来源 tag/commit、八阶段 PASS 摘要及候选行为/评测基架指纹；任一绑定不一致即阻断发布。

评测分层、证据边界与各版本公开摘要见 EVALUATIONS.md。评测引擎与模型可插拔（codex / claude / gemini / OpenAI 兼容 API 任一可用者均可充当被测与判定引擎），审计元数据如实记录当次使用的引擎与模型；跨引擎通过是更强证据，分数不跨引擎直接比较。

接收一个包时，通过它的 package-manifest.json 校验完整性；源码工作副本在分发前会先经过校验和敏感扫描。

如果你克隆了本仓库，可以在本地运行零依赖自检：

python3 -m unittest discover -s tests -q
python3 scripts/validate_suite.py .
python3 scripts/check_i18n_readme_structure.py .
python3 scripts/scan_sensitive_content.py . --format json

发布或分发前，再执行一次确定性导出与接收端复验：

export_dir="$(mktemp -d)"
python3 scripts/export_public_package.py . --output "$export_dir/package"
python3 "$export_dir/package/scripts/verify_public_package.py" "$export_dir/package"

这些命令也是 GitHub Actions CI 的核心检查项。

包完整性

请优先使用 GitHub Releases 这样的 可信来源 中的版本化发布包，不要混用不同版本的文件；仓库中的 VERSION 是版本号的唯一权威。每个 Release 会附带公开包压缩文件、package-manifest.json、gate-summary.json 和覆盖三者的 SHA256SUMS，用于确认下载产物没有被传输损坏或混入其他版本文件。仓库已启用不可变 Release：全部附件在草稿阶段附齐，发布后 tag 与附件不可替换；gate-summary.json 可用于回读本次 S