!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

# 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.