Requirements clarification and decomposition before CleanDDD modeling, producing structured requirement descriptions (scenarios, stakeholders, business entity classification), facilitating subsequent modeling or implementation.
Prerequisite Inputs
- Business requirements/change descriptions have been obtained (documents, meeting minutes, or conversations).
- When not yet modeled or when major adjustments to the existing model are needed, run this skill first before handing off to cleanddd-modeling.
Workflow (only perform requirements analysis and structured description, do not perform modeling definitions)
- Obtain and confirm scope: collect business scenarios, roles, inputs and outputs, constraints; ask follow-up questions first for missing information.
- Stakeholder identification: list all participating roles (such as C-end customers, backend administrators, audit, operations, etc.), and clarify the object each requirement is oriented toward.
- Requirement decomposition: split into executable items by "view/create/modify/close/async task", assign requirement IDs, and annotate the corresponding stakeholders.
- Business entity classification: classify requirement items by the business entity/domain object responsible for satisfying the requirement, record core responsibilities and constraints (do not perform aggregate/command/event modeling).
- "When X, do Y" trigger scenarios: identify follow-up actions triggered by events/states/operations, record them as "trigger condition → action/impact → involved roles/entities", still remaining at the requirement level, not entering modeling.
- Constraints and inputs/outputs: supplement key business rules, preconditions, dependent systems or data; annotate gaps and assumptions.
- Summarize output and reconfirm: present a table to the user, annotating assumptions and items to be confirmed.
Output Format (Structured Markdown)
- Stakeholder table: Role | Goals/Pain Points | Permissions/Restrictions | Remarks
- Requirement item table: Requirement ID | Scenario Description | Stakeholder/Object | Owning Business Entity | Operation Type (view/create/modify/close/async, etc.) | Constraints/Preconditions | Remarks/Gaps
- Business entity view: Business Entity | Covered Requirement Items | Main Responsibilities/Rules | Key Inputs/Outputs
- Trigger/Follow-up Action table: Trigger Condition (when X operation/event/state) | Follow-up Action/Impact (then do Y) | Related Stakeholders | Affected Business Entities | Remarks/Assumptions
- Business Rules and Dependencies (optional): Rule/Constraint | Related Entities | Dependent Systems/Data | Remarks
- Assumptions and Items to Confirm list: Item | Description | Owner | Deadline/Priority
Unified Naming and Placement Conventions
- Table naming and column headers: output uniformly according to the header format in the sections, facilitating parsing by downstream skills.
- Unified terminology: this skill remains at the "requirement level" terminology, avoiding the premature introduction of modeling terms such as aggregate/command; clearly distinguished from the terminology of
cleanddd-modeling. - Document location: it is recommended to save the output of this skill as
analysis/requirements.mdin the repository or have the Agent summarize it in the session record, facilitating subsequent reference bycleanddd-modeling.
Post-Output Reminders
- Append a "parameter summary + whether executed" prompt at the end of the output, facilitating subsequent confirmation or handoff to downstream modeling skills.
- Clearly state unresolved issues and assumptions, facilitating handoff in subsequent modeling or implementation phases.