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 | $0.00012 | $0.01530 |
| Sonnet 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 11d 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.
- 11d 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 2mo ago), licensed MIT. It adds 23 tokens to every session and 3,061 once invoked, about $0.0001 per session on Opus 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.
Other skills, from other repositories
import
Import a tasks.md into the coco tracker as an epic with dependencies, and create matching issues in the configured issue tracker.
hotfix
Single-issue workflow for quick fixes and small changes that don't need full epic tracking. Creates a branch, implements the fix, commits with issue tracking, and closes.
execute
Execute the next available tracked task with TDD, pre-commit validation, PR workflow, AI code review, and issue tracker bridge sync. Primary execution interface for multi-session feature work.
council-review
Perform a rigorous Carmack Council code review. Use when explicitly asked to review code, do a "council review", "carmack review", or invoke /council-review. Carmack's philosophy chairs a council of domain experts — Troy Hunt (security), Martin Fowler (refactoring), Kent C. Dodds (frontend), Matteo Collina (Node.js)…
council-plan
Architect a feature with the Carmack Council before writing code. Use when explicitly asked to plan a feature, do a "council plan", "carmack plan", or invoke /council-plan. Carmack's philosophy chairs a council of domain experts — Troy Hunt (security), Martin Fowler (refactoring), Kent C. Dodds (frontend), Matteo…
test-architect
Map testable surfaces, audit existing tests for quality, and write test specifications that prevent AI shortcuts. Use when asked to "audit tests", "specify tests", "test architect", "map test coverage", or invoke /test-architect. Two modes — audit (evaluate existing tests against Beck's principles) and specify (write…