How to Pass a Dressmaker Commission

Quick answer

A commission is read as two blocks of information: the budget attached to the request, and the attribute limits the customer set on the garment. Read both before choosing a pattern or a material, decide whether the garment can plausibly meet every limit, build it, then check the finished values against the recorded limits and deliver only when the two sets agree.

How a request is structured

The store description describes the commission loop as a customer asking for a garment that is then judged against the request. In practice a request presents two kinds of information. The first is a budget, the amount the request carries. The second is a set of attribute expectations attached to the garment: one or more attributes, each with a minimum, a maximum, or both.

The two blocks are read differently. The budget constrains what can be spent on materials. The limits constrain what the garment has to measure once it is finished. A cheap garment that misses a minimum fails on the limits, and an expensive garment that overshoots a maximum can fail as well, which is why a maximum deserves the same attention as a minimum.

This page does not state what the attributes are called or what any limit is worth. Those come from the request on screen, and the method below is written so that it works with whatever set the request names. The commission index holds structured records once a request can be traced to a dated source.

A reading order for any request

The order matters more than the speed. Each step below produces something the next step needs, so the note fills in one direction only.

1. Read the whole request once without writing anything. The first pass is for seeing how many distinct demands the request contains.
2. Write the budget down as the first line of the note. Everything spent on the attempt is measured against it.
3. List each attribute the request names, in the order it shows them. Leave space beside each one for its bounds.
4. Fill in every stated minimum and maximum next to its attribute. Where a bound is not shown, write not stated instead of leaving the space blank, so a missing bound cannot later be mistaken for a zero.
5. Mark the limit that is hardest to satisfy. That limit decides what the rest of the build has to protect.
6. Note the garment requested and anything the request itself excludes, such as a material or a pattern it rules out.
7. Estimate the cost of the cheapest plausible material set and compare it with the budget before anything is bought.
8. Keep the note open while building, and add the values the game reports at each stage beside the limits they are meant to satisfy.

Deciding whether a request is reachable, and what to do when it is not

Reachability is a decision made from the numbers already written down, and it has three parts. First, does the budget cover a material set that can plausibly reach the strictest minimum? Second, can that same set stay under every maximum? Third, if both hold, is there a pattern that produces the requested garment at all?

A request that fails the first test is set aside before any material is bought. A request that passes the first but fails the second is not hopeless: it usually means the material set is stronger than it needs to be, and a lighter or cheaper option may satisfy both ends. That is why the note records the budget and the limits on the same sheet rather than in separate places. The commission checker performs the arithmetic on the values typed into it, but it does not know the game’s catalogue and cannot say which material exists.

Some limits will not be reachable with the patterns and materials currently available. The useful response is to record the shortfall precisely instead of forcing a delivery. Re-read the limit and confirm which attribute it belongs to, because a misread attribute turns a reachable request into an impossible one. Confirm the direction of the bound too, since a maximum read as a minimum inverts the whole problem.

Then record which values the best candidate reached and how far it fell short, with the date, and leave the attempt in the note even though it failed. A failed attempt written down this way states what was tried, with what materials, and what the game reported, which is the shape of record the source register can actually use. Deliver only when every stated limit is satisfied; otherwise keep the note and move to another request.

Recording the request so a failed attempt is still useful

A failed delivery is only wasted if nothing was written down. The fields below are enough to make the next attempt a comparison rather than a fresh guess.

A worked reading example, with placeholder labels

Everything in this section is a placeholder. The labels and numbers were chosen to make the reading method visible; none of them are Dressmaker data, and none of them should be copied into a session note. A real note keeps the same shape and replaces each placeholder with what the screen shows.

On these placeholders the candidate clears both bounds, because A sits above its minimum and B sits below its maximum. If A had returned 38 instead, the candidate would fail the minimum no matter how well B performed, which is the reason the strictest limit is marked first in the reading order above.

Two further notes follow from the example. The budget never enters the finished-value comparison, because a budget constrains spending rather than the garment. And a bound that the request does not state is written as not stated, so it never enters the arithmetic as a zero. Both rules exist to stop the note from answering a question the request did not ask.

What stays unknown

No budget range, attribute name, threshold, quality formula or material price is published on this page. No dated source read for this site states them, so the page will not estimate them. A community discussion of selling prices labels its own figure as an estimate — community-reported, checked 2026-09-28 — and that is exactly why its number is not restated here as a rule.

Also unresolved: whether every request uses the same attribute set, how a value is rounded when it sits exactly on a bound, whether a maximum is evaluated before or after a finishing detail is added, and what else the delivery outcome depends on. Each of those is a question to answer from the screen with one change at a time, not a gap to fill with a plausible guess.

The beginner guide puts the reading order into a first session, and the fabric guide covers the material comparison that the budget feeds into. Neither publishes a value that the game itself has not been seen to state.