القائمة
Use when evaluating whether a project should continue, be refactored, rebuilt, forked, or abandoned — for both own projects and external/third-party codebases
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when the user wants to classify dirty changes, create serial commits, split work into one or more PRs, or publish the current flow without merging it.
Use when the user wants to resume work on an existing branch or flow. Reads context, executes the next step, reviews the result, and reports to the user before proceeding. Equivalent to superpowers:executing-plans, using vibe3 as the execution backend.
Use when you need an overview of the Vibe Center project, its implementations (vibe2 shell and vibe3 python), the available commands, and the standard development workflow. This is the meta-skill that orients any agent to the project.
Use when starting or switching to a new human-collaboration task. Confirm the target issue, bootstrap the corresponding dev/issue flow scene, and hand off to the chosen implementation workflow. Do not use for resuming an existing branch; use vibe-continue instead.
Use after `scripts/install.sh` to guide users through machine-level setup, dependency checks, Claude/Codex toolchain readiness, and core feature introduction. Interactive onboarding for new users. Delegates diagnostics to `vibe doctor` and `vibe keys check`. Do not use for project-level configuration (use vibe-project-check instead).
Use after `vibe init` to verify target-project configuration completeness, tool availability, and environment readiness. Interactively prompts user to fill missing items. Orchestrates existing commands without adding Python code. Supports cross-project vibe3 readiness verification (Phase 5-8). Do not use for system-level installation issues (use vibe-onboard instead).
| name | vibe-audit |
| description | Use when evaluating whether a project should continue, be refactored, rebuilt, forked, or abandoned — for both own projects and external/third-party codebases |
| metadata | {"category":"discipline","triggers":"evaluate, audit, refactor-or-rebuild, fork-or-build, architecture review, code quality, should I use this, is this worth it, project evaluation"} |
| input_examples | [{"prompt":"评估一下这个外部的开源项目是否可以直接复用","call":"vibe-audit - track: B (External Project)"},{"prompt":"我们的这个仓库现在这套引擎架构还要不要推翻重构","call":"vibe-audit - track: A (Own Project)"}] |
Project-level viability assessment. NOT code review (style/linting), NOT security audit.
Answers one question: What should we do with this codebase?
Two tracks depending on ownership:
Behavioral rules (anti-sycophancy, language, session discipline) are in ~/.agents/AGENTS.md. This skill does not repeat them.
1. Determine Track (A or B)
2. Quick Scan (5 min, automated, no interaction)
3. Deep Audit (on request, 11 dimensions)
4. Decision + Asset Extraction
5. Output Plan to ~/.agents/plans/
| Signal | Track |
|---|---|
| "我们的项目"、"这个项目要不要重构" | A — 自有项目 |
| "这个库好不好用"、"要不要 fork"、"评估一下这个开源项目" | B — 外部项目 |
| 不确定 | 问用户 |
Automated. No interaction. Both tracks共用。
执行步骤:
find src/ lib/ -name '*.py' -o -name '*.ts' -o -name '*.js' | xargs wc -l，按目录汇总git log --oneline --since="6 months ago" | wc -l，最近贡献者数量Quick Scan 输出格式:
## 基本指标
- 总行数: [X] 行（src/ [Y] 行，tests/ [Z] 行）
- 文件数: [N]
- 依赖数: [M]
- Git 活跃度: [近6月 commits] / [贡献者数]
- 最大文件: [file] ([lines] 行)
## 一句话裁决
[EMOJI] [verdict]
## 三大问题
1. [issue 1]
2. [issue 2]
3. [issue 3]
## 初步建议: [Track A 裁决 or Track B 裁决]
用户确认需要深入分析后执行。逐维度打分。
"一个合格工程师从零实现同样功能，大约需要多少行代码？"
没有这个基准，后续所有判断都是直觉，不是工程分析。
| # | 维度 | 核心问题 | 评级 |
|---|---|---|---|
| 1 | 技术选型 | 语言/框架是否匹配问题规模？换个人会选同样的栈吗？ | 🟢🟡🔴 |
| 2 | 目标偏离 | 文档说的 vs 代码做的，偏离度百分比。>30% 红灯 | 🟢🟡🔴 |
| 3 | 过度工程 | 解决了项目不存在的问题的抽象层有几个？ | 🟢🟡🔴 |
| 4 | 价值密度 | 核心业务逻辑行数 / 总行数。<10% = 全是脚手架 | 🟢🟡🔴 |
| 5 | 文档一致性 | README 承诺的功能，代码实际实现了多少？ | 🟢🟡🔴 |
| 6 | 死代码率 | 没有调用者的函数/模块占比。>20% 红灯 | 🟢🟡🔴 |
| 7 | 依赖健康 | 造轮子 vs 过度依赖的平衡。有无脆弱的自制解析器？ | 🟢🟡🔴 |
| 8 | 测试质量 | 测试在验证行为还是凑覆盖率？ | 🟢🟡🔴 |
| 9 | 复杂度趋势 | git 历史显示收敛还是发散？文件变更频率？ | 🟢🟡🔴 |
┌──────────────┬──────────────────────────────────────────────────────────┐
│ 裁决 │ 触发条件 │
├──────────────┼──────────────────────────────────────────────────────────┤
│ ✅ 继续 │ 膨胀 <2x，偏离 <20%，无致命缺陷 │
│ ⚠️ 瘦身 │ 膨胀 2-3x，死代码 <15%，核心可用，可定点清除 │
│ 🔧 Fork 改写 │ 核心逻辑可用但分发/接口有问题，改外壳不改引擎 │
│ 🔄 重构 │ 技术选型正确但实现混乱，膨胀 2-4x │
│ ❌ 推倒重来 │ 膨胀 >5x，或死代码 >20%，或偏离 >30% │
│ 🪦 放弃 │ 问题本身不值得解决，或市场上已有成熟方案 │
└──────────────┴──────────────────────────────────────────────────────────┘
┌──────────────┬──────────────────────────────────────────────────────────┐
│ 裁决 │ 触发条件 │
├──────────────┼──────────────────────────────────────────────────────────┤
│ ✅ 直接使用 │ 活跃维护，API 稳定，文档完善，满足 >80% 需求 │
│ 🔧 Fork 改造 │ 核心好用但缺关键功能/有设计缺陷，维护者不活跃或方向不同 │
│ 📦 提取逻辑 │ 整体不可用但有 1-3 个模块/算法值得复用（标注具体文件行号）│
│ 🪦 代码垃圾 │ 膨胀 >5x，无测试，依赖过时，或核心逻辑本身有缺陷 │
└──────────────┴──────────────────────────────────────────────────────────┘
Track B 额外评估项:
| 项目 | 检查内容 |
|---|---|
| 维护状态 | 最近 commit 时间、issue 响应速度、release 频率 |
| 许可证 | MIT/Apache 可商用；GPL 传染性；无许可证 = 不可用 |
| API 稳定性 | 是否频繁破坏性变更，是否有 SemVer 纪律 |
| 社区信号 | Star/Fork 比、contributor 数、是否一人项目 |
| 替代方案 | 同类项目中是否有更好选择（必须列出对比） |
无论裁决是什么，都必须产出资产清单：
## 值得保留的资产
### 可直接复用的文件
- [file] ([lines] 行): [reason]
### 可提取的核心逻辑
- [function/pattern] (~[lines] 行): [what it does]
### 值得保留的设计决策
- [decision]: [why correct]
### 必须丢弃的部分
- [module]: [why — 用数据，不用形容词]
审计是讨论 session，交付物必须是 plan 文件（见 ~/.agents/AGENTS.md §3）。
Plan 保存路径: ~/.agents/plans/YYYY-MM-DD-audit-<project-slug>.md
Plan 内容根据裁决不同：
不需要 plan。在回复中给出结论和使用注意事项即可。
# [project] 瘦身计划
## 目标
从 [X] 行减至 ~[Y] 行，保留核心功能 [list]。
## 删除清单（按依赖顺序）
1. 删 [file/module] ([lines] 行) — [reason]
2. 删 [file/module] ([lines] 行) — [reason]
...
## 风险点
- 删 [A] 后 [B] 会断，需要 [fix]
## 验证
- 每步删完跑 [test command]
- 最终验证: [end-to-end command]
# [project] Fork 改写计划
## 目标
在现有代码上改 [分发机制/接口/配置]，核心逻辑零修改。
## 不动的部分
- [module]: [why keep, lines]
## 要改的部分
1. [Task]: 新增/替换 [file] — [what and why]
2. [Task]: 删除 [file] — [reason]
...
## 删除的部分
- [duplicate/dead code] — [lines saved]
## 净变化
+[X] 行, -[Y] 行
# [project] 重建计划
## 重建目标
一句话: [what the rebuilt project should be]
## 从旧项目提取的资产
[asset extraction list, copy-paste ready]
## 约束（防止重蹈覆辙）
1. [constraint]
2. [constraint]
3. [constraint]
## 目标文件结构
[tree, 10-15 files max]
## 实施 Task
[standard task-by-task plan per ~/.agents/skills/writing-plans/]
# 从 [project] 提取逻辑
## 提取清单
1. [file:L10-L85] → 复制到 [destination] — [what it does]
2. [file:L100-L200] → 改造后用于 [purpose] — [adaptation needed]
## 依赖处理
- 提取的代码依赖 [lib]，需要 [install command]
- [internal dependency] 需要一并提取或替换
## 验证
- 提取后运行 [test]
不需要 plan。在回复中给出结论和替代方案建议。
传统假设：重建成本 >> 瘦身成本。AI 辅助开发下，等式反转。
判定规则: 膨胀 >5x 时，瘦身的认知负担（理解数千行垃圾）> 重建的执行成本（写几百行新代码）。此时瘦身是浪费不是节约。
但反过来，膨胀 <3x、核心可用时，重建是浪费——你在重写已经能用的代码。不要因为"重建很酷"而重建。
发现自己有以下行为时立即停止并重写：