Use this skill before changing behaviour that affects customers, traders, stock, pricing, or orders.
Establish the domain language first:
- A trader is a business customer; Proto does not sell to the general public.
- A product may have multiple SKU or colour variants, catalogue visibility, and live stock state.
- Search, catalogue, extended-range, and stock are related but distinct capabilities.
- A price or stock value shown to a user may need a fresh review before order submission.
- Archive and unarchive operations must be idempotent and should explain an already-current state rather than fail noisily.
- Main-site, admin, catalogue, stock, registration, and order-notification flows have different responsibilities and failure modes.
For each proposed change:
- State the user and business outcome.
- Identify the entities, states, invariants, and integration boundaries involved.
- Describe the happy path and at least three edge cases.
- Decide which checks belong in the browser, API, database, or upstream service.
- Add tests for the invariant before changing implementation.
- Verify both the trader-facing and admin-facing consequences.
Do not invent pricing, stock, minimum-order, fulfilment, or authentication rules. Ask the user or inspect the authoritative Proto implementation and documentation.
1---2name: proto-commerce-domain3description: Model and improve Proto's wholesale catalogue, trader accounts, pricing, stock, orders, fulfilment, and admin workflows.4---56Use this skill before changing behaviour that affects customers, traders, stock, pricing, or orders.78Establish the domain language first:910- A trader is a business customer; Proto does not sell to the general public.11- A product may have multiple SKU or colour variants, catalogue visibility, and live stock state.12- Search, catalogue, extended-range, and stock are related but distinct capabilities.13- A price or stock value shown to a user may need a fresh review before order submission.14- Archive and unarchive operations must be idempotent and should explain an already-current state rather than fail noisily.15- Main-site, admin, catalogue, stock, registration, and order-notification flows have different responsibilities and failure modes.1617For each proposed change:18191. State the user and business outcome.202. Identify the entities, states, invariants, and integration boundaries involved.213. Describe the happy path and at least three edge cases.224. Decide which checks belong in the browser, API, database, or upstream service.235. Add tests for the invariant before changing implementation.246. Verify both the trader-facing and admin-facing consequences.2526Do not invent pricing, stock, minimum-order, fulfilment, or authentication rules. Ask the user or inspect the authoritative Proto implementation and documentation.
Gee9999