mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:17:06 +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
180 lines
6.7 KiB
Markdown
180 lines
6.7 KiB
Markdown
---
|
|
name: bug-report
|
|
description: "Structured bug report from a description, or analyze code for potential bugs. Reproduction steps, severity."
|
|
argument-hint: "[description] | analyze [path-to-file]"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Bash, Write, Edit
|
|
model: sonnet
|
|
---
|
|
|
|
!`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).
|
|
|
|
## Phase 1: Parse Arguments
|
|
|
|
Determine the mode from the argument:
|
|
|
|
- No keyword → **Description Mode**: generate a structured bug report from the provided description
|
|
- `analyze [path]` → **Analyze Mode**: read the target file(s) and identify potential bugs
|
|
- `verify [BUG-ID]` → **Verify Mode**: confirm a reported fix actually resolved the bug
|
|
- `close [BUG-ID]` → **Close Mode**: mark a verified bug as closed with resolution record
|
|
|
|
If no argument is provided, ask the user for a bug description before proceeding.
|
|
|
|
---
|
|
|
|
## Phase 2A: Description Mode
|
|
|
|
1. **Parse the description** for key information: what broke, when, how to reproduce it, and what the expected behavior is.
|
|
|
|
2. **Search the codebase** for related files using Grep/Glob to add context (affected system, likely files).
|
|
|
|
3. **Draft the bug report**:
|
|
|
|
```markdown
|
|
# Bug Report
|
|
|
|
## Summary
|
|
**Title**: [Concise, descriptive title]
|
|
**ID**: BUG-[NNNN]
|
|
**Severity**: [S1-Critical / S2-Major / S3-Minor / S4-Trivial]
|
|
**Priority**: [P1-Fix this sprint / P2-Fix soon / P3-Backlog / P4-Won't fix]
|
|
|
|
> **These labels must match `/bug-triage`'s priority table exactly** — it parses
|
|
> this field out of the file you are writing. P4 is the easiest to get wrong:
|
|
> `P4-Wishlist` ("would be nice someday") and `P4 — Won't fix / Deferred`
|
|
> ("accepted risk, not doing it") mean opposite things, and nothing at runtime
|
|
> surfaces a disagreement between the producer and consumer of the field. If you change this ladder, change
|
|
> `.claude/skills/bug-triage/SKILL.md` in the same commit.
|
|
**Status**: Open
|
|
**Reported**: [Date]
|
|
**Reporter**: [Name]
|
|
|
|
## Classification
|
|
- **Category**: [Gameplay / UI / Audio / Visual / Performance / Crash / Network]
|
|
- **System**: [Which game system is affected]
|
|
- **Frequency**: [Always / Often (>50%) / Sometimes (10-50%) / Rare (<10%)]
|
|
- **Regression**: [Yes/No/Unknown -- was this working before?]
|
|
|
|
## Environment
|
|
- **Build**: [Version or commit hash]
|
|
- **Platform**: [OS, hardware if relevant]
|
|
- **Scene/Level**: [Where in the game]
|
|
- **Game State**: [Relevant state -- inventory, quest progress, etc.]
|
|
|
|
## Reproduction Steps
|
|
**Preconditions**: [Required state before starting]
|
|
|
|
1. [Exact step 1]
|
|
2. [Exact step 2]
|
|
3. [Exact step 3]
|
|
|
|
**Expected Result**: [What should happen]
|
|
**Actual Result**: [What actually happens]
|
|
|
|
## Technical Context
|
|
- **Likely affected files**: [List of files based on codebase search]
|
|
- **Related systems**: [What other systems might be involved]
|
|
- **Possible root cause**: [If identifiable from the description]
|
|
|
|
## Evidence
|
|
- **Logs**: [Relevant log output if available]
|
|
- **Visual**: [Description of visual evidence]
|
|
|
|
## Related Issues
|
|
- [Links to related bugs or design documents]
|
|
|
|
## Notes
|
|
[Any additional context or observations]
|
|
```
|
|
|
|
---
|
|
|
|
## Phase 2B: Analyze Mode
|
|
|
|
1. **Read the target file(s)** specified in the argument.
|
|
|
|
2. **Identify potential bugs**: null references, off-by-one errors, race conditions, unhandled edge cases, resource leaks, incorrect state transitions.
|
|
|
|
3. **For each potential bug**, generate a bug report using the template above, with the likely trigger scenario and recommended fix filled in.
|
|
|
|
---
|
|
|
|
## Phase 2C: Verify Mode
|
|
|
|
Read `production/qa/bugs/[BUG-ID].md`. Extract the reproduction steps and expected result.
|
|
|
|
1. **Re-run reproduction steps** — use Grep/Glob to check whether the root cause code path still exists as described. If the fix removed or changed it, note the change.
|
|
2. **Run the related test** — if the bug's system has a test file in `tests/`, run it via Bash and report pass/fail.
|
|
3. **Check for regression** — grep the codebase for any new occurrence of the pattern that caused the bug.
|
|
|
|
Produce a verification verdict:
|
|
|
|
- **VERIFIED FIXED** — reproduction steps no longer produce the bug; related tests pass
|
|
- **STILL PRESENT** — bug reproduces as described; fix did not resolve the issue
|
|
- **CANNOT VERIFY** — automated checks inconclusive; manual playtest required
|
|
|
|
Ask: "May I update `production/qa/bugs/[BUG-ID].md` to set Status: Verified Fixed / Still Present / Cannot Verify?"
|
|
|
|
If STILL PRESENT: reopen the bug, set Status back to Open, and suggest re-running `/hotfix [BUG-ID]`.
|
|
|
|
---
|
|
|
|
## Phase 2D: Close Mode
|
|
|
|
Read `production/qa/bugs/[BUG-ID].md`. Confirm Status is `Verified Fixed` before closing. If status is anything else, stop: "Bug [ID] must be Verified Fixed before it can be closed. Run `/bug-report verify [BUG-ID]` first."
|
|
|
|
Append a closure record to the bug file:
|
|
|
|
```markdown
|
|
## Closure Record
|
|
**Closed**: [date]
|
|
**Resolution**: Fixed — [one-line description of what was changed]
|
|
**Fix commit / PR**: [if known]
|
|
**Verified by**: qa-tester
|
|
**Closed by**: [user]
|
|
**Regression test**: [test file path, or "Manual verification"]
|
|
**Status**: Closed
|
|
```
|
|
|
|
Update the top-level `**Status**: Open` field to `**Status**: Closed`.
|
|
|
|
Ask: "May I update `production/qa/bugs/[BUG-ID].md` to mark it Closed?"
|
|
|
|
After closing, check `production/qa/bug-triage-*.md` — if the bug appears in an open triage report, note: "Bug [ID] is referenced in the triage report. Run `/bug-triage` to refresh the open bug count."
|
|
|
|
---
|
|
|
|
## Phase 3: Save Report
|
|
|
|
Present the completed bug report(s) to the user.
|
|
|
|
Ask: "May I write this to `production/qa/bugs/BUG-[NNNN].md`?"
|
|
|
|
If yes, write the file, creating the directory if needed. Verdict: **COMPLETE** — bug report filed.
|
|
|
|
If no, stop here. Verdict: **BLOCKED** — user declined write.
|
|
|
|
---
|
|
|
|
## Phase 4: Next Steps
|
|
|
|
After saving, suggest based on mode:
|
|
|
|
**After filing (Description/Analyze mode):**
|
|
- Run `/bug-triage` to prioritize alongside existing open bugs
|
|
- If S1 or S2: run `/hotfix [BUG-ID]` for emergency fix workflow
|
|
|
|
**After fixing the bug (developer confirms fix is in):**
|
|
- Run `/bug-report verify [BUG-ID]` — confirm the fix actually works before closing
|
|
- Never mark a bug closed without verification — a fix that doesn't verify is still Open
|
|
|
|
**After verify returns VERIFIED FIXED:**
|
|
- Run `/bug-report close [BUG-ID]` — write the closure record and update status
|
|
- Run `/bug-triage` to refresh the open bug count and remove it from the active list
|