From c266c5f170f2b8d845f3795da68031d925d430f1 Mon Sep 17 00:00:00 2001
From: youngcintj <youngcintj@163.com>
Date: Tue, 28 Jul 2026 16:45:59 +0800
Subject: [PATCH 1/2] Add vibe-coding-sop Cursor rule (5-stage SOP)

---
 ...ibe-coding-sop-cursorrules-prompt-file.mdc | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 rules/vibe-coding-sop-cursorrules-prompt-file.mdc

diff --git a/rules/vibe-coding-sop-cursorrules-prompt-file.mdc b/rules/vibe-coding-sop-cursorrules-prompt-file.mdc
new file mode 100644
index 00000000..def8a66f
--- /dev/null
+++ b/rules/vibe-coding-sop-cursorrules-prompt-file.mdc
@@ -0,0 +1,101 @@
+---
+description: A 5-stage vibe-coding standard operating procedure (SOP) for Cursor — requirements → tech eval → development → testing → review. Includes a safety gate that blocks file writes until the plan is approved by the human, and produces a reusable design system so generated UI stays consistent instead of "AI slop".
+globs: 
+alwaysApply: false
+---
+
+# Vibe-Coding SOP v1 — Cursor Rules
+
+自动加载,适用整个项目。完整文档: https://github.com/youngcintj/vibe-coding-sop
+
+## 工作流:5 阶段 + 4 横向 + 6 维
+
+任何"写代码"任务(后端/前端/全栈/脚本),按这个流程走:
+
+### 阶段 1:需求确认
+- 不要一上来就写代码。先问清楚:需求边界(不做什么)、验收标准(用户用得顺的具体行为)、优先级(MVP vs 完整)
+- 必产出:需求规格 + 风险点 + 后续建议
+- 拍板:边界 / 验收标准 / 优先级
+
+### 阶段 2:技术评估
+- 关键技术选型走 6 维评估矩阵:
+  | 维度 | 权重 |
+  |---|---|
+  | 功能匹配 | 30% |
+  | 团队熟悉度 | 20% |
+  | 性能/可扩展 | 15% |
+  | 维护性 | 15% |
+  | 生态/集成 | 10% |
+  | 长期成本 | 10% |
+- 输出:推荐方案 + 1-2 备选 + 各自优劣
+- 拍板:技术选型
+
+### 阶段 3:开发
+**第一件事:Git 初始化**
+- 项目第一天:`git init` + 写 `.gitignore`(.env / .bak / __pycache__ / node_modules 必 ignore)
+- 大变更必打 tag(semver v0.X.0 / v0.X.Y)
+- 回滚优先 `git checkout <tag> -- <path>`,不靠文件备份 + regex 删
+- 删文件用可恢复删除工具(`mavis-trash` Mavis 生态 / `trash-cli` npm i -g trash-cli / 系统回收站),绝不 `rm -rf`
+
+**后端开发**:
+- API 设计要稳(类型契约清晰,边界明确)
+- 凭记忆编码前先看官方文档
+- 安全审查(输入验证/认证/数据存储)
+
+**前端开发**:
+- 抗 AI slop,审美在线(参考设计系统,不是凭感觉)
+- 第一个功能必出 `docs/design-system.md`(配色/字号/间距/圆角/组件/动效)
+- 改设计规范要 PM 拍板
+
+**增量交付**:
+- 每完成小功能就 commit,不要攒一堆一起提交
+- 大变更(影响 ≥3 文件)前先报告 PM
+
+### 阶段 4:测试
+- 必出测试计划(覆盖功能/性能/兼容性/异常路径)
+- **必出串行测试用例**:用户按顺序点完一遍,快速确认主功能
+- 不靠 LLM 自检完成度,用 Playwright / curl 实测验证
+
+### 阶段 5:定期代码审查
+- 触发:累计 commit ≥ 20 / 大版本前 / 用户主动
+- 报告三件套:
+  1. 优化点(明确推荐改)
+  2. 没把握的地方(我担心,你来定)
+  3. 风险点(知道但暂时没解)
+- PM 拍板:全部修 / 部分修 / 暂不修 / 改设计规范
+
+## 4 个横向要求(每步必走)
+
+- **A. 执行思路**:做了什么 / 怎么做的 / 关键决策
+- **B. 风险点**:可能踩的坑 / 边界情况 / 已知问题
+- **C. 后续建议**:下一步 / 类似项目借鉴
+- **D. 强制 Git**:见上方
+
+## 报告格式(每步必给)
+
+```
+## [阶段 X] 执行报告
+
+### 执行思路
+- ...
+
+### 风险点
+- ...
+
+### 后续建议
+- ...
+```
+
+## 必拍板点(任何阶段遇到都要问,不擅自做主)
+
+- 需求边界 / 验收标准 / 优先级
+- 技术选型 / 库 / 方案
+- 改 schema / 业务阈值 / LLM prompt persona / UI 重要位置
+- 设计规范变更
+- 代码审查后的修缮决策
+
+## 不适用场景(可跳过部分流程)
+
+- **PoC 一次性**:可跳过 Git 强制 + 评估矩阵
+- **用户明确说"你随便改"**:可跳过拍板环节
+- **小修改(typo / 文案 / 颜色)**:自动处理

From 1dd2338457dc595f90f437921a2f83c288f25bb7 Mon Sep 17 00:00:00 2001
From: youngcintj <youngcintj@163.com>
Date: Tue, 28 Jul 2026 16:46:56 +0800
Subject: [PATCH 2/2] Add Vibe-Coding SOP to Documentation category

---
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index 8204dac5..5d73865a 100644
--- a/README.md
+++ b/README.md
@@ -313,6 +313,7 @@ By adding selected `.mdc` files to `.cursor/rules/`, you can use these rules dir
 - [DevSecOps, SSDLC, and AppSec](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/security-devsecops-ssdls-appsec.mdc) - Secure coding, secret handling, dependency hygiene, authentication, authorization, security testing, and compliance documentation.
 
 ### Documentation
+- [Vibe-Coding SOP](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/vibe-coding-sop-cursorrules-prompt-file.mdc) - A 5-stage standard operating procedure for AI-assisted coding (requirements to tech eval to development to testing to review) with a safety gate that blocks file writes until the plan is approved, plus a reusable design system to keep generated UI consistent.
 
 - [Gherkin Style Testing](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/gherkin-style-testing-cursorrules-prompt-file.mdc) - Behavior-driven scenarios and acceptance criteria.
 - [How-To Documentation](https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/how-to-documentation-cursorrules-prompt-file.mdc) - Task-oriented guides and procedural documentation.