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
222 lines
8.5 KiB
Markdown
222 lines
8.5 KiB
Markdown
---
|
|
name: hotfix
|
|
description: "Emergency fix bypassing normal sprint process — hotfix branch, approvals tracked, backport verified, full audit trail."
|
|
argument-hint: "[bug-id or description]"
|
|
user-invocable: true
|
|
disable-model-invocation: true
|
|
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion
|
|
model: sonnet
|
|
---
|
|
|
|
> **Explicit invocation only**: This skill should only run when the user explicitly requests it with `/hotfix`. Do not auto-invoke based on context matching.
|
|
|
|
## Phase 1: Assess Severity
|
|
|
|
Read the bug description or ID. Assess severity using these criteria:
|
|
|
|
- **S1 (Critical)**: Game unplayable, data loss, security vulnerability
|
|
- **S2 (Major)**: Significant feature broken, workaround exists
|
|
- **S3 or lower**: Minor issue — normal bug fix workflow applies
|
|
|
|
Confirm with `AskUserQuestion`:
|
|
- Prompt: "I've assessed this as **[assessed severity]** — [brief rationale]. Confirm severity to proceed:"
|
|
- Options:
|
|
- `[A] S1 (Critical) — game unplayable, data loss, or security issue`
|
|
- `[B] S2 (Major) — significant feature broken, workaround exists`
|
|
- `[C] S3 or lower — redirect to normal bug fix workflow`
|
|
|
|
If [C]: stop. Verdict: **REDIRECTED** — use the normal bug fix workflow for S3 and below.
|
|
|
|
---
|
|
|
|
## Phase 2: Create Hotfix Record
|
|
|
|
Draft the hotfix record:
|
|
|
|
```markdown
|
|
## Hotfix: [Short Description]
|
|
Date: [Date]
|
|
Severity: [S1/S2]
|
|
Reporter: [Who found it]
|
|
Status: IN PROGRESS
|
|
|
|
### Problem
|
|
[Clear description of what is broken and the player impact]
|
|
|
|
### Root Cause
|
|
[To be filled during investigation]
|
|
|
|
### Fix
|
|
[To be filled during implementation]
|
|
|
|
### Testing
|
|
[What was tested and how]
|
|
|
|
### Approvals
|
|
- [ ] Fix reviewed by lead-programmer
|
|
- [ ] Regression test passed (qa-tester)
|
|
- [ ] Release approved (producer)
|
|
|
|
### Rollback Plan
|
|
[How to revert if the fix causes new issues]
|
|
```
|
|
|
|
Ask: "May I write this to `production/hotfixes/hotfix-[date]-[short-name].md`?"
|
|
|
|
If yes, write the file, creating the directory if needed.
|
|
|
|
---
|
|
|
|
## Phase 3: Create Hotfix Branch
|
|
|
|
Check whether this is a git repository:
|
|
|
|
`Bash: git rev-parse --is-inside-work-tree 2>/dev/null`
|
|
|
|
If this command fails or returns empty: note "Not a git repository — create the branch manually." and skip branch creation.
|
|
|
|
If the check passes, use `AskUserQuestion` before creating the branch:
|
|
- Prompt: "Ready to create hotfix branch 'hotfix/[short-name]' from [base-ref]?"
|
|
- Options:
|
|
- `[A] Yes — create branch`
|
|
- `[B] Use a different base ref — I'll specify it`
|
|
- `[C] Skip — I'll create the branch myself`
|
|
|
|
Only run `git checkout -b hotfix/[short-name] [base-ref]` if user selects [A]. If [B]: ask the user for the base ref, then run the command with that ref. If [C]: skip branch creation and proceed to Phase 4.
|
|
|
|
---
|
|
|
|
## Phase 4: Investigate and Propose
|
|
|
|
Find the root cause. Draft the minimal fix: which files change, what the change does, and what it deliberately leaves alone. Do NOT refactor, clean up, or add features alongside the hotfix.
|
|
|
|
Present the root cause and proposed fix, then ask: "May I implement this fix?" Do not modify any code before this approval — an emergency flow earns its audit trail by approving the change *before* it exists, not after.
|
|
|
|
---
|
|
|
|
## Phase 4b: Implement (only after approval)
|
|
|
|
Implement the approved minimal change. Validate the fix by running targeted tests for the affected system. Check for regressions in adjacent systems.
|
|
|
|
Update the hotfix record with root cause, fix details, and test results.
|
|
|
|
---
|
|
|
|
## Phase 5: Collect Approvals
|
|
|
|
Use the `Agent` tool to request sign-off in parallel:
|
|
|
|
- `subagent_type: lead-programmer` — Review the fix for correctness and side effects
|
|
- `subagent_type: qa-tester` — Run targeted regression tests on the affected system
|
|
- `subagent_type: producer` — Approve deployment timing and communication plan
|
|
|
|
All three must return APPROVE before proceeding. If any returns CONCERNS or REJECT, do not deploy — surface the issue and resolve it first.
|
|
|
|
---
|
|
|
|
## Phase 5b: QA Re-Entry Gate
|
|
|
|
After approvals, determine the QA scope required before deploying the hotfix. Spawn `qa-lead` via `Agent` with:
|
|
- The hotfix description and affected system
|
|
- The regression test results from Phase 5
|
|
- A list of all systems that touch the changed files (use Grep to find callers)
|
|
|
|
Ask qa-lead: **Is a full smoke check sufficient, or does this fix require a targeted team-qa pass?**
|
|
|
|
Apply the verdict:
|
|
- **Smoke check sufficient** — run `/smoke-check` against the hotfix build. If PASS, proceed to Phase 6.
|
|
- **Targeted QA pass required** — run `/team-qa [affected-system]` scoped to the changed system only. If QA returns APPROVED or APPROVED WITH CONDITIONS, proceed to Phase 6.
|
|
- **Full QA required** — S1 fixes that touch core systems may require a full `/team-qa sprint`. This delays deployment but prevents a bad patch.
|
|
|
|
**If the QA step returns `NOT ASSESSED`, the gate did not run — treat it as unmet,
|
|
not as met.** `/smoke-check` returns it when the suite never executed and
|
|
`/team-qa` when a cycle produced no executed evidence. **A NOT ASSESSED result is
|
|
not a pass** — from either skill — and under time pressure the permissive reading
|
|
is the one that will feel reasonable,
|
|
which is exactly why it is written down here. Either obtain the missing result —
|
|
the verdict names what would make it runnable — or take the decision to the
|
|
producer explicitly, as a decision to deploy an unverified hotfix rather than as a
|
|
gate that quietly cleared.
|
|
|
|
Do not skip this gate. A hotfix that breaks something else is worse than the original bug.
|
|
|
|
---
|
|
|
|
## Phase 6: Update Bug Status and Deploy
|
|
|
|
> **STOP — deployment requires explicit approval, unconditionally.** Merging a
|
|
> hotfix to a release branch is the one irreversible act in this skill, so it is
|
|
> gated even though branch creation (reversible) already is. Before any merge,
|
|
> tag, or deploy, use `AskUserQuestion`:
|
|
>
|
|
> - Prompt: "Hotfix validated and approved. Merge to the release branch and
|
|
> deploy?"
|
|
> - Options: `[A] Yes — merge and deploy` / `[B] Merge to development only — hold
|
|
> the release` / `[C] Stop here`
|
|
>
|
|
> This holds regardless of `modes.automation`, including `autonomous`. An
|
|
> emergency process is exactly where an unreviewed irreversible step is most
|
|
> likely and least recoverable.
|
|
|
|
> **Backport is not verified unless you verify it.** The frontmatter advertises
|
|
> "backport verified", and until this note the word `backport` appeared **once in
|
|
> this file — in that claim**. After merging, confirm the fix is present on BOTH
|
|
> the release branch and the development branch, and state the result. An
|
|
> unbackported hotfix means the bug returns in the next release from development,
|
|
> which is the single most common hotfix regression.
|
|
|
|
Update the original bug file if one exists:
|
|
|
|
```markdown
|
|
## Fix Record
|
|
**Fixed in**: hotfix/[branch-name] — [commit hash or description]
|
|
**Fixed date**: [date]
|
|
**Status**: Fixed — Pending Verification
|
|
```
|
|
|
|
Set `**Status**: Fixed — Pending Verification` in the bug file header.
|
|
|
|
Output a deployment summary:
|
|
|
|
```
|
|
## Hotfix Ready to Deploy: [short-name]
|
|
|
|
**Severity**: [S1/S2]
|
|
**Root cause**: [one line]
|
|
**Fix**: [one line]
|
|
**QA gate**: [Smoke check PASS / Team-QA APPROVED / NOT ASSESSED — [why, and whose
|
|
explicit decision it was to deploy anyway]]
|
|
**Approvals**: lead-programmer ✓ / qa-tester ✓ / producer ✓
|
|
**Backport**: [verified present on release AND development — or NOT VERIFIED, with
|
|
what was not checked]
|
|
**Rollback plan**: [from Phase 2 record]
|
|
|
|
Merge to: release branch AND development branch
|
|
Next: /bug-report verify [BUG-ID] after deploy to confirm resolution
|
|
```
|
|
|
|
### Rules
|
|
- Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring
|
|
- Every hotfix must have a rollback plan documented before deployment
|
|
- Hotfix branches merge to BOTH the release branch AND the development branch
|
|
- All hotfixes require a post-incident review within 48 hours
|
|
- If the fix is complex enough to need more than 4 hours, escalate to `technical-director`
|
|
|
|
---
|
|
|
|
## Phase 7: Post-Deploy Verification
|
|
|
|
After deploying, run `/bug-report verify [BUG-ID]` to confirm the fix resolved the issue in the deployed build.
|
|
|
|
If VERIFIED FIXED: run `/bug-report close [BUG-ID]` to formally close it.
|
|
If STILL PRESENT: the hotfix failed — immediately re-open, assess rollback, and escalate.
|
|
|
|
Schedule a post-incident review within 48 hours using `/retrospective hotfix`.
|
|
|
|
Use `AskUserQuestion`:
|
|
- Prompt: "Hotfix complete. What's the next step?"
|
|
- Options:
|
|
- `[A] Run /smoke-check to verify the fix`
|
|
- `[B] Run /patch-notes to document this hotfix`
|
|
- `[C] Stop here`
|