customer-problems

The customer-problems skill provides a structured framework for the initial stage of the Problem-Based Software Requirements Specification (SRS) methodology. It is designed to assist software engineers, tech leads, and product managers in moving from vague stakeholder feature requests toward a rigorous understanding of the underlying business problems. By focusing on the 'WHY' domain, this skill ensures that development efforts are explicitly traced to justified business needs, thereby preventing the common industry failure of building technical features that lack business value.

The skill operates in two primary modes: generation and review. In generation mode, it processes raw business context to extract and validate problem statements using a precise syntax consisting of a subject, severity-indicating verb (must, expects, hopes), object, and penalty. This structure forces a clear articulation of consequences for unsolved issues. In review mode, it normalizes draft statements into this canonical format, identifies missing information, and flags potential ambiguities, ensuring that requirements are ready for subsequent steps such as Software Glance and Customer Needs.

• Enables systematic discovery of real customer problems from unstructured business context.

• Standardizes problem documentation into a consistent [Subject] [Verb] [Object] [Penalty] syntax for traceability.

• Classifies problems by severity (Obligation, Expectation, Hope) to support prioritization.

• Provides automated validation and normalization of draft requirements to reduce rework.

• Integrates with broader requirements engineering workflows including Business Context (Step 0) and Software Glance (Step 2).

• Best input involves a structured Business Context (e.g., project identity, stakeholders, current situation, and domain boundaries).

• Ideal for scenarios where stakeholders describe 'how' they want a feature to look rather than 'what' problem they are facing.

• Adheres to BCP 14 standards for normative keywords when used in documentation context.

• The skill explicitly does not define technical solutions or derive functional requirements, maintaining a strict boundary between problem identification and architectural design.

• Requires consistent use of 'CP-' IDs to maintain linkage between artifacts throughout the software development lifecycle.