企业官网建设流程全解析

本文为新手准备了一份 vibecode-pro-max-kit 贡献指南，手把手教你在 AI 编码工具包中编写自定义 Skill 与添加文档翻译。vibecode-pro-max-kit 是一个 spec 驱动的 AI 编码 harness，内置 15 个 agent、33 个 skill 和 10 个 hook，兼容 Claude Code 与 Codex，让 AI 按 Research → Spec → Plan → Execute 的流程开发而不丢失上下文。无论你是想提交第一个 Skill，还是补充一门语言翻译，读完这篇贡献指南都能独立走完整个流程。

为什么值得为 vibecode-pro-max-kit 做贡献？

这个项目零依赖、结构清晰，非常适合第一次向开源项目提交 PR 的开发者：

• 门槛低：官方维护了 docs/GOOD-FIRST-ISSUES.md 新手任务清单，标注了难度和预估时间（多数 1~3 小时可完成），还有 mentor 负责评审
• 贡献类型多：Skill、Agent、Hook、协议文档、翻译、文档改进、Bug 修复都欢迎
• AI 辅助友好：这是一个 AI 工具包，官方明确鼓励用 AI 协助开发（你需要自行审查并理解提交内容）
• 无需签 CLA：贡献遵循仓库的 MIT 许可证，合并后你的名字会出现在 README 贡献者列表和 Release Notes 中

贡献前准备：环境要求与仓库获取

按 CONTRIBUTING.md 的要求，准备好以下环境即可开工，不需要额外的包管理器：

获取代码：

git clone https://gitcode.com/gh_mirrors/vi/vibecode-pro-max-kit cd vibecode-pro-max-kit

建议先把 install.sh 安装到一个空测试项目里，确认vc-setup能跑通、验证脚本全部通过，再开始动手。

理解 Skill 结构：一个目录加一个 SKILL.md

Skill 是项目里最核心的可复用能力模块，全部位于.claude/skills/下，每个 Skill = 一个目录 + 一份 SKILL.md。想理解结构，直接读一个现成例子，比如 vc-scenario 的 SKILL.md：

--- name: vc-scenario description: "从12个维度拆解功能，生成边界用例和测试场景。" trigger_keywords: edge cases, test scenarios layer: helper metadata: author: claudekit version: "1.0.0" --- # vc-scenario — 边界用例与场景探索器 （正文：使用时机、工作流程、输出规范…）

YAML frontmatter 是"元数据"，告诉系统这个 Skill 叫什么、做什么、什么关键词触发它；正文则是给 AI 的工作指令。辅助脚本统一放在该目录的scripts/子目录下。

⚠️重要规则：自定义 Skill 的名称不能使用vc-前缀——这是官方保留命名空间，安装包在更新时会自动清理vc-*路径下的"陈旧文件"，你的自定义 Skill 可能因此被误删。推荐用my-、team-、proj-之类的自定义前缀。

编写第一个自定义 Skill：分步操作清单

以下清单整合自 CONTRIBUTING.md 的 Skill Contribution Checklist，照着做即可：

1. 建目录：在.claude/skills/下新建.claude/skills/my-skill/
2. 写 SKILL.md：包含合法 YAML frontmatter（至少name和description），正文写清楚"何时使用、如何使用、输出什么"
3. 放脚本：需要辅助脚本时放入scripts/子目录
4. 登记清单：把新增文件路径加入根目录的 vc-manifest.json——安装和vc-update依据它同步文件，漏登记意味着用户装不到你的 Skill
5. 跑验证，两条命令必须全部通过：

node .claude/skills/vc-audit-vc/scripts/validate-skills.mjs node .claude/skills/vc-audit-vc/scripts/validate-agent-parity.mjs

💡新手建议：先从 docs/GOOD-FIRST-ISSUES.md 里挑一个skill标签的任务，例如"Changelog 生成 Skill（从 conventional commits 生成变更日志，约 2~3 小时）"。先认领 issue，再按上面的清单开发，最后提交 PR。

添加翻译：让 AI 编码工具包被更多人使用

翻译是门槛最低的贡献类型（预估 1~2 小时）。项目的多语言文档统一放在docs/i18n/目录，命名规则为<文档名>.<语言代码>.md，现有文件可参考 docs/i18n/README.es.md：

1. 选文档：通常从 README.md 开始，价值最大
2. 建文件：保存为docs/i18n/README.<locale>.md（如README.id.md）
3. 保留格式：所有链接、badge、表格结构原样保留，只翻译文字
4. 加语言切换头：在文件顶部仿照现有翻译的语言切换栏（见 docs/i18n/README.es.md 开头），并把新语言加入 README.md 顶部的语言导航
5. 提交 PR：commit 使用docs:前缀，例如docs: translate README to Indonesian

🌐 当前项目已支持英文、简体中文、日本語、한국어、Tiếng Việt、Português、Español、Deutsch、Français、हिंदी 共 10 种语言，每多一门语言，就有更多 vibecoder 能用母语上手这套 spec 驱动开发流程。

提交 PR：命名规范与评审流程

• 一个 PR 只做一件事：单个 Skill、单个翻译或单个 Bug 修复，改动量控制在 200~400 行为佳
• 分支命名：feat/my-new-skill、docs/contributing-guide、fix/install-symlink-wsl
• Commit 格式（conventional commits）：
  • feat:新增 Skill / Agent / Hook
  • fix:修复既有功能
  • docs:纯文档变更
  • chore:维护与工具链调整
• PR 描述写清"做了什么、怎么测的（跑了哪些验证脚本）、是否有破坏性变更"，并引用对应 issue——无上下文的 PR 可能被直接关闭

评审方面：CI 验证脚本必须通过，维护者会在 48 个工作小时内（软性目标）完成审查，至少一名维护者批准即可合并。收到修改意见时请追加新 commit，不要 force-push 覆盖评审记录。

延伸阅读：仓库里的关键资料

从认领一个 good first issue，到提交一个通过验证的 PR，整个过程不需要你精通项目的每个协议文档——照着清单走、跑通验证脚本，你的第一个贡献就能顺利落地。🚀