Phase 1: Assess Severity

allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task

Phase 1:

Assess Severity for the Hotfix Skill

The "Phase 1: Assess Severity" step is the critical initial gate in the hotfix workflow on the Happycapy Skills platform. This skill, identified as hotfix, provides a controlled, auditable process for deploying emergency fixes outside the normal sprint cadence. Phase 1 ensures that only issues of sufficient severity justify invoking this expedited path, minimizing risk while enabling rapid response to critical bugs.

What Is This?

"Phase 1: Assess Severity" is the first step in the hotfix skill workflow. When invoked by a user, it evaluates the severity of a reported bug or incident using a standardized triage process. This phase explicitly determines whether the issue qualifies as:

  • S1 (Critical): Game is unplayable, there is data loss, or a security vulnerability is identified. Requires immediate attention and hotfix deployment.
  • S2 (Major): Significant feature is broken, but a workaround exists. Requires hotfix within 24 hours.
  • S3 or Lower: Minor or cosmetic issues. These do not qualify for the hotfix process and should be handled through normal sprint-based workflows.

By enforcing explicit severity assessment, this phase prevents misuse of the hotfix path and ensures that only truly urgent issues bypass regular development processes.

Why Use It?

The hotfix process is inherently risky; it bypasses some safeguards of the standard sprint cycle to rapidly address production issues. "Phase 1: Assess Severity" is essential because:

  • Reduces Risk: By clearly defining what constitutes a hotfix-worthy issue, it prevents unnecessary disruption and mitigates the chance of introducing regressions.
  • Ensures Auditability: The assessment creates an explicit record of why the hotfix was justified, facilitating postmortems and compliance checks.
  • Promotes Consistency: All team members use the same severity criteria, ensuring fairness and eliminating ambiguity in the decision to escalate.
  • Streamlines Workflow: By immediately filtering out S3 or lower issues, it saves time and keeps the emergency path clear for genuine crises.

How to Use It

The "Phase 1: Assess Severity" skill is invoked with the /hotfix command, along with a bug description or ID. The skill will perform the following steps:

  1. Read Input: It parses the provided bug description or references the bug ID to gather context.

  2. Evaluate Severity: The skill guides the user through the following triage:

    • S1 (Critical):
      • Game is unplayable for most users
      • Data loss has occurred or is likely
      • Security vulnerability is present
      • Action: Proceed to hotfix immediately
    • S2 (Major):
      • Major feature is nonfunctional but a temporary workaround exists
      • Significant negative impact on user experience
      • Action: Initiate hotfix within 24 hours
    • S3 or Lower:
      • Minor bugs, cosmetic issues, small annoyances
      • Action: Do not proceed with hotfix; use the standard bug fix workflow
  3. Prompt for Confirmation: If the severity is S1 or S2, the skill proceeds to the next phase, drafting a hotfix record. If severity is S3 or lower, the user is advised to follow the regular process.

Example

Suppose a user identifies a bug where players are unable to log in to the game:

/hotfix "Players are unable to log in after the latest update."

The skill will assess:

  • Is the game unplayable? Yes.
  • Severity: S1 (Critical)
  • Recommendation: Proceed to hotfix.

If a user reports a visual bug (e.g., a minor UI misalignment):

/hotfix "Inventory icon is misaligned by 2 pixels on the main screen."

The skill will assess:

  • Is the game unplayable? No.
  • Severity: S3 (Minor)
  • Recommendation: Use normal bug fix workflow.

When to Use It

Invoke "Phase 1: Assess Severity" in the following scenarios:

  • Production Emergencies: When a newly discovered bug is impacting live players and may require immediate remediation.
  • Security Incidents: On discovery of vulnerabilities that could compromise user data or system integrity.
  • Major Feature Outages: When a core gameplay element fails in a way that cannot wait for the next sprint cycle.

Do not use this skill for minor bugs, feature requests, or issues that do not directly impact gameplay or data integrity. Such issues should follow the regular sprint-based bug triage and resolution process.

Important Notes

  • Explicit Invocation Only: The hotfix skill must only be triggered manually by users with the /hotfix command. It will never auto-invoke based on contextual cues, ensuring deliberate usage.
  • Allowed Tools: The skill has access to Read, Glob, Grep, Write, Edit, Bash, and Task tools, but will not execute any changes until the severity assessment is complete.
  • Audit Trail: Every invocation and severity assessment is logged as part of the hotfix record for future review.
  • Strict Escalation Criteria: Adherence to the S1/S2/S3 definitions is critical. Overusing the hotfix process for non-urgent issues can lead to increased risk and technical debt.
  • Collaboration: The skill prompts for clear documentation, setting up the next phase where the hotfix record is created, including the problem statement, root cause, and approval checklist.

In summary, "Phase 1: Assess Severity" is the gatekeeper for the hotfix workflow, ensuring that only critical and major issues are escalated for immediate attention. Its disciplined approach protects stability, supports compliance, and maintains operational efficiency in high-pressure production environments.