mcpField
O
onboard

onboard

github.com/donchitos开发32.1k509 次安装2 周前更新
代码仓库

关于 onboard

onboard 是面向游戏项目新成员的引导技能,可按角色或领域扫描项目资料并生成入职文档。它要求先核对输入是否存在,缺少必要数据时明确标记未评估,而不推测内容。

主要功能

  1. 01读取项目说明和角色定义
  2. 02按角色扫描相关目录
  3. 03查看近期 Git 变更
  4. 04标记缺失输入和未评估项
  5. 05生成并保存引导文档

适用场景

  1. 01帮助新程序员了解代码结构和开发动向
  2. 02为 QA 成员整理现有测试覆盖情况
  3. 03为新成员汇总设计或制作资料

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/donchitos/claude-code-game-studios --skill onboard

安装后在 Claude Code 中输入/onboard确认已加载。

详细介绍

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

自动化模式:解析 modes.automation(project.local.yaml → project.yaml → 默认值 collaborative)。每次调用 AskUserQuestion 和 每次文件写入都遵循 .claude/docs/automation-modes.md (collaborative 始终提问 · guided 仅重大事项提问 · autonomous 记录并继续; automation_always_ask 类别始终提示)。

入门引导

输入不足——生成任何报告前先检查

如果此技能所需的输入不存在,答案就是“无法运行”—— 而不是一份填好的报告。 先检查,若检查失败则停止。

  1. 列出此技能读取的输入(数据文件、先前的报告、分析器输出、 测试结果、注册表、源代码)。
  2. 对每项记录 FOUND 或 ABSENT——不要写“假定存在”。
  3. 如果某个章节所需的任一输入为 ABSENT,该章节应标记为 NOT ASSESSED — NO DATA。不要估算,不要从相邻产物推断,也不要把模板中规定填写的单元格留给下一个阅读者填写。
  4. 如果所有必需输入都为 ABSENT,请停止,并将 NOT ASSESSED — NO DATA 作为整体结论,注明缺少的内容以及负责生成这些内容的技能。

结论为 NOT ASSESSED 也是成功。 当没有数据时,这是对“数据说明了什么?”这一问题正确且有用的回答。它能防止一种特定的失败情况:结论枚举中没有“无法运行”状态的报告会产生虚假的通过结果——例如,项目没有资产也没有标准,却在资产审计中得到 COMPLIANT;或者没有任何分析器数据、也从未设置预算,却报告“相对于 16.67ms 预算,余量超过 99%”。

没有证据不等于不存在的证据。 如果没有文件可扫描,扫描自然找不到匹配项,这并不能证明任何事情。请说明实际发生的是哪一种情况——读者无法仅凭绿色结果判断。


Phase 1:加载项目上下文

阅读 CLAUDE.md,了解项目概况和标准。

如果指定了特定角色,请阅读 .claude/agents/ 中相关的 Agent 定义。

CLAUDE.md 和 .claude/agents/ 随框架提供,不会由任何技能创建。如果缺少其中任一项,请报告其在安装中缺失。


Phase 2:扫描相关区域

  • 对程序员:扫描代码根目录(根据 .claude/docs/code-root-resolution.md 确定),了解架构、模式和关键文件。若根目录无法解析,则表示扫描未运行:其相关章节应写为 NOT ASSESSED — code root unresolved,绝不能猜测为 src/
  • 对设计师:扫描 design/ 中现有的设计文档
  • 对叙事工作:扫描 design/narrative/ 中的世界构建和故事文档
  • 对 QA:扫描 tests/ 中现有的测试覆盖情况(/test-setup 会创建该目录)
  • 对制作:扫描 production/ 中当前的冲刺和里程碑
  • 未指定角色或区域:进行一般性概览——列出 design/、 docs/architecture/、production/ 和代码根目录的顶层内容;若 production/session-state/active.md 存在,则阅读该文件;并说明指定角色可以让下一轮检查更聚焦(例如 /onboard programmer)

阅读近期变更(如果可用,查看 git log),以了解当前进展。


Phase 3:生成入门引导文档

# Onboarding: [Role/Area]

## Project Summary
[2-3 sentence summary of what this game is and its current state]

## Your Role
[What this role does on this project, key responsibilities, who you report to]

## Project Architecture
[Relevant architectural overview for this role]

### Key Directories
| Directory | Contents | Your Interaction |
|-----------|----------|-----------------|

### Key Files
| File | Purpose | Read Priority |
|------|---------|--------------|

## Current Standards and Conventions
[Summary of conventions relevant to this role from CLAUDE.md and agent definition]

## Current State of Your Area
[What has been built, what is in progress, what is planned next. Name what
Phase 2 found by path — for a designer, each existing GDD and design doc — or
say it found none]

## Current Sprint Context
[What the team is working on now and what is expected of this role]

## Key Dependencies
[What other roles/systems this role interacts with most]

## Common Pitfalls
[Things that trip up new contributors in this area]

## First Tasks
[Suggested first tasks to get oriented and productive]

1. [Read these documents first]
2. [Review this code/content]
3. [Start with this small task]

## Questions to Ask
[Questions the new contributor should ask to get fully oriented]

Phase 4:保存文档

向用户展示入门引导文档。

询问:“我可以将此文档写入 production/onboarding/onboard-[role]-[date].md 吗?”

如果可以,则写入文件;如有需要,先创建目录。


Phase 5:后续步骤

结论:COMPLETE — 入门引导文档已生成。

  • 在新贡献者首次参与前,将入门引导文档分享给他们。
  • 运行 /sprint-status,向新贡献者展示当前进度。
  • 如果贡献者需要关于下一步工作的指导,请运行 /help。

评论

支持 Markdown