Phase 1: Parse Arguments

argument-hint: "[version] [--style brief|detailed|full]"

Phase 1:

Parse Arguments - Technical Overview

What Is This

The "Phase 1: Parse Arguments" skill is the initial processing phase for the patch-notes skill on the Happycapy Skills platform. This phase is responsible for interpreting user input when invoking the patch-notes skill, extracting and validating command-line arguments, and ensuring the operation can proceed with accurate context. It specifically handles the arguments related to generating player-facing patch notes for a designated version of a game or software product. The parsing routine serves as a critical gatekeeper, ensuring that all required information is present in the correct format before any subsequent data gathering or note generation occurs.

Why Use It

Parsing arguments effectively is essential for any command-line or user-invocable skill that operates with variable input. In the context of the patch-notes skill, precise argument parsing:

  • Prevents User Error: By validating the presence and format of the version and --style arguments, the skill helps avoid ambiguous or incomplete requests.
  • Automates Workflows: Users can quickly generate tailored patch notes by providing clear parameters, minimizing back-and-forth and manual corrections.
  • Supports Multiple Output Styles: With the --style flag, users can choose among brief, detailed, or full output formats, enhancing flexibility based on audience or context.
  • Enforces Consistency: By standardizing input expectations, the phase ensures reproducible and predictable patch note generation across teams and releases.

This phase is indispensable for maintaining a robust, user-friendly, and error-resistant interface between the skill and its users.

How to Use It

Invocation Syntax

The argument parsing phase expects the following syntax when invoking the skill:

/patch-notes [version] [--style brief|detailed|full]
  • version (required): The release version for which to generate notes, such as 1.2.0.
  • --style (optional): The output style. Accepts brief, detailed, or full. If omitted, defaults to detailed.

Argument Parsing Logic

Upon invocation, the phase performs these steps:

  1. Extract Arguments: The skill splits the input into tokens, identifying the version and optional --style flag.
  2. Validate Version: Checks if a version is provided and matches the expected format (e.g., 1.2.0). If missing, prompts the user explicitly before proceeding.
  3. Parse Style: Verifies the presence of the --style flag and its value. If not provided, defaults to detailed.
Example:

Minimal Usage

/patch-notes 1.3.2
  • Outputs patch notes for version 1.3.2 in detailed style.
Example:

Specifying Style

/patch-notes 1.3.2 --style brief
  • Outputs patch notes for version 1.3.2 in bullet-point format.
Example:

Missing Version

/patch-notes --style full
  • The skill will prompt: "Please specify the release version you want patch notes for."

Pseudocode Example

Below is a simplified pseudocode that illustrates the argument parsing process:

def parse_arguments(input_str):
    tokens = input_str.split()
    version = None
    style = 'detailed'

    for i, token in enumerate(tokens):
        if token == '--style':
            if i + 1 < len(tokens):
                style = tokens[i + 1]
        elif token.count('.') == 2 and token.replace('.', '').isdigit():
            version = token

    if not version:
        print("Please specify the release version you want patch notes for.")
        return None

    if style not in ['brief', 'detailed', 'full']:
        print("Invalid style. Use: brief, detailed, or full.")
        return None

    return version, style

When to Use It

The argument parsing phase is triggered whenever a user or automated system invokes the patch-notes skill directly. Typical scenarios include:

  • Release Preparation: Before publishing a new game or software version, use this skill to generate clear, player-facing patch notes.
  • QA Review: When QA or production teams need to communicate changes to stakeholders in specific formats.
  • Sprint Retrospectives: During or after a development sprint when summarizing changes for internal or external audiences.
  • Automated Workflows: As part of continuous integration pipelines where patch notes need to be generated programmatically based on version tags.

Important Notes

  • Mandatory Version Argument: The version argument is required. If not supplied, the skill will halt and prompt the user for this critical information.
  • Strict Style Options: The --style flag only accepts brief, detailed, or full. Any other values will result in an error.
  • Default Behavior: If the --style flag is omitted, the output style defaults to detailed, providing a balance between brevity and context.
  • Blocking on Missing Data: If argument parsing fails (specifically if the version is missing or invalid), the skill will not proceed to subsequent phases, preventing incomplete or incorrect patch note generation.
  • User Invocable: This phase is not limited to automated scripts; real users can invoke the skill directly via chat or CLI, making clear argument parsing and prompting essential for usability.
  • Integration with Other Phases: Successful argument parsing is a prerequisite for the skill to gather change data and generate output. Errors at this stage prevent unnecessary file reads or processing, optimizing resource use and user experience.

By enforcing strict yet flexible argument parsing, Phase 1 of the patch-notes skill ensures that all subsequent operations start on a solid, unambiguous foundation. This approach supports accurate, user-friendly patch note generation tailored to a wide variety of use cases.