mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 10:17:06 +00:00
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
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -2,29 +2,48 @@
|
||||
|
||||
## Skill Summary
|
||||
|
||||
`/bug-report` creates a structured bug report document from a user description.
|
||||
It produces a report with the following required fields: Title, Repro Steps,
|
||||
Expected Behavior, Actual Behavior, Severity (CRITICAL/HIGH/MEDIUM/LOW), Affected
|
||||
System(s), and Build/Version. If the user's initial description is missing any
|
||||
required field, the skill asks follow-up questions to fill the gaps before
|
||||
producing the draft.
|
||||
`/bug-report` has four modes, chosen from the argument: a plain description
|
||||
(**Description Mode**), `analyze [path]` (**Analyze Mode** — read code and
|
||||
report potential bugs), `verify [BUG-ID]` (**Verify Mode**) and `close [BUG-ID]`
|
||||
(**Close Mode**). With no argument it asks for a bug description first.
|
||||
|
||||
The skill checks for possibly duplicate reports (by comparing to existing files
|
||||
in `production/bugs/`) and offers to link rather than create a new report. Each
|
||||
report is written to `production/bugs/bug-[date]-[slug].md` after a "May I write"
|
||||
ask. No director gates are used — bug reporting is an operational utility.
|
||||
Description Mode parses the description, searches the codebase with Grep/Glob
|
||||
for related files, and drafts the report template: Title, ID `BUG-[NNNN]`,
|
||||
Severity on the `S1-Critical / S2-High / S3-Medium / S4-Low` scale, Priority
|
||||
on the `P1-Fix this sprint / P2-Fix soon / P3-Backlog / P4-Won't fix` ladder
|
||||
(which must match `/bug-triage`), Status `Open`, Classification (Category,
|
||||
System, Frequency, Regression — for a bug spanning systems, `System` is the one
|
||||
whose code must change), Environment (Build, Platform, Scene/Level),
|
||||
Reproduction Steps with Expected and Actual Result, and Technical Context
|
||||
(likely affected files, related systems). It presents the report and asks
|
||||
"May I write this to `production/qa/bugs/BUG-[NNNN].md`?" — `Verdict: **COMPLETE**`
|
||||
on write, `Verdict: **BLOCKED**` if declined. The ID is the highest existing
|
||||
number plus one; several reports in one run (Analyze Mode) take consecutive IDs,
|
||||
and one ask names every file. Next steps: `/bug-triage`, and
|
||||
`/hotfix [BUG-ID]` for S1/S2. No director gates are used.
|
||||
|
||||
Verify and Close Mode find the bug file by its number, whatever its padding —
|
||||
an older three-digit file with a slug included. Verify runs a related test with
|
||||
`commands.test` from `project.yaml` (never a runner line from memory). When no
|
||||
test ran — none covers the bug, `commands.test` is unset, or the run did not
|
||||
complete — or the bug is Visual or UI, it asks whether the user played the
|
||||
reproduction steps: `[No longer occurs]` → VERIFIED FIXED, recorded as a manual
|
||||
verification with the build; `[Still occurs]` → STILL PRESENT; `[Not played yet]`
|
||||
→ CANNOT VERIFY. It asks "May I update" before setting the Status; only a
|
||||
`Verified Fixed` bug can be closed, and Close Mode shows the closure record and
|
||||
asks before it writes anything.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified automatically by `/skill-test static` — no fixture needed.
|
||||
Checked against the SKILL.md by `/skill-test spec` — no fixture needed.
|
||||
|
||||
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
|
||||
- [ ] Has ≥2 phase headings
|
||||
- [ ] Contains verdict keyword: COMPLETE
|
||||
- [ ] Contains "May I write" collaborative protocol language before writing the report
|
||||
- [ ] Has a next-step handoff (e.g., `/bug-triage` to reprioritize, `/hotfix` for critical)
|
||||
- [ ] Contains verdict keywords: COMPLETE, BLOCKED (and VERIFIED FIXED / STILL PRESENT / CANNOT VERIFY for Verify Mode)
|
||||
- [ ] Contains "May I write" language before writing the report and "May I update" before changing an existing bug file
|
||||
- [ ] Has a next-step handoff (`/bug-triage`; `/hotfix [BUG-ID]` for S1/S2; `/bug-report verify` → `close`)
|
||||
|
||||
---
|
||||
|
||||
@@ -39,136 +58,224 @@ None. `/bug-report` is an operational documentation skill. No director gates app
|
||||
### Case 1: Happy Path — User describes a crash, full report produced
|
||||
|
||||
**Fixture:**
|
||||
- `production/bugs/` directory exists and is empty
|
||||
- No similar existing reports
|
||||
- `production/qa/bugs/` does not exist yet
|
||||
- The code root contains a boss-arena scene script
|
||||
|
||||
**Input:** `/bug-report` (user describes: "Game crashes when player enters the boss arena")
|
||||
**Input:** `/bug-report The game crashes to desktop every time the player enters the boss arena — progress is blocked`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill extracts: Title = "Game crashes when entering boss arena"
|
||||
2. Skill recognizes crash reports as CRITICAL severity
|
||||
3. Skill confirms repro steps, expected (no crash), actual (crash), affected system
|
||||
(arena/boss), and build version with the user
|
||||
4. Skill drafts the full structured report
|
||||
5. Skill asks "May I write to `production/bugs/bug-2026-04-06-game-crashes-boss-arena.md`?"
|
||||
6. File is written on approval; verdict is COMPLETE
|
||||
1. Description Mode (no keyword)
|
||||
2. Skill parses the description and greps the codebase for boss-arena files
|
||||
3. Drafts the report template: Category `Crash`, Severity `S1-Critical`,
|
||||
Status `Open`, reproduction steps, Expected Result (no crash) and Actual
|
||||
Result (crash to desktop), likely affected files from the search
|
||||
4. Globs `production/qa/bugs/BUG-*.md`, finds none, allocates `BUG-0001`, presents the
|
||||
report and asks "May I write this to `production/qa/bugs/BUG-0001.md`?"
|
||||
5. On approval writes the file, creating `production/qa/bugs/`; Verdict is COMPLETE
|
||||
6. Next steps: `/bug-triage`, and `/hotfix [BUG-ID]` because the bug is S1
|
||||
|
||||
**Assertions:**
|
||||
- [ ] All 7 required fields are present in the report
|
||||
- [ ] Severity is CRITICAL for a crash report
|
||||
- [ ] Filename follows the `bug-[date]-[slug].md` convention
|
||||
- [ ] "May I write" is asked with the full file path
|
||||
- [ ] Verdict is COMPLETE
|
||||
- [ ] Report contains Title, ID, Severity, Priority, Status, Category, System, Build, Reproduction Steps, Expected Result and Actual Result
|
||||
- [ ] Severity uses the S1–S4 scale (`S1-Critical` here) and Priority uses the P1–P4 labels
|
||||
- [ ] "Likely affected files" is filled from the codebase search
|
||||
- [ ] "May I write" names `production/qa/bugs/BUG-0001.md` — no bug files exist yet
|
||||
- [ ] Variant — with `BUG-0001.md` and `BUG-0003.md` already present, the new ID is
|
||||
`BUG-0004`: the highest existing number plus one, not the file count plus one
|
||||
- [ ] Verdict is COMPLETE after the write
|
||||
- [ ] `/hotfix [BUG-ID]` is suggested because severity is S1
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Minimal Input — Skill asks follow-up questions for missing fields
|
||||
### Case 2: No Argument — Asks for a description before drafting
|
||||
|
||||
**Fixture:**
|
||||
- User provides: "Sometimes the audio cuts out"
|
||||
- No existing reports
|
||||
- No existing bug reports
|
||||
|
||||
**Input:** `/bug-report`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill identifies missing required fields: repro steps, expected vs. actual,
|
||||
severity, affected system, build
|
||||
2. Skill asks targeted follow-up questions for each missing field (one at a time
|
||||
or in a structured prompt)
|
||||
3. User provides answers
|
||||
4. Skill compiles complete report from answers
|
||||
5. Skill asks "May I write?" and writes on approval
|
||||
1. No argument → skill asks the user for a bug description before proceeding
|
||||
2. No template is drafted and nothing is written until a description arrives
|
||||
3. Once the user answers ("Sometimes the audio cuts out"), Description Mode proceeds;
|
||||
unknown values (e.g. Build, Frequency) remain visible in the draft for the user to correct
|
||||
4. "May I write" is asked before the file is created
|
||||
|
||||
**Assertions:**
|
||||
- [ ] At least 3 follow-up questions are asked to fill missing fields
|
||||
- [ ] Each required field is filled before the report is finalized
|
||||
- [ ] Report is not written until all required fields are present
|
||||
- [ ] Verdict is COMPLETE after all fields are filled and file is written
|
||||
- [ ] Skill asks for a description instead of drafting from nothing
|
||||
- [ ] No report is drafted or written before the description is given
|
||||
- [ ] "May I write" precedes the write
|
||||
- [ ] Verdict is COMPLETE only after the file is written
|
||||
|
||||
---
|
||||
|
||||
### Case 3: Possible Duplicate — Offers to link rather than create new
|
||||
### Case 3: Close Mode — Bug not yet verified is refused
|
||||
|
||||
**Fixture:**
|
||||
- `production/bugs/bug-2026-03-20-audio-cut-out.md` already exists with
|
||||
similar title and MEDIUM severity
|
||||
- `production/qa/bugs/BUG-0007.md` exists with `**Status**: Open`
|
||||
|
||||
**Input:** `/bug-report` (user describes: "Audio randomly stops working")
|
||||
**Input:** `/bug-report close BUG-0007`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill scans existing reports and finds the similar audio bug
|
||||
2. Skill reports: "A similar bug report exists: bug-2026-03-20-audio-cut-out.md"
|
||||
3. Skill presents options: link as duplicate (add note to existing), create new anyway
|
||||
4. If user chooses link: skill adds a cross-reference note to the existing file
|
||||
(asks "May I update the existing report?")
|
||||
5. If user chooses create new: normal report creation proceeds
|
||||
1. Close Mode reads `production/qa/bugs/BUG-0007.md`
|
||||
2. Status is not `Verified Fixed`, so the skill stops:
|
||||
"Bug BUG-0007 must be Verified Fixed before it can be closed. Run `/bug-report verify BUG-0007` first."
|
||||
3. No Closure Record is appended and the Status field is not changed
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Existing similar report is surfaced before creating a new one
|
||||
- [ ] User is given the choice (not forced to link or create)
|
||||
- [ ] If linking: "May I update" is asked before modifying the existing file
|
||||
- [ ] Verdict is COMPLETE in either path
|
||||
- [ ] The "must be Verified Fixed before it can be closed" message is shown
|
||||
- [ ] `/bug-report verify BUG-0007` is named as the next step
|
||||
- [ ] No Closure Record is written and `BUG-0007.md` is not edited
|
||||
- [ ] No "May I update" ask is issued (nothing to update)
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Multi-System Bug — Report created with multiple system tags
|
||||
### Case 4: Multi-System Bug — One report, primary and related systems
|
||||
|
||||
**Fixture:**
|
||||
- No existing reports
|
||||
- The code root has a save manager and a level-complete UI screen
|
||||
|
||||
**Input:** `/bug-report` (user describes: "After finishing a level, the save system
|
||||
freezes and the UI doesn't show the completion screen")
|
||||
**Input:** `/bug-report After finishing a level, the save system freezes and the UI doesn't show the completion screen`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill identifies 2 affected systems from the description: Save System and UI
|
||||
2. Report is drafted with both systems listed under Affected System(s)
|
||||
3. Severity is assessed (likely HIGH — data loss risk from save freeze)
|
||||
4. Skill asks "May I write" with the appropriate filename
|
||||
5. Report is written with both systems tagged; verdict is COMPLETE
|
||||
1. Description Mode drafts **one** report
|
||||
2. Classification `System` names the save system — its freeze is what must be
|
||||
fixed, and the missing completion screen follows from it; Technical Context
|
||||
"Related systems" lists the UI; "Likely affected files" lists files for both
|
||||
from the codebase search
|
||||
3. Skill asks "May I write" once for one `BUG-[NNNN].md`
|
||||
4. Verdict is COMPLETE after the write
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Both affected systems are listed in the report
|
||||
- [ ] Single report is created (not one per system)
|
||||
- [ ] Severity reflects the most impactful component (save freeze → HIGH or CRITICAL)
|
||||
- [ ] A single report is created (not one per system)
|
||||
- [ ] `System` is the save system, the one whose code must change; the UI is under Related systems
|
||||
- [ ] Likely affected files cover both systems
|
||||
- [ ] Verdict is COMPLETE
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Director Gate Check — No gate; bug reporting is operational
|
||||
### Case 5: Director Gate Check — Analyze Mode, no gate
|
||||
|
||||
**Fixture:**
|
||||
- Any bug description provided
|
||||
- `src/save/save_manager.gd` exists and contains an unguarded null dereference and an unclosed file handle
|
||||
- `production/qa/bugs/` holds `BUG-0011.md` (the highest existing number)
|
||||
|
||||
**Input:** `/bug-report`
|
||||
**Input:** `/bug-report analyze src/save/save_manager.gd`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Skill creates and writes the bug report
|
||||
2. No director agents are spawned
|
||||
3. No gate IDs appear in output
|
||||
1. Analyze Mode reads the target file
|
||||
2. Identifies potential bugs (null reference, resource leak) and drafts one report
|
||||
per bug with the trigger scenario and a recommended fix
|
||||
3. Allocates consecutive IDs, `BUG-0012` and `BUG-0013`, one per report
|
||||
4. Presents the reports and asks once, naming both files: "May I write these to
|
||||
`production/qa/bugs/BUG-0012.md`, `production/qa/bugs/BUG-0013.md`?"
|
||||
5. No director agents are spawned; no gate IDs appear
|
||||
|
||||
**Assertions:**
|
||||
- [ ] No director gate is invoked
|
||||
- [ ] No gate skip messages appear
|
||||
- [ ] Skill reaches COMPLETE without any gate check
|
||||
- [ ] One report per potential bug, each with a trigger scenario and recommended fix
|
||||
- [ ] The two reports get different, consecutive IDs (`BUG-0012`, `BUG-0013`) — never the same ID twice
|
||||
- [ ] The single "May I write" ask names every file before any report is saved
|
||||
- [ ] No director gate is invoked and no gate skip messages appear
|
||||
- [ ] If the user declines, Verdict is BLOCKED and nothing is written
|
||||
|
||||
---
|
||||
|
||||
### Case 6: Verify Mode — older three-digit file found by its number, CANNOT VERIFY
|
||||
|
||||
**Fixture:**
|
||||
- `production/qa/bugs/` holds a bug file for bug 42 written in the older form:
|
||||
a three-digit number followed by a slug (`-save-corruption.md`), with
|
||||
`**Status**: Fixed — Pending Verification`
|
||||
- The bug's root-cause code path is gone from `src/save/`, but no test in
|
||||
`tests/` covers the save system, and the reproduction needs a console suspend
|
||||
that no automated check can drive
|
||||
|
||||
**Input:** `/bug-report verify BUG-0042`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Verify Mode globs `production/qa/bugs/BUG-*.md` and takes the file whose
|
||||
number is 42 — the three-digit, slugged file — instead of stopping on a
|
||||
missing `BUG-0042.md`
|
||||
2. It checks the root-cause code path (changed) and looks for a related test
|
||||
(none), then greps for the pattern recurring
|
||||
3. No test ran, so it asks via `AskUserQuestion` whether the user played the
|
||||
reproduction steps on a build with the fix — `[No longer occurs]` /
|
||||
`[Still occurs]` / `[Not played yet]`; the user answers `[Not played yet]`
|
||||
4. The verdict is **CANNOT VERIFY**: it names what is missing (no related test)
|
||||
and says that playing the reproduction steps settles it
|
||||
5. It asks "May I update `production/qa/bugs/[that file]` to set Status: … Cannot
|
||||
Verify?", naming the file it found
|
||||
6. It does not suggest `/bug-report close` — only a `Verified Fixed` bug can be
|
||||
closed
|
||||
|
||||
**Assertions:**
|
||||
- [ ] The older three-digit file is found by its number; the skill does not report "No bug BUG-0042"
|
||||
- [ ] The manual-play question is asked, with the three answers, before a verdict is given
|
||||
- [ ] Verdict is CANNOT VERIFY, not VERIFIED FIXED — the changed code path is not taken as a pass, and "Not played yet" is not a pass
|
||||
- [ ] Playing the reproduction steps is named as what would settle it
|
||||
- [ ] The "May I update" ask names the file actually found, before the Status changes
|
||||
- [ ] Close is not offered while the verdict is CANNOT VERIFY
|
||||
|
||||
---
|
||||
|
||||
### Case 7: Verify then Close — no test covers the bug, the user's play settles it
|
||||
|
||||
**Fixture:**
|
||||
- `project.yaml` has no `modes` block (so `qa.level: minimal` — tests are waived)
|
||||
and no `commands` block
|
||||
- `production/qa/bugs/BUG-0005.md`: Category `UI`, System `HUD`, "health bar does
|
||||
not update after healing", `**Status**: Fixed — Pending Verification`
|
||||
- No test in the engine's test root covers the HUD
|
||||
|
||||
**Input:** `/bug-report verify BUG-0005`, then `/bug-report close BUG-0005`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Verify finds no related test and runs no runner line of its own — `commands.test`
|
||||
is unset, and it says so
|
||||
2. It asks via `AskUserQuestion` whether the user played the reproduction steps
|
||||
on a build with the fix, and which build — `[No longer occurs]` /
|
||||
`[Still occurs]` / `[Not played yet]`; the user answers `[No longer occurs]`,
|
||||
build `0.3.1`
|
||||
3. Verdict **VERIFIED FIXED**, a manual verification; it asks "May I update
|
||||
`production/qa/bugs/BUG-0005.md` to set Status: Verified Fixed …?" and, on
|
||||
yes, writes the Status with `**Verified by**: [user], manual, build 0.3.1`
|
||||
4. Next step: `/bug-report close BUG-0005`
|
||||
5. Close reads `Verified Fixed`, shows the closure record (`Verified by` from the
|
||||
verify record, `Regression test: Manual verification`) and the Status change,
|
||||
and asks "May I update `production/qa/bugs/BUG-0005.md` to mark it Closed?"
|
||||
before appending anything or changing the Status
|
||||
6. On yes it appends the Closure Record and sets `**Status**: Closed`
|
||||
|
||||
**Assertions:**
|
||||
- [ ] No test command is written from memory; the unset `commands.test` is named
|
||||
- [ ] The manual-play question is asked with the three answers and the build is recorded as the user gave it
|
||||
- [ ] Verdict is VERIFIED FIXED, recorded as manual (`[user], manual, build 0.3.1`) — a bug no test covers can reach Verified Fixed
|
||||
- [ ] Close asks "May I update … to mark it Closed?" before the Closure Record is appended or the Status changed
|
||||
- [ ] The Closure Record's Regression test reads "Manual verification"
|
||||
- [ ] Variant — answering `[Still occurs]` gives STILL PRESENT (the bug is reopened and `/hotfix [BUG-ID]` suggested); answering `[Not played yet]` gives CANNOT VERIFY
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Collects all 7 required fields before drafting the report
|
||||
- [ ] Asks follow-up questions for any missing required fields
|
||||
- [ ] Checks for similar existing reports before creating a new one
|
||||
- [ ] Asks "May I write to `production/bugs/bug-[date]-[slug].md`?" before writing
|
||||
- [ ] Verdict is COMPLETE when the report file is written
|
||||
- [ ] Selects the mode from the argument; asks for a description when none is given
|
||||
- [ ] Uses the S1–S4 severity scale and the P1–P4 priority labels shared with `/bug-triage`
|
||||
- [ ] Verify runs a related test with `commands.test` from `project.yaml`, never a runner line written from memory
|
||||
- [ ] Verify says VERIFIED FIXED only when every check that applies passed — the related tests ran and passed, or, with no test run (or for a Visual or UI bug), the user played the reproduction steps on a named build and it no longer occurs, recorded as a manual verification; "Not played yet" with nothing else to settle it is CANNOT VERIFY
|
||||
- [ ] The Reporter field never holds an email address or account ID taken from the session
|
||||
- [ ] Searches the codebase for affected files before drafting
|
||||
- [ ] Asks "May I write this to `production/qa/bugs/BUG-[NNNN].md`?" before writing
|
||||
- [ ] Asks "May I update" before changing an existing bug file (Verify / Close); Close Mode shows the closure record and asks before appending it
|
||||
- [ ] Finds the bug file by its number in Verify and Close Mode, and never closes a bug that is not `Verified Fixed`
|
||||
- [ ] Verdict is COMPLETE on write, BLOCKED when the user declines
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- The case where the user provides a severity that seems too low for the
|
||||
described impact (e.g., LOW for a crash) is not tested; the skill may suggest
|
||||
a higher severity but ultimately respects user input.
|
||||
- Build/version field is required but may be "unknown" if the user doesn't know —
|
||||
this is accepted as a valid value and not tested separately.
|
||||
- Report slug generation (sanitizing the title into a filename) is an
|
||||
implementation detail not assertion-tested here.
|
||||
- Verify Mode on a bug whose related test runs and passes (VERIFIED FIXED with
|
||||
no manual question) is not separately tested; Case 6 covers CANNOT VERIFY,
|
||||
Case 7 a manual VERIFIED FIXED and, as variants, STILL PRESENT.
|
||||
- Close Mode's triage-report reference note is not separately tested.
|
||||
- Verify or close with a number no file carries ("No bug [BUG-ID] in
|
||||
`production/qa/bugs/`", Verdict BLOCKED) is not separately tested.
|
||||
|
||||
Reference in New Issue
Block a user