Files
Claude-Code-Game-Studios/.claude/skills/onboard/SKILL.md
T
DonchitosandClaude Opus 5.5 b21fa0f7f2 Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that
run on Godot, Unity and Unreal, hook warnings you can see, and verdicts
that say when they could not check. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.1 → v1.1.2).

Fixes #67
Fixes #131

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
2026-09-29 21:32:19 +10:00

143 lines
5.4 KiB
Markdown

---
name: onboard
description: "Onboarding doc for a new contributor or agent — project state, conventions, priorities relevant to the specified role."
argument-hint: "[role|area]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Bash(bash "*/.claude/skills/onboard/../../hooks/yaml-helper.sh" resolve_config *)
model: haiku
---
!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation`
**Automation mode**: Resolve `modes.automation` (`project.local.yaml` →
`project.yaml` → default `collaborative`). Every `AskUserQuestion` call and
every file write follows `.claude/docs/automation-modes.md`
(collaborative asks always · guided major-only · autonomous logs and proceeds;
`automation_always_ask` categories always prompt).
## Insufficient input — check this before producing any report
**If the inputs this skill needs do not exist, the answer is "could not run" —
not a filled-in report.** Check first, and stop if the check fails.
1. List the inputs this skill reads (data files, prior reports, profiler output,
test results, registries, source code).
2. For each, record `FOUND` or `ABSENT` — not "assumed present".
3. If any input required for a section is ABSENT, that section is
**`NOT ASSESSED — NO DATA`**. Do not estimate it, do not infer it from an
adjacent artifact, and do not leave a mandated cell to be filled by whoever
reads the template next.
4. If **every** required input is ABSENT, stop and report
**`NOT ASSESSED — NO DATA`** as the whole verdict, naming what was missing and
which skill produces it.
**A verdict of `NOT ASSESSED` is a success.** It is the correct, useful answer to
"what does the data say?" when there is no data. The failure mode this prevents is
specific and has been observed in practice: report templates whose verdict
enum had no "could not run" state produced **false clean passes** — an asset audit
returning COMPLIANT on a project with no assets and no standards, and a
performance profile reporting ">99% headroom against a 16.67ms budget" with zero
profiler data and no budget ever set.
**Absence of evidence is never evidence of absence.** A scan that finds no
matches because there are no files to scan has not verified anything. Say which of
the two happened — a reader cannot tell from a green result.
---
## Phase 1: Load Project Context
Read CLAUDE.md for project overview and standards.
Read the relevant agent definition from `.claude/agents/` if a specific role is specified.
`CLAUDE.md` and `.claude/agents/` ship with the framework — no skill creates them. If either is missing, report it as missing from the install.
---
## Phase 2: Scan Relevant Area
- For programmers: scan the code root (resolve per `.claude/docs/code-root-resolution.md`) for architecture, patterns, key files. An unresolved root means the scan did not run: the sections it feeds read `NOT ASSESSED — code root unresolved`, never a guess at `src/`
- For designers: scan `design/` for existing design documents
- For narrative: scan `design/narrative/` for world-building and story docs
- For QA: scan `tests/` for existing test coverage (`/test-setup` creates it)
- For production: scan `production/` for current sprint and milestone
- **No role or area given**: a general orientation — list the top level of `design/`,
`docs/architecture/`, `production/` and the code root, read
`production/session-state/active.md` if it exists, and say that a role would
focus the next pass (e.g. `/onboard programmer`)
Read recent changes (git log if available) to understand current momentum.
---
## Phase 3: Generate Onboarding Document
```markdown
# 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: Save Document
Present the onboarding document to the user.
Ask: "May I write this to `production/onboarding/onboard-[role]-[date].md`?"
If yes, write the file, creating the directory if needed.
---
## Phase 5: Next Steps
Verdict: **COMPLETE** — onboarding document generated.
- Share the onboarding doc with the new contributor before their first session.
- Run `/sprint-status` to show the new contributor current progress.
- Run `/help` if the contributor needs guidance on what to work on next.