Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/xushuodasd/VIBE-Claude-Pluginnpx agentmods add skills/xushuodasd/vibe-claude-plugin/vibe-planWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/xushuodasd/vibe-claude-plugin/vibe-plan)<a href="https://agentmods.dev/skills/xushuodasd/vibe-claude-plugin/vibe-plan"><img src="https://agentmods.dev/badge/skills/xushuodasd/vibe-claude-plugin/vibe-plan/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/xushuodasd/vibe-claude-plugin/vibe-plan"><img src="https://agentmods.dev/badge/skills/xushuodasd/vibe-claude-plugin/vibe-plan.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00023 | $0.03061 |
| Opus 5.5 | $0.00009 | $0.01224 |
| Sonnet 5.5 | $0.00005 | $0.00612 |
| Haiku 4.5 | $0.00002 | $0.00306 |
Grade A, and why
vibe-plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 279 lines — stays where its author put it; the contents beside it link to each section on GitHub.
项目阶段开发计划工作流
1. 文档目的
规范项目阶段开发计划的制定标准,确保按照需求文档、框架设计文档和API文档,将大项目功能拆分为模块化的最小可实现功能,并划分清晰的开发阶段。
2. 工作流结构
一个完整的项目阶段开发计划工作流应包含:
- 基本信息:名称、目标
- 前置步骤:文档检查、依赖项确认
- 执行步骤:详细的执行流程和顺序
- 执行建议:专业建议和注意事项
- 成功标准:任务完成的判定条件
- 失败处理:异常情况的应对措施
- 输出成果:明确的交付物和保存位置
3. 执行要求
- 严格按照步骤执行
- 与用户保持深度沟通
- 记录关键信息和结果
- 遇到异常时按失败处理机制执行
- 确保输出成果符合用户预期
4. 文档管理
- 执行后根据实际情况更新文档
- 进行版本管理,确保使用最新版本
工作流程
前置步骤:文档检查
-
检查需求文档:
- 确认项目需求文档是否存在
- 如果不存在,提示用户先准备需求文档
-
检查框架设计文档:
- 确认框架设计文档是否存在
- 如果不存在,提示用户先准备框架设计文档
-
检查API文档:
- 确认API文档是否存在
- 如果不存在,提示用户先准备API文档
-
读取相关文档:
- 读取需求文档,了解项目的整体需求和功能点
- 读取框架设计文档,了解技术架构和技术栈
- 读取API文档,了解接口设计和数据结构
第一步:功能拆解与模块化
-
功能点识别:
- 基于需求文档和框架设计文档和API文档,识别所有功能点
- 基于需求文档和框架设计文档和API文档的描述和优先级标识,自行分析确定功能点的优先级和重要性
- 优先考虑核心业务功能和用户体验关键路径
-
最小可实现功能拆分:
- 将每个功能点拆分为最小可实现的模块
- 确保每个模块都有明确的功能边界和职责
-
模块依赖关系分析:
- 分析模块之间的依赖关系
- 确定模块的实现顺序
-
技术可行性评估:
- 评估每个模块的技术实现难度
- 基于框架设计文档和技术栈,自行分析确定技术方案
- 优先选择成熟稳定的技术实现方式
第二步:阶段划分
-
阶段数量确定:
- 基于功能模块的数量和复杂度,自动确定合理的阶段数量
- 确保每个阶段的任务量适中,减轻AI的处理压力
- 原则上每个阶段的功能模块数量不超过5个
-
MVP阶段定义:
- 确定MVP(最小可行产品)阶段的功能范围
- 选择核心功能和必要的基础功能
- 确保MVP阶段能够展示产品的核心价值
- 任务量控制在最小可行范围内
-
后续阶段定义:
- 根据功能模块的优先级和依赖关系,划分后续阶段
- 每个后续阶段的功能模块数量控制在合理范围内
- 确保每个阶段都有明确的目标和可交付成果
-
阶段时间估算:
- 基于功能复杂度和技术实现难度,估算每个阶段的开发时间
- 每个阶段的开发时间不宜过长,确保AI能够高效处理
- 制定合理的时间计划,确保项目能够按时完成
第三步:前端开发计划制定
-
MVP阶段前端开发计划:
- 明确MVP阶段前端需要实现的功能模块
- 详细说明每个模块的开发要求和技术实现
- 确定前端与后端的交互方式
-
后续阶段前端开发计划:
- 针对每个后续阶段,分别制定前端开发计划
- 明确每个阶段前端需要实现的功能模块
- 详细说明每个模块的开发要求和技术实现
- 确定前端与后端的交互方式
-
前端测试计划:
- 制定每个阶段的前端测试计划
- 确保前端功能与后端API正确对接
第四步:后端开发计划制定
-
MVP阶段后端开发计划:
- 明确MVP阶段后端需要实现的功能模块
- 详细说明每个模块的开发要求和技术实现
- 确定API接口的设计和实现
-
后续阶段后端开发计划:
- 针对每个后续阶段,分别制定后端开发计划
- 明确每个阶段后端需要实现的功能模块
- 详细说明每个模块的开发要求和技术实现
- 确定API接口的设计和实现
-
后端测试计划:
- 制定每个阶段的后端测试计划
- 确保API接口与前端需求正确对接
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 279 lines · 23 tokens per session scan A 7ce8bf043f96
vibe-plan is a skill published in the GitHub repository xushuodasd/VIBE-Claude-Plugin (4 stars, last pushed 4mo ago), licensed MIT. It adds 23 tokens to every session and 3,061 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
vibe-plan compared with skills from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| vibe-planxushuodasd/VIBE-Claude-Plugin | Skill | 4 | 4mo ago | MIT | A | 23 | Claude Code |
| importskullninja/coco-workflow | Skill | 7 | 23d ago | MIT | A | 26 | Claude Code |
| hotfixskullninja/coco-workflow | Skill | 7 | 23d ago | MIT | A | 36 | Claude Code |
| authoring-a-skillNew1Direction/korgex | Skill | 5 | 25d ago | MIT | A | 25 | Claude Code, Codex |
| skill-creatorcnfjlhj/ai-collab-playbook | Skill | 462 | 26d ago | none | A | 46 | Codex |
| academic-paper-helpercnfjlhj/ai-collab-playbook | Skill | 462 | 26d ago | none | A | 42 | Claude Code, Codex |
| paper-review-pipelinecnfjlhj/ai-collab-playbook | Skill | 462 | 26d ago | none | A | 63 | Claude Code, Codex |