qarium goga-define-constraints
Purpose
Identify and document the product constraints that must be respected by the solution.
Transform the existing product context, problem, users, goals, user experience, and requirements into a clear set of constraints that limit or shape the possible product solution.
Constraints describe what the solution must respect. They do not prescribe how the solution should be implemented.
Contract
consume:
- product
- problem
- users
- goals
- user_experience
- requirements
produce:
- constraints
Core Principle
A constraint is a condition that the product solution must respect.
It may come from:
- existing product behaviour;
- business rules;
- user expectations;
- regulatory or contractual obligations;
- dependencies outside the product;
- explicitly stated organizational constraints;
- limitations that materially affect the product experience.
A constraint is not a technical preference.
For example:
Users cannot cancel an order after preparation has started.
is a product constraint.
This is not:
Store the order state in PostgreSQL.
That is an implementation decision.
Product Interview
Do not infer constraints from technical assumptions, personal preferences, or conventional implementation choices.
Determine which boundaries are intentional product constraints.
Interview the user when it is unclear whether a limitation is:
- mandatory;
- preferred;
- temporary;
- negotiable;
- outside the product decision.
Examples of decisions that may require clarification:
- compatibility requirements;
- supported user groups;
- availability limitations;
- operational boundaries visible to users;
- mandatory business rules;
- regulatory or organizational restrictions when relevant to the product.
Do not turn an engineering preference into a product constraint.
Process
1. Inspect the existing product
Identify existing product behaviour that the new solution must preserve.
Consider:
- established user flows;
- existing rules;
- existing states;
- existing permissions;
- existing user expectations;
- behaviour that must not regress.
Do not treat every existing implementation detail as a constraint.
Only preserve existing behaviour when changing it would materially affect the product decision.
2. Identify business constraints
Determine rules that limit what the product can do.
Examples:
- an action is available only under certain conditions;
- a user cannot modify an object after a particular state;
- specific information must be shown;
- a particular action requires approval;
- a process must follow a defined business rule.
Express the constraint in product language.
3. Identify user-facing constraints
Consider limitations that directly affect the experience.
Examples:
- users must be able to recover from a failed action;
- a user cannot be asked to repeat information unnecessarily;
- sensitive information must not be shown to unauthorized users;
- an irreversible action must be clearly communicated.
Do not turn general UX preferences into constraints unless they materially restrict the solution.
4. Identify external constraints
Consider constraints imposed from outside the product itself.
Examples may include:
- contractual obligations;
- regulatory requirements;
- external system behaviour;
- mandatory business processes;
- dependencies controlled by another party.
Include only constraints that are known or explicitly provided.
Do not invent regulatory, legal, or organizational requirements.
5. Distinguish constraints from requirements
Use this distinction:
Requirement
What the product must do.
Constraint
What the solution must respect while doing it.
Example:
Requirement:
The user can cancel an eligible order.
Constraint:
An order cannot be cancelled after preparation begins.
A single constraint may influence multiple requirements.
6. Distinguish constraints from implementation decisions
Do not treat technical choices as constraints unless they are explicitly imposed and genuinely cannot be changed.
Examples that are normally not constraints:
- preferred programming language;
- preferred framework;
- database choice;
- API style;
- internal service structure;
- deployment platform;
- coding conventions.
If such information is provided as an external requirement, preserve it only when it genuinely constrains the product solution.
Do not introduce technical constraints yourself.
Constraint Quality
Each constraint should be:
Relevant
It materially affects the product solution.
Explicit
Its meaning is clear.
Justified
Its origin can be understood from the available context.
Stable
It represents a condition that the solution must respect rather than a temporary implementation preference.
Product-oriented
It describes a condition affecting product behaviour, users, or business rules.
Challenge the Constraint Set
Challenge the identified constraints.
Ask:
- Is this actually a constraint or just a preference?
- Is it relevant to the current problem?
- Is it supported by the existing product context?
- Does it contradict a requirement?
- Does it unnecessarily restrict the solution?
- Are we treating an implementation detail as a product constraint?
- Are there known constraints that materially affect the user experience but are missing?
Do not invent constraints merely to make the PRD appear more complete.
Relationship With Requirements
Check:
Requirements
↕
Constraints
Requirements must be compatible with all established constraints.
If a requirement violates a constraint, report a conflict.
Do not silently weaken either side.
Conflict Detection
Report a conflict when:
- a requirement contradicts a constraint;
- a goal cannot be achieved under the known constraints;
- the user experience violates an established constraint;
- existing product behaviour conflicts with the requested change;
- two constraints are mutually incompatible.
Example:
conflict: |
The requirement allows every user to access the requested
information, while an existing product constraint limits
this information to authorized users.
reason: |
The requirement conflicts with an established access rule.
The orchestrator will invoke goga-define-resolve.
Do not resolve cross-context conflicts yourself.
Missing Information
Ask the user only when a missing constraint materially affects the product decision.
Valid questions may concern:
- business rules;
- mandatory user behaviour;
- existing product limitations;
- external dependencies;
- permissions;
- irreversible actions;
- obligations that the product must respect.
Do not ask about technical implementation.
Do not invent legal, regulatory, or business constraints.
Do Not Define
This skill must not define:
- technical architecture;
- programming languages;
- databases;
- APIs;
- infrastructure;
- implementation patterns;
- development tasks;
- project plans.
Those decisions belong to engineering design.
Output
Produce a concise set of relevant product constraints.
Each constraint should clearly describe:
- what must be respected;
- why it matters when necessary;
- which product behaviour it affects when relevant.
Do not include irrelevant limitations or technical preferences.
The final result must give the following Scope stage a clear understanding of the boundaries within which the product solution must be designed.
Before producing constraints, verify that each constraint is intentional.
If removing a supposed constraint would materially change the product decision, confirm it with the user rather than assuming it.