Phase 1: Define the Question

Phase 1:

Define the Question

What Is This?

“Phase 1: Define the Question” is the initial step in the rapid prototyping workflow for the Happycapy Skills platform, specifically within the prototype skill. This phase ensures that the purpose of a game prototype is clearly established before any code is written. Its primary function is to extract or clarify the core question or hypothesis that the prototype should answer, based on the concept description provided by the user. By doing so, it prevents wasted effort on vague or unfocused prototypes and creates a structured foundation for all subsequent phases.

This phase is triggered when a user invokes the prototype skill with a concept description and an optional review mode flag (--review full|lean|solo). The skill will also determine the review mode based on existing settings or defaults if not explicitly provided.

Why Use It?

Defining the core question at the outset is critical for effective prototyping. Game development is full of open-ended ideas, and without a clear question to answer, prototypes often fail to deliver actionable insights. The main reasons to use this phase are:

• Focus: It distills the concept into a single, actionable question, avoiding scope creep and wasted effort.
• Alignment: Ensures that all team members and stakeholders understand and agree on the prototype’s purpose.
• Efficiency: Prevents time being spent on unnecessary features or code, as only the elements needed to answer the core question are considered.
• Documentation: Provides a clear record of what the prototype is intended to validate, which is especially useful when presenting results or revisiting the concept later.

How to Use It

The prototype skill is invoked through the Happycapy Skills platform, typically with a command structure like:

prototype "[concept-description]" [--review full|lean|solo]

Step-by-Step Process

1. Resolve the Review Mode:

   • If the --review flag is provided, the skill uses that value.
   • If not, it checks for a persisted setting in production/review-mode.txt.
   • If neither is set, it defaults to lean.

   Example Code Snippet:

   bash

   # Bash pseudocode for resolving review mode
   if [ "$REVIEW_MODE" != "" ]; then
       mode="$REVIEW_MODE"
   elif [ -f production/review-mode.txt ]; then
       mode=$(cat production/review-mode.txt)
   else
       mode="lean"
   fi

2. Extract the Concept Description:

   • The skill reads the concept description from the command arguments.

3. Identify the Core Question:

   • The skill analyzes the concept description to determine the main question the prototype must answer.
   • If the description is ambiguous, the skill explicitly states a suggested core question and seeks clarification before proceeding.

   Example:

   plaintext

   Input: "A platformer with a grappling hook mechanic."
   Output: "Core question: Does the grappling hook mechanic feel fun and controllable in a basic platforming environment?"

4. Gatekeeping:

   • If the core question cannot be clearly defined, the skill prompts the user to clarify before moving to the next phase.

When to Use It

Use Phase 1 whenever you are starting a new rapid prototype using the prototype skill, especially when:

• You need to quickly test a new game mechanic, interaction, or system.
• The concept is still high-level and lacks technical specification.
• There are multiple possible directions for implementation and you need to focus efforts.
• You are working in a team and need consensus on what the prototype should accomplish.

This phase is essential for all prototypes that aim to answer a specific design or technical question. It is less relevant for production-ready features or when the requirements are already fully specified.

Important Notes

• Strict Gatekeeping: The process will halt if a clear question cannot be established. This is not a limitation but a safeguard to prevent wasted work.
• Review Modes: The skill supports three review modes (full, lean, solo). These influence how much feedback or oversight is required in later phases, but the question-defining logic is always enforced.
• Throwaway Code: The rapid prototyping workflow explicitly skips polish and long-term maintainability. Only the minimum viable code to answer the core question is built.
• Documentation: Each prototype run generates a structured report, including the defined question, for future reference.
• Refer to Documentation: For details on the review mode selection logic and the director gates mechanism, consult .claude/docs/director-gates.md in your repository.

By rigorously defining the question at the outset, Phase 1 ensures that the prototype delivers meaningful answers and maximizes the value of rapid experimentation. This discipline is especially valuable in early-stage game development, where ideas are plentiful but time and resources are limited.