Skip to content

Add Vibe-Coding SOP (5-stage AI coding workflow rule) #342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
youngcintj wants to merge 2 commits into
base: main
Choose a base branch
from
+102 −0
Open

Add Vibe-Coding SOP (5-stage AI coding workflow rule) #342

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c266c5f
Add vibe-coding-sop Cursor rule (5-stage SOP)
youngcintj Jul 28, 2026
1dd2338
Add Vibe-Coding SOP to Documentation category
youngcintj Jul 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
101 changes: 101 additions & 0 deletions rules/vibe-coding-sop-cursorrules-prompt-file.mdc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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
Comment on lines +1 to +4

@coderabbitai coderabbitai Bot Jul 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '--- locate the file ---\n'
fd -a 'vibe-coding-sop-cursorrules-prompt-file\.mdc$' . || true

printf '\n--- git status/diff stat ---\n'
git diff --stat || true

printf '\n--- target file around frontmatter and mentions ---\n'
path="$(fd 'vibe-coding-sop-cursorrules-prompt-file\.mdc$' . | head -n 1 || true)"
if [ -n "${path:-}" ]; then
  wc -l "$path"
  sed -n '1,40p' "$path" | cat -n
  printf '\n--- rule title/self references ---\n'
  rg -n 'automatic|project|wide|alwaysApply|globs|Cursor|rule|prompt|sop' "$path"
fi

Repository: PatrickJS/awesome-cursorrules

Length of output: 258

🌐 Web query:

Cursor context rules yml md frontmatter alwaysApply globs documentation

💡 Result:

Cursor has transitioned to a directory-based system for managing AI instructions, using.mdc files within a.cursor/rules/ folder [1][2]. While the legacy.cursorrules file in the project root is still supported for backward compatibility, it is recommended to migrate to the new format for better scoping and organization [3][4][5]. ### Modern.mdc Rules System Project rules are now defined as.mdc (Markdown + metadata) files located in the.cursor/rules/ directory [1][4]. These files use YAML frontmatter to control their activation and scope [2][6]. ### Frontmatter Configuration Each.mdc file should contain a YAML frontmatter block at the top [2][7]. The three primary fields used to control rule application are: * description: A one-line summary that helps Cursor's agent decide whether the rule is relevant to the current task [1][4][6]. * globs: A list of file patterns (e.g., ["src//.ts", "styles/.css"]) that trigger the rule automatically when a matching file is in context [2][4]. * alwaysApply: A boolean flag [1][7]. * When true: The rule is always included in every chat session, and the globs/description fields are ignored [1][4]. * When false: The rule is applied conditionally based on matching globs or agent relevance [1][7]. ### Rule Activation Modes Based on these settings, rules generally fall into four activation categories [4][7]: 1. Always Apply: alwaysApply: true. Included in every request [4][7]. 2. Auto-attached: alwaysApply: false with globs provided. Activates when a file matching the glob is in context [1][4]. 3. Agent-requested: alwaysApply: false with a description provided (but no globs). The agent reads the description and determines if it is relevant [1][6][7]. 4. Manual: alwaysApply: false with no globs or description. The rule only activates when explicitly referenced (e.g., @-mentioning the rule in chat) [4][7]. Note: Plain.md files in the.cursor/rules/ folder are ignored by the rules system because they lack the required frontmatter [1][4]. If you prefer plain markdown without frontmatter, you can use AGENTS.md instead [1].

Citations:

Make the rule activate reliably across coding tasks.

With alwaysApply: false and globs: empty, the rule is agent-relevance/manual rather than project-wide. Set alwaysApply: true, or add explicit matching globs if this SOP should auto-attach only for certain task contexts.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/vibe-coding-sop-cursorrules-prompt-file.mdc` around lines 1 - 4, Update
the rule frontmatter for the SOP so it activates reliably across coding tasks by
setting alwaysApply to true; remove the empty globs configuration if it is no
longer needed, while preserving the existing description.

---

# Vibe-Coding SOP v1 — Cursor Rules

自动加载,适用整个项目。完整文档: https://github.com/youngcintj/vibe-coding-sop

## 工作流:5 阶段 + 4 横向 + 6 维

任何"写代码"任务(后端/前端/全栈/脚本),按这个流程走:

### 阶段 1:需求确认
- 不要一上来就写代码。先问清楚:需求边界(不做什么)、验收标准(用户用得顺的具体行为)、优先级(MVP vs 完整)
- 必产出:需求规格 + 风险点 + 后续建议
- 拍板:边界 / 验收标准 / 优先级
Comment on lines +13 to +18

@coderabbitai coderabbitai Bot Jul 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Enforce the advertised approval gate before claiming it.

The SOP and README promise that file writes are blocked until human approval, but the rule currently lacks an explicit no-mutation constraint.

  • rules/vibe-coding-sop-cursorrules-prompt-file.mdc#L13-L18: prohibit all file creation, modification, deletion, and renaming before approval.
  • README.md#L316-L316: retain the safety-gate description after the rule enforces it.
📍 Affects 2 files
  • rules/vibe-coding-sop-cursorrules-prompt-file.mdc#L13-L18 (this comment)
  • README.md#L316-L316
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/vibe-coding-sop-cursorrules-prompt-file.mdc` around lines 13 - 18,
Update the “阶段 1:需求确认” section in
rules/vibe-coding-sop-cursorrules-prompt-file.mdc to explicitly prohibit
creating, modifying, deleting, or renaming any files before human approval;
retain the existing approval-gate description in README.md at line 316 with no
direct change required.


### 阶段 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 / 文案 / 颜色)**:自动处理
Loading