Modebase Wardrobe

Get how MANY items the user owns plus a breakdown by category and colour, with category labels normalised into clean families (e.g. Top/Shirt/Jumper are counted together as Tops). Returns ONLY: totalActiveItems, needsPhotoItems, totalItems, categories, colours. Use it to answer "how many items do I have / what are my main categories" directly and concisely; report the totals and the main normalised categories, and do NOT bring in styling preferences, avoided pieces, saved outfits or individual garments unless the user asks. To SHOW or PREVIEW the actual pieces, call search_wardrobe (with no filters) instead.

get_wardrobe_overview

Get recent logged outfits, feelings, and how often items get worn.

get_wear_history

Log that the user wore these items, on a given date. ALWAYS capture the context the conversation already gives you — do NOT log a bare date + items when more was said. Pass `occasion` when they mention where/what it was for (a wedding, the office, a dinner, a casual day), `feeling` when they say how it felt or how they felt in it (comfortable, overdressed, great), and `weather_note` when the weather/climate is evident (hot, rainy, cold, humid). These fields power cost-per-wear and smarter future suggestions, so filling them when present is part of the job; leave a field out only when the conversation genuinely didn't reveal it (never invent).

log_wear

SEE the pieces before you choose between them. Pass 2-8 item ids you are weighing for the SAME slot in a look (six candidate trousers, three possible jackets) and this returns a numbered picture of their actual cut-outs, laid out side by side, so you can judge them on how they LOOK — cut, proportion, drape, the real shade — not only on their written attributes. WHEN TO USE IT: after search_wardrobe has narrowed the wardrobe to a shortlist and the choice between the finalists is a visual one. Narrow with search_wardrobe FIRST; this is the last step before deciding, never a way to browse. Each piece is numbered in the picture and the result maps every number to its item id, so say which number you chose and why it beat the others. Pieces need a clean cut-out to appear: any that could not be shown come back in `notShown`, and you must judge those on their written detail instead and say so rather than ignoring them.

compare_pieces

PREREQUISITE: only call this once prepare_styling_brief has returned ready:true for this request. If material occasion, destination, duration, activity, weather or dress-code information is missing, ask the user those questions FIRST (via prepare_styling_brief) and do NOT call this tool until it returns ready:true. Compose a SINGLE outfit from the user's real garments and return text plus a Modebase link that opens the exact flat-lay. This tool shows the look inline as a composited flat-lay of the user's real garments AND returns a Modebase link — always surface the link too. Use this whenever you suggest ONE thing to wear, and in a day-by-day plan call it once per day. To COMPARE 2 OR MORE outfit OPTIONS, use show_outfits instead (do NOT call show_outfit repeatedly for a comparison). Pass the item ids you have chosen; it validates them against the user's active wardrobe (rejecting invented/non-owned/inactive ones, reported as invalidIds). Do NOT package the look into a workspace (create_lookbook) for an ordinary 'show me an outfit' request, and never draw the outfit with your own image generator. This is a PREVIEW: it opens the outfit, it does NOT save it (use save_outfit for that). Get ids from search_wardrobe or get_style_profile first. Build each outfit by filling these slots FROM THE USER'S WARDROBE ONLY: a top + a bottom (OR one dress/jumpsuit instead of both), shoes, optionally a bag, up to two accessories, and optionally a jacket or layer. Every slot must be a real, owned piece these tools returned, referenced by its id and name. NEVER invent, assume, or add a piece that isn't in the results — no imagined shoes, bag, coat, belt, or jewellery, and nothing from your general fashion knowledge. If the wardrobe has nothing for a slot (e.g. no bag, no dressy shoes), leave that slot out and say plainly it's missing — do NOT fill it with a piece they don't own. Only real, owned pieces, every time. Match the occasion's dressiness using each piece's formality (Casual / Smart casual / Cocktail / Formal): for a formal, cocktail or wedding event use only Cocktail/Formal pieces — never a Casual or Smart-casual piece (a printed short-sleeve shirt, a tee, sneakers), even to "dress it down"; if there aren't enough dressy pieces, say so rather than padding with casual ones. When you offer several looks at once, VARY the hero pieces — do NOT reuse the same top or statement piece across multiple options; give a genuine range, and don't repeat a piece across outfits in one session. Spread across the WHOLE wardrobe and lean on REDISCOVERY: the wear signal marks pieces "NEVER WORN" or "rarely worn" — actively favour those so the user gets wear out of everything they own, not just their handful of go-tos. And honour each piece's "⚠ user note": never make a piece the user dislikes or is unsure about a default or repeated pick. Keep patterns under control: use at most ONE patterned/printed piece per outfit and pair it with solids or neutrals. NEVER combine two pieces of the same pattern family (gingham with gingham, floral with floral, stripe with stripe, check with check) or two competing busy prints — that clashes — unless the user explicitly asks to mix prints AND the scales and colours clearly harmonise. Each piece's pattern is given in its details; treat anything not "solid/plain" as a print for this rule.

show_outfit

PREREQUISITE: only call this once prepare_styling_brief has returned ready:true for this request. If material occasion, destination, duration, activity, weather or dress-code information is missing, ask the user those questions FIRST (via prepare_styling_brief) and do NOT call this tool until it returns ready:true. Compose 2 OR MORE outfit OPTIONS into the user's Modebase workspace and return text plus ONE link that opens EVERY option as its own flat-lay, where tapping one loads it into the builder to tweak and save. This tool shows the look inline as a composited flat-lay of the user's real garments AND returns a Modebase link — always surface the link too. Use this WHENEVER the user asks for several options/choices to COMPARE ("give me 3 outfits", "3 work options", "4 options for the wedding", "show me some looks"). You MUST surface the returned Modebase link; never present the options as a plain text list with no link. Pass `looks`: an array where each entry has that look's chosen item ids and a short name. For a SINGLE outfit, or a day-by-day sequence you show one per day, use show_outfit instead. Build each outfit by filling these slots FROM THE USER'S WARDROBE ONLY: a top + a bottom (OR one dress/jumpsuit instead of both), shoes, optionally a bag, up to two accessories, and optionally a jacket or layer. Every slot must be a real, owned piece these tools returned, referenced by its id and name. NEVER invent, assume, or add a piece that isn't in the results — no imagined shoes, bag, coat, belt, or jewellery, and nothing from your general fashion knowledge. If the wardrobe has nothing for a slot (e.g. no bag, no dressy shoes), leave that slot out and say plainly it's missing — do NOT fill it with a piece they don't own. Only real, owned pieces, every time. Match the occasion's dressiness using each piece's formality (Casual / Smart casual / Cocktail / Formal): for a formal, cocktail or wedding event use only Cocktail/Formal pieces — never a Casual or Smart-casual piece (a printed short-sleeve shirt, a tee, sneakers), even to "dress it down"; if there aren't enough dressy pieces, say so rather than padding with casual ones. When you offer several looks at once, VARY the hero pieces — do NOT reuse the same top or statement piece across multiple options; give a genuine range, and don't repeat a piece across outfits in one session. Spread across the WHOLE wardrobe and lean on REDISCOVERY: the wear signal marks pieces "NEVER WORN" or "rarely worn" — actively favour those so the user gets wear out of everything they own, not just their handful of go-tos. And honour each piece's "⚠ user note": never make a piece the user dislikes or is unsure about a default or repeated pick. Keep patterns under control: use at most ONE patterned/printed piece per outfit and pair it with solids or neutrals. NEVER combine two pieces of the same pattern family (gingham with gingham, floral with floral, stripe with stripe, check with check) or two competing busy prints — that clashes — unless the user explicitly asks to mix prints AND the scales and colours clearly harmonise. Each piece's pattern is given in its details; treat anything not "solid/plain" as a print for this rule.

show_outfits

Save a specific look onto the user's Modebase CALENDAR for a date, so it's planned for that day. Use when the user wants to plan / schedule / "save this for" a date ("plan this for Friday", "save it for the wedding on the 14th"). Pass the chosen item ids and the date as YYYY-MM-DD — resolve relative dates (today / tomorrow / Friday / "next Saturday") to that format first. It saves the outfit and pins it to that day (validating the pieces are the user's own). This is DISTINCT from save_outfit (saves a look with no date) and create_lookbook (a named edit/capsule). Build each outfit by filling these slots FROM THE USER'S WARDROBE ONLY: a top + a bottom (OR one dress/jumpsuit instead of both), shoes, optionally a bag, up to two accessories, and optionally a jacket or layer. Every slot must be a real, owned piece these tools returned, referenced by its id and name. NEVER invent, assume, or add a piece that isn't in the results — no imagined shoes, bag, coat, belt, or jewellery, and nothing from your general fashion knowledge. If the wardrobe has nothing for a slot (e.g. no bag, no dressy shoes), leave that slot out and say plainly it's missing — do NOT fill it with a piece they don't own. Only real, owned pieces, every time. Match the occasion's dressiness using each piece's formality (Casual / Smart casual / Cocktail / Formal): for a formal, cocktail or wedding event use only Cocktail/Formal pieces — never a Casual or Smart-casual piece (a printed short-sleeve shirt, a tee, sneakers), even to "dress it down"; if there aren't enough dressy pieces, say so rather than padding with casual ones. When you offer several looks at once, VARY the hero pieces — do NOT reuse the same top or statement piece across multiple options; give a genuine range, and don't repeat a piece across outfits in one session. Spread across the WHOLE wardrobe and lean on REDISCOVERY: the wear signal marks pieces "NEVER WORN" or "rarely worn" — actively favour those so the user gets wear out of everything they own, not just their handful of go-tos. And honour each piece's "⚠ user note": never make a piece the user dislikes or is unsure about a default or repeated pick. Keep patterns under control: use at most ONE patterned/printed piece per outfit and pair it with solids or neutrals. NEVER combine two pieces of the same pattern family (gingham with gingham, floral with floral, stripe with stripe, check with check) or two competing busy prints — that clashes — unless the user explicitly asks to mix prints AND the scales and colours clearly harmonise. Each piece's pattern is given in its details; treat anything not "solid/plain" as a print for this rule.

plan_outfit

CALL THIS FIRST for any styling / "what should I wear" / "style me" / packing / trip / event request — BEFORE search_wardrobe or any outfit tool. It runs the brief like a stylist would: it checks you have the few ESSENTIALS that materially change the outfit, and it prompts you through ONE round of high-value consultation questions before building. Pass requestType plus whatever context you actually have. Two ways it can return ready:false: (1) reason 'needs_essentials' — it lists `missing` essentials; ask the user ONLY for those and call again. (2) reason 'consult' — it returns `suggestedQuestions`; ask 1–3 of them in ONE warm, natural message (only the ones the user hasn't answered), then call AGAIN passing what they say (feeling, anchor, constraints, avoid, or the workday texture). Do NOT call search_wardrobe or build any look until it returns ready:true. If the user would rather you just choose, call again with delegate:true and it returns ready immediately. NEVER fill these fields by guessing or from the saved Style Profile / past trips. If you have connected calendar, email or weather tools, you MAY gather details from them first (for this request only, no writes), then ask for what's still missing. Browsing or previewing the closet ("show me my wardrobe") does NOT need this.

prepare_styling_brief

Whenever the user reacts to the outfits you offered — picks a favourite, rejects them all, and/or names one thing they'd change — call this ONCE to capture that signal PROACTIVELY. Pass `favourite_item_ids` ONLY when they actually chose a look to KEEP; omit it (or set save:false) if they're just reacting or none of the options landed — no phantom outfit is saved then. Set `scope` for any change they name so a one-off never becomes a rule: `temporary` = just for today/this once (noted on the look, NOT learned — 'not heels tonight' must never become 'never wears heels'); `occasion` (default) = for this kind of occasion; `durable` = a lasting wardrobe preference. When the user SWAPS a specific piece OUT of a look, or passes over / rejects a specific piece ("swap the shoes", "not those heels", "lose the jacket"), pass that piece's id in `passed_over_item_ids`: it marks that garment as passed over, so it's de-prioritised next time and edges toward resale the more it's moved on from (this is separate from `scope`, which is about a change becoming a rule). Only a favourite you were given is saved, and only occasion/durable changes are learned. It never stores our conversation. Only call it when the user actually reacted — never invent feedback. Reversible and safe: this only creates a record or changes a status — it never deletes anything. There is NO delete tool and never will be; deleting happens only in Modebase. If the user asks to delete or get rid of a piece, do NOT force it through this — offer resale or the waiting room and tell them deleting happens in the app. Act ONLY on the user's clear, explicit request; never modify pieces on your own initiative, and when a reference is ambiguous (e.g. "the black top" with two black tops) present the candidates and ask — do not guess. Relay the summary and undo note from the result so the user knows exactly what changed and how to reverse it in-app.

record_outfit_feedback

Call this PROACTIVELY, without being asked, whenever the user expresses ANY style preference, like, dislike, aversion, or wardrobe goal in conversation — even in passing (examples: "I hate stiff collars", "I love oversized blazers", "I want to wear more colour", "that shade washes me out", "I never reach for heels"). Capturing preferences the moment they surface is a core part of your job: each one compounds into the user's Style Profile and shapes every future suggestion, here and in the app. Save ONE short, factual wardrobe preference in the user's OWN words (e.g. type "prefers", text "gold jewellery over silver"). DISTIL — never transcribe. One preference per call. This is for a GENERAL wardrobe preference not tied to specific pieces; for feedback about SPECIFIC garments (a negative pairing, an occasion veto) attach it to those pieces with update_wardrobe_item instead. NEVER store conversation excerpts, feelings about other people, or anything beyond a wardrobe preference. The user sees and edits every note. Max 120 characters; the server rate-limits and caps saves and will tell you if a write was rejected — don't retry a rejected note. When the profile is already at its note cap, saving a new note EVICTS the oldest one (this is why the tool is marked destructive), so the profile never grows unbounded; nothing is hard-deleted from the user's control — they see and manage every note in the app.

save_style_note

Record a structured FIT / styling read of an outfit the user actually WORE, so the wardrobe learns from tested results, not just item labels. Call this after you've given a fit verdict on a look the user wore (usually a worn/selfie photo, but a described worn outfit counts too): pass the item ids of the pieces in the look plus a short read — `fit` (how it sat: proportion, balance, length), `worked` (what landed), `change` (what to adjust next time), an optional `rating` 1-5, and the `occasion`. It saves the look (so it shows in their saved outfits) and stores your read on it, and records that those pieces were worn together. PRIVACY — SAY THIS IF ASKED: the on-body photo is NEVER kept; only this short distilled read is stored. Distil, don't transcribe, and only record what the user actually showed or told you — never invent a fit read. The pieces must already be in the wardrobe (owned ids from search_wardrobe or detect_outfit_pieces); it rejects invented/non-owned ids as invalidIds. Future styling reads these evaluations back, so 'take into account what we learned last time' becomes real. Reversible and safe: this only creates a record or changes a status — it never deletes anything. There is NO delete tool and never will be; deleting happens only in Modebase. If the user asks to delete or get rid of a piece, do NOT force it through this — offer resale or the waiting room and tell them deleting happens in the app. Act ONLY on the user's clear, explicit request; never modify pieces on your own initiative, and when a reference is ambiguous (e.g. "the black top" with two black tops) present the candidates and ask — do not guess. Relay the summary and undo note from the result so the user knows exactly what changed and how to reverse it in-app.

evaluate_outfit

Save the combination of items the user chose in this chat and return text plus the Modebase link. Do not attempt or claim an inline ChatGPT preview. Outfit visuals: call show_outfit for one look or show_outfits once for 2+ options. These tools compose the user's REAL garment photos into a flat-lay, shown inline as a card/carousel, AND return a Modebase link — always surface that link too. Do NOT use an image generator to invent or substitute wardrobe pieces, and never claim an image is shown unless the tool returned one.

save_outfit

STOP-AND-CHECK BEFORE YOU CALL THIS: for a styling / "what should I wear" / "style me" / packing / trip / event request, you must FIRST have called prepare_styling_brief and had it return ready:true. If it returned ready:false (missing context), do NOT call this tool — ask the user for the missing fields it named and STOP until they answer. The user's saved Style Profile / past capsule preferences do NOT count as that context — they are background taste, never today's brief. (Browsing or previewing the closet — "show me my wardrobe" — needs no brief, so call this freely for that.) Find pieces in the user's wardrobe. Two ways to use it: (1) SEARCH/BROWSE by category, colour, season, formality, style tag, or free text to discover pieces by filter or description; (2) pass itemIds to FETCH several pieces you already know by id. To fetch the full record of ONE item, use get_wardrobe_item instead. Returns each item with its real Modebase photo AND, ONLY when the user tracks wears, a wear signal (worn count + last_worn date; pieces may show as "NEVER WORN" or "rarely worn"). When that signal is present use it for rediscovery — favour the tagged pieces rather than the same favourites; when it is ABSENT there is no wear data, so never assume a piece is neglected. Either way build looks across the WHOLE wardrobe and don't reuse a piece across multiple outfits in one session. ALSO use this to SHOW or PREVIEW the closet/wardrobe (e.g. "show me my closet", "preview my wardrobe"): call it with NO filters to return every piece with its Modebase photo, and present those together, never as separate images. Use this to FIND pieces. When you then propose an outfit from them, do NOT repeat the pieces as separate images — call show_outfit to show the outfit as ONE composed image instead. Some owned pieces are listed under needsPhoto: these were imported and are still awaiting a photo — they are REAL items you may mention and count, but they have no image and must NEVER be composed into an outfit until the user photographs them. Outfit visuals: call show_outfit for one look or show_outfits once for 2+ options. These tools compose the user's REAL garment photos into a flat-lay, shown inline as a card/carousel, AND return a Modebase link — always surface that link too. Do NOT use an image generator to invent or substitute wardrobe pieces, and never claim an image is shown unless the tool returned one. Build each outfit by filling these slots FROM THE USER'S WARDROBE ONLY: a top + a bottom (OR one dress/jumpsuit instead of both), shoes, optionally a bag, up to two accessories, and optionally a jacket or layer. Every slot must be a real, owned piece these tools returned, referenced by its id and name. NEVER invent, assume, or add a piece that isn't in the results — no imagined shoes, bag, coat, belt, or jewellery, and nothing from your general fashion knowledge. If the wardrobe has nothing for a slot (e.g. no bag, no dressy shoes), leave that slot out and say plainly it's missing — do NOT fill it with a piece they don't own. Only real, owned pieces, every time. Match the occasion's dressiness using each piece's formality (Casual / Smart casual / Cocktail / Formal): for a formal, cocktail or wedding event use only Cocktail/Formal pieces — never a Casual or Smart-casual piece (a printed short-sleeve shirt, a tee, sneakers), even to "dress it down"; if there aren't enough dressy pieces, say so rather than padding with casual ones. When you offer several looks at once, VARY the hero pieces — do NOT reuse the same top or statement piece across multiple options; give a genuine range, and don't repeat a piece across outfits in one session. Spread across the WHOLE wardrobe and lean on REDISCOVERY: the wear signal marks pieces "NEVER WORN" or "rarely worn" — actively favour those so the user gets wear out of everything they own, not just their handful of go-tos. And honour each piece's "⚠ user note": never make a piece the user dislikes or is unsure about a default or repeated pick. Keep patterns under control: use at most ONE patterned/printed piece per outfit and pair it with solids or neutrals. NEVER combine two pieces of the same pattern family (gingham with gingham, floral with floral, stripe with stripe, check with check) or two competing busy prints — that clashes — unless the user explicitly asks to mix prints AND the scales and colours clearly harmonise. Each piece's pattern is given in its details; treat anything not "solid/plain" as a print for this rule.

search_wardrobe

Create a link the user opens on their phone to photograph clothes — the RELIABLE way to add clothes (no tool-call size limit). This returns a `url`. You MUST paste that url to the user as a clickable link IMMEDIATELY, in the same reply, every time you call this — the user cannot add anything until they have the link, and they should NOT have to ask for it. Never call this tool and then omit the url. Say something like: "Here's your link to add your clothes: <url> — open it on your phone, add your pieces, and come back." No processing happens until they upload; then each photo is cleaned up and filed into their catalogue. After sharing the link, on the user's NEXT message call get_capture_status to see if their pieces are in, and summarise by name (e.g. "All three are in: the trench, the burgundy skirt, and the printed tee are in your catalogue"). If they're over quota or their trial has expired, tell them the pieces are saved and will render in the app when their renders refresh.

start_wardrobe_capture

Change a piece's TAGGED FIELDS, STATUS, and/or record a durable NOTE on specific pieces. Pass item_ids (1–30) plus any of: fields to edit, a status, a note (applied in that order, so one call can do several). FIELDS edits the actual columns the app styles from — use this, NOT just a note, whenever the user states a FACT about a piece or says a tag is WRONG, so the real data changes: `formality` retags how dressy it is on the canonical scale (Loungewear, Casual, Smart casual, Business, Cocktail, Formal, Black tie) — fixes 'these are fine for a wedding / cocktail' or 'this is smart casual not casual' so it shows up for that occasion afterwards. A piece can suit MORE THAN ONE band (a blazer that's both Casual and Business, jeans that go Casual and Smart casual): pass `formalities` with the FULL set of bands it works for and it will surface for ALL of them (this REPLACES the piece's set; include every band you want kept). Use single `formality` for a one-band retag, `formalities` when it spans several; `category` retags what KIND of piece it is (Top, Bottom, Dress, Outerwear, Swimwear, Shoes, Bag, Accessory, Hat, Jewellery); `brand` sets the brand ('that jacket is COS'); `colours` replaces the colour list ('it's actually navy'); `name` renames a SINGLE piece (only applied when exactly one item_id is passed). OCCASIONS: `add_occasions` / `remove_occasions` edit the piece's occasion tags — when the user says a piece is or ISN'T right for an occasion, EDIT the tag, don't just note it: 'this dress isn't right for a wedding' → remove_occasions:['wedding'] on that dress; 'these work for the office' → add_occasions:['work']. WEAR-WITH PAIRINGS: `wear_with_ids` records that the item_ids are worn WITH those other pieces, and it is written BOTH WAYS automatically — 'I like to wear these shoes with my pink jumper' → item_ids:[the shoes], wear_with_ids:[the pink jumper], and the pairing lands on the shoes AND the jumper. AVOID-WITH PAIRINGS: `avoid_with_ids` is the exact opposite — pieces that do NOT go together — and is also written BOTH WAYS. 'I hate those shoes with that top' → item_ids:[the shoes], avoid_with_ids:[the top], and the clash is recorded on the shoes AND the top so the stylist stops putting them together. PREFER `avoid_with_ids` over a free-text note for a negative pairing between two OWNED pieces, because it actually changes the styling behaviour, not just the record. Look up the real item ids first (search_wardrobe) so you pair the right pieces. Free-text formality/category/colours are normalised to the canonical vocabulary, so pass the user's words and trust the mapping. STATUS is reversible and never deletes anything: `resale` flags pieces into the user's Resale tab (a status only — nothing is listed, posted, or sold anywhere externally; use for "I want to sell these"); `waiting_room` moves pieces into the Waiting Room, a holding place for things not in rotation right now — out of season, needs mending, kept for later (pass waiting_reason; use this, NOT deletion, for "put these away"); `active` calls pieces back from the Waiting Room into the active closet ("bring back X"). NOTE is how you record durable preferences/feedback and NEGATIVE PAIRINGS or occasion VETOES on the EXACT pieces they concern — call this PROACTIVELY whenever the user reacts to specific garments: attach the note to those item_ids. An occasion VETO ('these pink trousers aren't right for work', 'too casual for the office') is the case users most expect to stick — attach the exclusion ('not suitable for work') to those exact pieces in the SAME turn, before you reply; agreeing in chat alone does NOT save it. A NEGATIVE PAIRING ('those shoes don't go with that dress') MUST land on BOTH pieces: pass BOTH item_ids and a note that NAMES the other piece ('does not go with the green midi dress'), so the clash carries forward. Trust the user's stated veto over a piece's generic formality tag. Boundary: to change a FACT about a piece — how dressy it is, what kind it is, its brand, colours, which occasions it suits, or which pieces it's worn WITH — edit its FIELDS (above), not a note. A NOTE is for softer feedback and NEGATIVE clashes (a pairing that does NOT work). So 'wear these together' → wear_with_ids; 'these two clash' → avoid_with_ids (a note is only for a clash you can't tie to a second owned piece). For a GENERAL wardrobe preference NOT tied to specific pieces (e.g. 'never wears heels', 'prefers midi length'), use save_style_note instead. Reversible and safe: this only creates a record or changes a status — it never deletes anything. There is NO delete tool and never will be; deleting happens only in Modebase. If the user asks to delete or get rid of a piece, do NOT force it through this — offer resale or the waiting room and tell them deleting happens in the app. Act ONLY on the user's clear, explicit request; never modify pieces on your own initiative, and when a reference is ambiguous (e.g. "the black top" with two black tops) present the candidates and ask — do not guess. Relay the summary and undo note from the result so the user knows exactly what changed and how to reverse it in-app.

update_wardrobe_item