mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 09:58:36 +00:00
DonchitosandClaude Opus 5
d05699707f
`project.yaml` at the repo root is now the single source of truth for a project's configuration, replacing `production/stage.txt`, `production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all three still read as a fallback; nothing is force-deleted). **`modes.rigor` — one question instead of six.** `minimal`, `standard` or `full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to `minimal`, which is a change from 1.0's behaviour: the heavier tier was measured costing several times more to reach working code without producing a better result, and returning nothing when a fresh developer inherited the project. Pin `modes.rigor: standard` to keep 1.0's process level. Also in this release: - `/settings` to view or change any setting, and `project.local.yaml` for per-developer preferences that should not be committed. - `system_overrides` to hold one system to a higher standard than the rest of the project, and `testing.strict` to set per test type whether missing evidence blocks a story or warns. - A story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in `production/qa/evidence/`. A parse check is not a run. This holds at every rigor level, including `minimal`, where automated tests are waived but the look is not. - The code root is engine-specific and enforced as such: Godot `src/`, Unity `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a project laid out any other way. - Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh` converts a 1.0 layout, non-destructively by default, with a report to review before `--finalize` deletes anything. - Ask-before-write holds regardless of personal automation settings. Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes: CHANGELOG.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
135 lines
4.6 KiB
Markdown
135 lines
4.6 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
|
|
model: haiku
|
|
---
|
|
|
|
!`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && 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.
|
|
|
|
---
|
|
|
|
## Phase 2: Scan Relevant Area
|
|
|
|
- For programmers: scan the code root (resolve per `.claude/docs/code-root-resolution.md`) for architecture, patterns, key files
|
|
- 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
|
|
- For production: scan `production/` for current sprint and milestone
|
|
|
|
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]
|
|
|
|
## 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.
|