[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B687V6ME6HZZKTPPRHBXT":3,"skill-same:01M69B687V6ME6HZZKTPPRHBXT":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M69B687V6ME6HZZKTPPRHBXT","loading-dock-selector",null,"Reason over weather, one current dock snapshot, optional ETA, and verified Drive Priority Pass to select and explain one loading dock.","microsoft\u002Fcopilot-studio-gallery","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69B5GK6Q5V7Q6S3Q3DAKAAB",16,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwandelay-loading-bay-pickup\u002Fsolution\u002Fbotcomponents\u002Fcrf98_curbsidepickupassistant_Q0mRmz.file.skillmd_FPadO\u002Ffiledata\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"loading dock selector","loading","selector","weather","explain","select","snapshot","drive","eta","verified","reason","2026-11-10 10:12:30",false,"---\nname: loading-dock-selector\ndescription: Reason over weather, one current dock snapshot, optional ETA, and verified Drive Priority Pass to select and explain one loading dock.\n---\n\n# Loading Dock Selector and Reasoner\n\nUse this skill after the shipment and pickup facility are verified. Facility\noperating status and hours do not affect whether this skill runs.\n\nThis skill owns the complete dock decision, queue interpretation, ETA comparison,\nsame-session arrival-time calculation, and evidence-based recommendation\nexplanation. Do not reveal private chain-of-thought. Return only evidence\ngrounded in supplied facts.\n\n## Operations\n\nThe calling agent must specify exactly one operation:\n\n- `recommend`: Use after live weather has been attempted and WanDelay Loading Bay Pickup MCP has\n  returned exactly one current dock snapshot. Evaluate all candidates before\n  selecting one.\n- `queue_status`: Use after a recommendation for questions about the queue,\n  readiness, remaining time, a new ETA, or an arrival-time adjustment. Keep the\n  selected dock unchanged and calculate deterministic queue progress from the\n  original `queue_observed_at` at one completed truck every 30 seconds. Do not\n  accept weather or other docks, call `list_bays`, or reselect a dock.\n\nUse `recommend` only for the initial decision or after a no-available-dock\nresult. Once a dock is assigned, it is final for the conversation and must\nnever be discarded, replaced, or reselected. Questions about whether another\ndock is better are explanation requests, not selection requests, and are\nhandled by the calling agent from retained recommendation evidence without\ninvoking this skill. Queue, ETA, and retained-weather follow-ups also keep the\nassigned dock unchanged.\n\n## Inputs\n\nUse only:\n\n- verified shipment reference, consignee name, delivery destination, canonical\n  pickup facility name, and pickup facility timezone\n- optional verified driver first name\n- exact `pass_verified` boolean supplied by the calling agent\n- operation\n- fresh timezone-aware `facility_local_time`\n- either a new optional driver ETA in minutes or the existing absolute\n  `target_local_time`, never both\n- optional `target_adjustment_minutes` only when the driver explicitly says\n  they will arrive earlier or later than the existing target\n- optional exact verified `tier_code`\n- for `recommend` only: available MSN Weather values and exactly one `list_bays`\n  snapshot\n- for `queue_status` only: selected `dock_id`, retained `queue_observed_at`,\n  retained adjusted `initial_trucks_ahead`, optional `previous_queue_update_time` copied\n  from `latest_queue_status.current_local_time`, and no other dock data\n\nTreat a missing or invalid `tier_code` as `standard`. Never infer Drive Priority\nPass from a pass ID, displayed tier, driver statement, shipment, or identity.\nTreat `pass_verified` as authoritative and never infer or change it.\n\nNever retrieve new data or call another tool or agent. For `recommend`, never\ncall `list_bays` again. Shipment and consignee values are output context only; they\nnever influence which dock is selected.\n\n## Canonical same-session state\n\nEvery successful `recommend` or `queue_status` result must include a\n`canonical_state` object containing the complete current state:\n\n- `assigned_dock_id`\n- `queue_observed_at`\n- `initial_trucks_ahead`\n- `target_local_time`, which may be null\n- `latest_queue_status`, which may be null after the initial recommendation\n\nThe complete successful `recommend` result is not a field inside\n`canonical_state`. The calling agent retains it separately as\n`recommendation_evidence`. A later `queue_status` result updates canonical queue\nstate but never replaces `recommendation_evidence`.\n\nInitialize this state only from a successful `recommend` result. Preserve values\nexactly as returned, including identifier type, timestamp, timezone offset,\nnumeric type, and null. Never initialize or update state from driver wording,\nassistant prose, examples, failed calls, partial results, or another\nconversation.\n\nFor the active assignment, `assigned_dock_id`, `queue_observed_at`, and\n`initial_trucks_ahead` are immutable. The successful `recommend` result sets\n`initial_trucks_ahead` to the selected dock's adjusted queue, after any verified\nPriority Pass reduction has been applied exactly once. A successful `queue_status` result may\nreplace only `target_local_time` and `latest_queue_status`. Failed, cancelled,\nmalformed, or permission-denied calls change no state.\n\nFor `queue_status`, copy the three immutable fields from the supplied canonical\nstate. Never replace `queue_observed_at` with the current time, replace\n`initial_trucks_ahead` with another count, apply a Priority Pass reduction\nagain, or infer a missing value. The\ncalling agent must not invoke `queue_status` when required state is missing,\nambiguous, or conflicting. If it is invoked with invalid state despite that\nguard, return `status: state_unavailable` without running Python or fabricating\nstate, with only this `customer_message`:\n`> **⚠️ QUEUE UPDATE UNAVAILABLE**\n>  \n> I can't safely update the pickup queue because the current assignment state is unavailable.\n>  \n> **? Next step:** Start a new shipment pickup request.`\n\nClear all state only for a new conversation or a new shipment. Never clear or\nreplace an active assignment because the driver asks for another, different,\ncloser, faster, or better dock. Treat that wording as a request to explain the\nretained decision. Do not clear state for queue questions, time-left questions,\nETA changes, tool failures, or ordinary follow-ups. `canonical_state` is\ninternal structured output and must never be included in `customer_message`.\n\n## Weather-policy step\n\nRun the bundled `loading_dock_reasoning.py` script before evaluating docks. Python owns\nweather policy, deterministic arrival-time arithmetic, and elapsed queue\narithmetic. Never pass it shipment, pickup facility name, Drive Priority Pass, ETA-derived dock\nassumptions, occupancy, candidate docks, or a selected dock.\n\nFor available or partial weather, pass every available Metric weather value and\nomit unavailable flags:\n\n```bash\npython3 loading_dock_reasoning.py assess \\\n  --weather-available true \\\n  --eta-minutes 20 \\\n  --current-cap \"Cloudy\" \\\n  --temp 30 --feels 33 --visibility 8 \\\n  --wind-dir 45 --wind-speed 25 --wind-gust 50 \\\n  --day-cap \"Rain showers\" --day-precip 70 \\\n  --day-summary \"Periods of rain are expected.\" \\\n  --night-cap \"Mostly clear\" --night-precip 10 \\\n  --night-summary \"Mostly clear overnight.\" \\\n  --now 2026-09-02T18:50:00-05:00 \\\n  --store-timezone America\u002FAnchorage \\\n  --sunrise 2026-09-02T06:20:00-08:00 \\\n  --sunset 2026-09-02T19:20:00-08:00\n```\n\nUse only these weather fields:\n\n- current weather: condition caption, temperature, feels-like temperature,\n  visibility, wind direction, wind speed, and wind gust\n- today's forecast: day condition, precipitation chance, and summary; night\n  condition, precipitation chance, and summary\n- almanac: sunrise and sunset only\n\nDo not pass UV, humidity, pressure, dewpoint, sky code, METAR weather code,\nprovider icons, symbols, daily high or low, moon data, or coordinates.\n\nPython determines `selected_period` from `target_local_time` when an arrival\ntarget exists, otherwise from fresh facility-local current time:\n\n- `day` when `sunrise \u003C= reference time \u003C sunset`\n- `night` otherwise\n- unknown only when the reference time, sunrise, or sunset is unavailable\n\nWhen the period is unknown but forecast values exist, Python retains the\nmore precipitation-exposed day or night forecast instead of discarding both.\n\nSunrise and sunset are internal classification evidence. Never include them in\ndriver text.\n\nPython sets `effective_temperature` to feels-like temperature when available,\notherwise current temperature. Use it for both heat and cold evaluation. In\ndriver text, mention feels-like only when both values exist and differ by at\nleast 3 degrees.\n\nOmit `--eta-minutes` when the driver provides no ETA. When no live weather\nvalue is available, run the same applicable ETA or target-time flags with:\n\n```bash\npython3 loading_dock_reasoning.py assess --weather-available false\n```\n\nFor a retry after no dock was available, preserve the original absolute\narrival target instead of restarting the original relative ETA:\n\n```bash\npython3 loading_dock_reasoning.py assess \\\n  --weather-available true \\\n  --target-local-time 2026-09-02T19:10:00-05:00 \\\n  --now 2026-09-02T19:00:00-05:00 \\\n  --store-timezone America\u002FAnchorage\n```\n\nWhen the driver explicitly changes an existing target by a relative amount,\nalso pass `--target-adjustment-minutes`. A positive value means later and a\nnegative value means earlier. When the driver supplies a completely new ETA,\npass only `--eta-minutes`; it replaces the previous target.\n\nFor a plain `queue_status` request, run:\n\n```bash\npython3 loading_dock_reasoning.py queue \\\n  --queue-observed-at 2026-09-02T19:00:00-05:00 \\\n  --initial-trucks-ahead 3 \\\n  --target-local-time 2026-09-02T19:10:00-05:00 \\\n  --now 2026-09-02T19:00:30-05:00 \\\n  --store-timezone America\u002FChicago\n```\n\nFor a completely new relative ETA, omit `--target-local-time` and run the same\nqueue command with only the replacement ETA:\n\n```bash\npython3 loading_dock_reasoning.py queue \\\n  --queue-observed-at 2026-09-02T19:00:00-05:00 \\\n  --initial-trucks-ahead 3 \\\n  --eta-minutes 30 \\\n  --now 2026-09-02T19:00:30-05:00 \\\n  --store-timezone America\u002FChicago\n```\n\nFor an explicit delay or earlier-arrival adjustment, pass the retained target\nand the adjustment together:\n\n```bash\npython3 loading_dock_reasoning.py queue \\\n  --queue-observed-at 2026-09-02T19:00:00-05:00 \\\n  --initial-trucks-ahead 3 \\\n  --target-local-time 2026-09-02T19:10:00-05:00 \\\n  --target-adjustment-minutes 10 \\\n  --now 2026-09-02T19:00:30-05:00 \\\n  --store-timezone America\u002FChicago\n```\n\nNever pass `--eta-minutes` with `--target-local-time`. Never pass\n`--target-adjustment-minutes` without `--target-local-time`.\n\nThe `queue` command rejects weather and candidate-dock inputs and returns:\n\n```json\n{\n  \"operation\": \"queue_status\",\n  \"current_local_time\": \"2026-09-02T19:00:30-05:00\",\n  \"queue_observed_at\": \"2026-09-02T19:00:00-05:00\",\n  \"queue_seconds_per_truck\": 30,\n  \"initial_trucks_ahead\": 3,\n  \"completed_trucks\": 1,\n  \"trucks_ahead\": 2,\n  \"expected_wait_seconds\": 60,\n  \"estimated_dock_ready_time\": \"2026-09-02T19:01:30-05:00\",\n  \"queue_status\": \"in_progress\",\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_seconds\": 600,\n  \"remaining_eta_minutes\": 10,\n  \"target_status\": \"future\",\n  \"eta_margin_seconds\": 540,\n  \"eta_status\": \"before_arrival\"\n}\n```\n\nFor `queue_status`, start the card with:\n\n```text\n> **? QUEUE UPDATE**\n>  \n```\n\nThen choose exactly one mutually exclusive Status row in this priority order:\n\n- `queue_status: ready`, including an initial queue of zero:\n  `> **✅ Status:** The queue ahead of your assigned dock has cleared.`\n- no completed truck yet and one order remains:\n  `> **⏱️ Status:** There is still one truck ahead. About 30 seconds remains.`\n- no completed truck yet and more than one order remains:\n  `> **⏱️ Status:** There are still [initial_trucks_ahead] trucks ahead. About [formatted expected_wait_seconds] remains.`\n- progress with more than one order remaining:\n  `> **⏱️ Status:** There are now [trucks_ahead] trucks ahead, down from [initial_trucks_ahead]. About [formatted expected_wait_seconds] remains.`\n- progress with one order remaining:\n  `> **⏱️ Status:** There is now one truck ahead, down from [initial_trucks_ahead]. About 30 seconds remains.`\n\nWhen `previous_queue_update_time` is present, add\n`Since your last update at [formatted previous_queue_update_time], ` immediately\nafter the Status label. This timestamp comes only from the retained\n`latest_queue_status.current_local_time`; never infer it from conversation text.\nFor every non-ready result, add\n`> **? Estimated ready:** [formatted estimated_dock_ready_time].` using the\ncanonical raw-string boundary. Use the exact Python field and do not calculate\nthe timestamp in the selector.\n\nWhen a new ETA or adjustment was supplied, add an `> **? Arrival:**` row using\nthe canonical raw-string boundary, followed by one short sentence confirming\nthe updated remaining arrival time. For a plain queue or time-left question,\ndo not state the obvious ETA countdown; report queue progress only. Return\n`status: queue_status`, the retained dock ID, Python queue\u002Ftiming fields,\nthe complete `canonical_state`, and `customer_message`. Set\n`canonical_state.latest_queue_status` to the complete current Python queue result,\nincluding `current_local_time` for use as the next follow-up's remembered update.\nUse Python's `eta_margin_seconds` and `eta_status`; never reconstruct them from\nrounded minutes.\nReturn no weather assessment or new recommendation.\n\nFor `recommend`, preserve Python's driver-safe weather evidence inside\n`weather_assessment`: `assessment_basis`, the recommendation\n`evidence_target_local_time`, `current_conditions`, `selected_forecast`,\n`selected_period`, `active_conditions`, and effective temperature. Keep\nlimitations and unevaluated fields internal.\n\nPython returns:\n\n```json\n{\n  \"weather_available\": true,\n  \"weather_status\": \"complete\",\n  \"assessment_basis\": \"expected_arrival\",\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_seconds\": 1200,\n  \"remaining_eta_minutes\": 20,\n  \"target_status\": \"future\",\n  \"selected_period\": \"day\",\n  \"current_conditions\": {\n    \"condition\": \"Cloudy\",\n    \"temperature\": 30,\n    \"feels_like\": 33,\n    \"visibility\": 8,\n    \"wind_direction\": 45,\n    \"wind_speed\": 25,\n    \"wind_gust\": 50\n  },\n  \"selected_forecast\": {\n    \"condition\": \"Rain showers\",\n    \"precipitation_chance\": 70,\n    \"summary\": \"Periods of rain are expected.\"\n  },\n  \"effective_temperature\": 33,\n  \"temperature_source\": \"feels\",\n  \"primary_band\": \"WET\",\n  \"active_conditions\": [\"WET\", \"WINDY\"],\n  \"preferred_dock_attributes\": {\n    \"covered\": true,\n    \"lit\": null,\n    \"good_drainage\": true,\n    \"high_wind_protection\": true,\n    \"facing_away_from_wind_degrees\": 225.0,\n    \"shorter_distance_to_yard_gate\": true\n  },\n  \"reason_codes\": [\n    \"PRECIPITATION_PROTECTION\",\n    \"WIND_PROTECTION\"\n  ],\n  \"unevaluated_conditions\": []\n}\n```\n\n`primary_band` follows\n`WET > HOT > COLD > WINDY > DARK > LOW_VISIBILITY > BENIGN` for concise\nsummarization only. Never let precedence suppress another active condition or\napplicable dock preference.\n\nFor `weather_status: partial`, use every known active condition and attribute.\nNever treat an unevaluated condition as false and never discard confirmed\nweather facts because another field is missing. A partial assessment with\nconfirmed non-hazardous conditions may still use `primary_band: BENIGN`. For\n`weather_status: unavailable`, apply no weather preference and reason from\navailability and queue only. Missing and unevaluated fields always remain\ninternal.\n\n## Dock reasoning\n\nApply these rules in order:\n\n1. Exclude every dock where `occupied` is true.\n2. If no dock remains, return `status: no_available_dock`. Do not select a dock.\n3. Start with all unoccupied docks as the candidate set.\n4. Process active weather conditions in Python's returned order.\n5. For `WET`, `HOT`, or `COLD`, prefer `covered: true`. Apply the covered filter\n   once even when several of these conditions are active, but preserve every\n   active condition in the explanation.\n6. For `WET`, rank `drainage` as `good > fair > poor` and retain candidates with\n   the best available drainage value.\n7. For `WINDY`, rank `wind_protection` as `high > medium > low` and retain\n   candidates with the best available protection value. Then, when\n   `facing_away_from_wind_degrees` exists, calculate each retained candidate's\n   smallest circular angular difference and retain the closest candidate or tied\n   closest candidates.\n8. For `DARK` or `LOW_VISIBILITY`, prefer `lit: true`.\n9. When any active condition exists, retain candidates with the shortest\n   `distance_to_yard_gate_m` after applying the other weather preferences.\n10. Apply a weather filter only when at least one current candidate has a valid\n   value that satisfies it.\n   If none does, retain the current candidates and record that exact preference\n   in `weather_degradations`.\n11. Never discard all known weather reasoning because one condition is\n   unevaluated. Record each unevaluated condition as a limitation without\n   inventing a result.\n12. After occupancy and weather suitability have produced the retained candidate\n    set, determine the verified Drive Priority Pass tier reduction:\n    - `standard`: 0 trucks\n    - `plus`: 1 truck\n    - `extra`: 3 trucks\n    - `mega`: 5 trucks\n    Use 0 when `pass_verified` is false. Never apply a reduction based only on a\n    supplied or claimed tier.\n13. For each retained candidate where `priority: true`, calculate\n    `adjusted_trucks_ahead = max(0, trucks_ahead - tier_reduction)`, then calculate\n    `adjusted_expected_wait_seconds = adjusted_trucks_ahead *\n    queue_seconds_per_truck` and derive adjusted expected-wait minutes from those\n    seconds. For `priority: false`, keep the dock's original queue values. Do not\n    apply this calculation to occupied docks or candidates removed by weather\n    suitability.\n14. Treat each candidate's adjusted queue as its actual queue for this loading\n    plan. Retain candidates with the lowest resulting `expected_wait_seconds`.\n    Track `queue_narrowed_candidates` from this adjusted-wait comparison.\n15. Drive Priority Pass never overrides occupancy or weather suitability and\n    never makes an occupied or weather-inferior dock eligible.\n16. If candidates remain tied, retain the shortest `distance_to_yard_gate_m`.\n17. If candidates still remain tied, select the lowest `dock_id`.\n\nFor `recommend`, apply the Priority Pass queue calculation exactly once during\nthe initial recommendation. In `selected_dock`, replace `trucks_ahead`,\n`expected_wait_seconds`, and `expected_wait_minutes` with the adjusted values\nused for ranking, while preserving `queue_seconds_per_truck` and\n`queue_observed_at`. Use those same adjusted values for the customer-visible\nqueue and wait, ETA comparison, top-level `initial_trucks_ahead`,\n`canonical_state.initial_trucks_ahead`, retained recommendation evidence, and\nPDF inputs. Preserve the selected dock's pre-adjustment queue and the actual\nreduction in `decision_evidence`. For `queue_status`, pass the retained adjusted\nqueue anchors to Python and use its returned elapsed queue values unchanged;\nnever subtract the Priority Pass reduction again.\n\nTreat `wind_protection`, `drainage`, and `distance_to_yard_gate_m` as comparison\ndata only. Never ask Python to evaluate docks.\n\n## Queue and ETA reasoning\n\nGenerate exact queue wording:\n\n- zero: `There are no trucks ahead.`\n- one: `There is one truck ahead.`\n- more than one: `There are [n] trucks ahead.`\n\nWhen ETA is present, use `remaining_eta_seconds`, not the original relative ETA\nor rounded minutes, for every queue comparison:\n\n- wait seconds less than or equal to ETA seconds: `eta_status: before_arrival`\n- wait seconds greater than ETA seconds: `eta_status: may_extend_beyond_arrival`\n\nWhen ETA is absent, return `eta_status: not_provided` and never invent an arrival\ntime, clock time, or availability time. When `target_status` is `due_or_passed`,\nuse zero as the remaining ETA and state that any positive wait may extend beyond\nthe expected arrival.\n\n## Decision explanation\n\nThe explanation must be composed from the actual decision evidence. It must not\nbe a fixed sentence.\n\nInclude:\n\n- why the selected dock remained available\n- every active weather condition that affected its preferred attributes\n- every weather preference that could not be satisfied\n- how drainage, wind protection, lighting, or yard-gate distance affected the\n  comparison when applicable\n- why it won the adjusted queue comparison\n- the complete verified Drive Priority Pass outcome and normalized display\n  grade, and whether lowest dock ID resolved a final tie\n\nKeep pass and weather claims in `recommendation_reason` consistent with\n`decision_evidence`. Never expose the pass ID, raw `tier_code`, unevaluated\nconditions, or missing weather fields in `recommendation_reason`. For every\nverified pass outcome, show the normalized display grade exactly as `Standard`,\n`Plus`, `Extra`, or `Mega` in the required Priority Pass row. If no pass is\nverified, do not invent `Standard`.\n\n## Driver message\n\nFor `recommend`, compose one complete `customer_message` for the calling agent\nto present unchanged. It is the only driver-facing recommendation text.\nStructured fields support orchestration, retained evidence, diagnostics, and\nPDF rendering; never restate them outside `customer_message`.\n\nEvery `customer_message` returned by this skill, including `recommend`,\n`queue_status`, `no_available_dock`, and `state_unavailable`, must be exactly\none Markdown blockquote card with no text before or after it, built as one raw\nmessage string. Start every content row with `> `. For every multi-row card,\nplace the exact literal sequence `\\n>  \\n` between every adjacent content\nrow so that each `>` begins its own physical line. Never use a line containing\nonly `>`, a bare newline, or any alternative spacing method between content\nrows. Single-row cards need no spacer. All later references to adding a row or\nspacer use only this canonical rule. Keep the current simple visual hierarchy:\nbold card title and row labels, and no bullets, tables, horizontal dividers,\nnested cards, or additional decorative spacer rows. The raw-string pattern is:\n\n```text\n> [first content row]\n>  \n> [second content row]\n```\n\nReturn a `weather_icon` selected only from confirmed weather evidence:\n\n- `WET`: `?️`\n- `HOT`: `?️`\n- `COLD`: `❄️`\n- `WINDY`: `?`\n- `DARK`: `?`\n- `LOW_VISIBILITY`: `?️`\n- `BENIGN` with a confirmed current or selected-forecast condition: `?️`\n- no confirmed current or selected-forecast condition: an empty string\n\nWhen several conditions are active, use the icon for `primary_band`; describe\nevery confirmed condition that affected selection in the prose.\n\nReturn two free-text fields composed only after deterministic comparison:\n\n- `weather_summary`: a concise natural summary using every useful confirmed\n  fact that is relevant to the expected pickup. Lead with useful current\n  conditions. Include selected-forecast facts only when they materially affect\n  dock selection, driver guidance, or conditions expected around the retained\n  arrival target. When included, connect them explicitly to the pickup with\n  wording such as `Around your expected arrival`; do not append a general daily\n  or overnight weather report. Include actual temperature, feels-like only when\n  it differs by at least 3 degrees, visibility when relevant, and current wind.\n  For `HOT`, use natural wording such as `Hot conditions are expected around\n  your arrival, feeling like [X]°C` when feels-like is available, otherwise\n  `Hot conditions are expected around your arrival, with a temperature around\n  [X]°C`. Always include `°C`. Never say `humid high near`, `high near`, or use\n  a forecast high as though it were the retained feels-like value. Do not\n  produce a raw field list or repeat equivalent facts.\n- `driver_guidance`: concise practical guidance grounded in the selected\n  dock's cover, drainage, wind protection, facing, lighting, and yard-gate\n  distance. Mention only attributes that are relevant to confirmed conditions.\n  Do not state the dock number in this field.\n\nFree text never changes the selected dock. Never enumerate unavailable\nreadings, unevaluated conditions, omitted field names, API behavior, or internal\nlimitations. When no confirmed weather evidence exists, use only the defined\nWeather-block fallback.\n\nUse `available` only for an unoccupied dock. Use `covered` and `uncovered` only\nfor overhead weather protection. Never use `open` as a synonym for either\navailable or uncovered.\n\nTrack `weather_narrowed_candidates` as true only when an applied weather filter\nreduced the candidate count. Track `queue_narrowed_candidates` as true only when\nthe adjusted shortest-wait step reduced the candidate count. Return\n`priority_pass_queue_benefit_applied` as true only when the selected dock is\npriority-enabled and its adjusted queue is lower than its pre-adjustment queue.\nAlso return the selected dock's pre-adjustment trucks ahead, adjusted trucks\nahead, and actual reduction count. A tier allowance larger than the available\nqueue reduces only to zero and records only the positions actually removed.\n\nReturn one deterministic `decision_driver` using this precedence:\n\n1. `priority_pass_queue_benefit` when a nonzero verified Priority Pass queue\n   reduction was applied to the selected dock.\n2. `lowest_dock_id_tie_break` when the lowest dock ID resolved the final tie.\n3. `weather_and_queue` when both narrowing flags are true.\n4. `weather` when only `weather_narrowed_candidates` is true.\n5. `queue` when only `queue_narrowed_candidates` is true, including when a\n   retained weather preference matched every candidate and therefore did not\n   narrow the set.\n6. `distance_tie_break` when yard-gate distance was the final candidate-reducing\n   step.\n7. `availability` when occupancy left only one candidate before weather and\n   queue reasoning, so neither narrowing flag is true.\n\nWhen ETA is present, return signed `eta_margin_seconds` as\n`remaining_eta_seconds` minus `expected_wait_seconds`. A positive value is the\nremaining buffer, zero matches the expected arrival, and a negative value is\nseconds beyond it. When ETA is absent, return `eta_margin_seconds: null`.\n\nCompose the initial recommendation card in this content order: plan and\nfacility, weather, queue, optional ETA, dock planning and assigned dock, why,\nthen Priority Pass. Use the canonical raw-string boundary between adjacent\ncontent rows. Natural wording is allowed inside each required initial-plan row.\n\n1. Start with a grouped title-and-facility row identifying the loading-dock\n   plan and canonical pickup facility.\n2. Weather row: when `weather_icon` is nonempty, identify the row as Weather\n   and address the driver by verified first name\n   when available, followed by `weather_summary`. When no confirmed weather\n   evidence is available, use exactly\n   `> **?️ Weather:** Current weather details are unavailable, so the assignment uses the available dock and queue evidence.`\n   Missing optional weather evidence never suppresses a recommendation.\n3. Queue row: identify the row as Queue. State trucks ahead and\n   expected wait, then give only the supported comparison fact, such as the\n   retained wait range or whether this is the unique shortest wait. When weather\n   affected suitability, identify the relevant group only as the suitable\n   available docks. Reserve all explanation of why the dock was assigned for\n   the Assignment block. Do not use phrases such as `narrowed the comparison`\n   or `resolved the selection`. Do not state the dock number or repeat queue\n   values elsewhere.\n4. When ETA exists, add an ETA row. State the\n   arrival estimate and use `eta_margin_seconds` to explain the exact buffer,\n   match, or overrun. Format minutes and seconds naturally. Do not repeat the\n   wait value. Omit the row when ETA is absent.\n5. Add a dock-planning and assigned-dock row. This is the only\n   place before the Why row that may state the dock number and begins the final\n   section. Every successful recommendation must finish with a plain-English\n   explanation of why this dock was assigned.\n6. Add a Why row with concise natural prose.\n     Explain the observed condition, why it matters operationally, the dock\n     feature that addresses it, and the final fact that made this dock the best\n     fit. Say, for example, that hot conditions make shade useful or that rain\n     makes cover and drainage useful. Never use internal comparison language\n     such as `narrowed the comparison`, `resolved the selection`,\n     `candidate-reducing`, or `tie-resolving` in driver-facing text. Mention\n     queue causality only when `queue_narrowed_candidates` is true or the final\n     `decision_driver` is queue-based. When `decision_driver` is\n     `priority_pass_queue_benefit`, explain the actual before-and-after queue\n     benefit. Mention lowest dock ID only when it\n     resolved the final tie. Use `uncovered docks`, never `open docks`, as the\n     opposite of covered docks.\n   - When a relevant non-decisive benefit remains, add it naturally\n     in the Why prose. Every included benefit must state why it helps under a\n     confirmed active condition and must not repeat a cause already explained\n     in Why. Never list attributes by themselves.\n   Apply these condition-to-benefit rules:\n   - For `HOT`, cover matters because it provides shade and reduces heat\n     exposure.\n   - For `COLD`, cover matters because it provides shelter and reduces cold\n     exposure.\n   - For `WET`, cover helps keep loading dry and good drainage helps reduce\n     standing water.\n   - For `WINDY`, wind protection and a suitable facing help reduce wind\n     exposure around the truck and loading area.\n   - For `DARK` or `LOW_VISIBILITY`, lighting helps the driver see the dock and\n     approach more clearly.\n   - A shorter yard-gate route may be mentioned only when it decided the\n     assignment or when its reduced exposure to a confirmed active condition is\n     explained.\n   Omit drainage without `WET`; wind protection without `WINDY`; lighting\n   without `DARK` or `LOW_VISIBILITY`; and shade or heat protection without\n   `HOT`. Do not repeat queue or ETA values. Describe an unoccupied dock as\n   `available`, never `open`.\n7. Finish the card with exactly one Priority Pass outcome selected from these\n   mutually exclusive outcomes, using exactly one supported reason:\n   - Not verified:\n     `> ? **Priority Pass:** Not verified for this assignment.`\n   - A nonzero verified reduction was applied:\n     `> ? **Priority Pass ([Grade]):** Applied. Your queue was reduced by [reduction] position[s], from [before] truck[s] ahead to [after] truck[s] ahead.`\n   - Verified `Standard`:\n     `> ? **Priority Pass (Standard):** Verified. Standard provides no queue reduction.`\n   - Verified `Plus`, `Extra`, or `Mega` with a selected non-priority dock:\n     `> ? **Priority Pass ([Grade]):** Verified, but no queue reduction was applied because Dock [dock_id] is not priority-enabled.`\n   - A selected priority-enabled dock already had zero trucks ahead:\n     `> ? **Priority Pass ([Grade]):** Verified, but no queue reduction was needed because there were no trucks ahead.`\n   Use natural singular\u002Fplural grammar for `position[s]` and `truck[s]`. The\n   applied explanation may state that the adjusted queue helped selection. Do\n   not use equal-wait language. Use only the existing verified grade, selected\n   dock priority flag, pre-adjustment queue, adjusted queue, and actual\n   reduction; add no conditions or calculations. Never expose the pass ID or\n   raw `tier_code`. Follow-ups must reuse the retained pass outcome and grade\n   without recalculating either.\n\nReturn no preface, progress update, tool narration, duplicate summary,\ndisclaimer, closing sentence, text outside the card, or PDF offer. Never expose raw field names,\nfacility operating status, operating hours, local store time, missing readings,\nunevaluated conditions, or internal limitations. Before returning, ensure the\nmessage follows the canonical raw-line boundary rule, preserves the required\ninitial recommendation content order, states the dock number only in the\ndock-planning row and Why prose, and ends with the single Priority Pass outcome.\nThese formatting checks must never suppress an otherwise successful\nrecommendation.\n\n## Output\n\nReturn this structure:\n\n```json\n{\n  \"status\": \"recommended\",\n  \"shipment_reference\": \"ORD-10502\",\n  \"consignee_name\": \"Caribbean Market Logistics\",\n  \"delivery_destination\": \"Caribbean Market Tampa Hub, 6705 East Adamo Drive, Tampa, FL 33619\",\n  \"pickup_facility_name\": \"WanDelay Miami Distribution Center\",\n  \"selected_dock\": {\n    \"dock_id\": 2,\n    \"priority\": true,\n    \"covered\": true,\n    \"lit\": true,\n    \"facing\": 180,\n    \"wind_protection\": \"high\",\n    \"drainage\": \"good\",\n    \"distance_to_yard_gate_m\": 20,\n    \"trucks_ahead\": 2,\n    \"queue_seconds_per_truck\": 30,\n    \"expected_wait_seconds\": 60,\n    \"expected_wait_minutes\": 1.0\n  },\n  \"weather_assessment\": {\n    \"weather_status\": \"complete\",\n    \"assessment_basis\": \"expected_arrival\",\n    \"evidence_target_local_time\": \"2026-09-02T19:10:00-05:00\",\n    \"primary_band\": \"WET\",\n    \"selected_period\": \"day\",\n    \"effective_temperature\": 33,\n    \"current_conditions\": {\n      \"condition\": \"Cloudy\",\n      \"temperature\": 30,\n      \"feels_like\": 33,\n      \"visibility\": 8,\n      \"wind_direction\": 45,\n      \"wind_speed\": 25,\n      \"wind_gust\": 50\n    },\n    \"selected_forecast\": {\n      \"condition\": \"Rain showers\",\n      \"precipitation_chance\": 70,\n      \"summary\": \"Periods of rain are expected.\"\n    },\n    \"active_conditions\": [\"WET\", \"WINDY\"],\n    \"reason_codes\": [\n      \"PRECIPITATION_PROTECTION\",\n      \"WIND_PROTECTION\"\n    ],\n    \"unevaluated_conditions\": []\n  },\n  \"decision_evidence\": {\n    \"weather_matches\": [\n      \"Covered for expected precipitation\",\n      \"Good drainage for expected precipitation\",\n      \"High wind protection and closest available facing for strong wind\",\n      \"Shortest weather-exposed yard route among the suitable docks\"\n    ],\n    \"weather_degradations\": [],\n    \"weather_limitations\": [],\n    \"queue_comparison\": \"Adjusted current wait for the dock meeting the retained weather preferences\",\n    \"weather_narrowed_candidates\": true,\n    \"queue_narrowed_candidates\": false,\n    \"priority_pass_queue_benefit_applied\": true,\n    \"priority_pass_original_trucks_ahead\": 5,\n    \"priority_pass_adjusted_trucks_ahead\": 2,\n    \"priority_pass_queue_reduction\": 3,\n    \"lowest_dock_id_resolved_tie\": false\n  },\n  \"weather_icon\": \"?️\",\n  \"decision_driver\": \"priority_pass_queue_benefit\",\n  \"queue_observed_at\": \"2026-09-02T18:50:00-05:00\",\n  \"initial_trucks_ahead\": 2,\n  \"canonical_state\": {\n    \"assigned_dock_id\": 2,\n    \"queue_observed_at\": \"2026-09-02T18:50:00-05:00\",\n    \"initial_trucks_ahead\": 2,\n    \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n    \"latest_queue_status\": null\n  },\n  \"eta_margin_seconds\": 1140,\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_seconds\": 1200,\n  \"remaining_eta_minutes\": 20,\n  \"target_status\": \"future\",\n  \"weather_summary\": \"It is currently cloudy and 30°, feeling like 33°, with winds of 25 km\u002Fh and gusts up to 50 km\u002Fh. The daytime forecast calls for rain showers with a 70% chance of precipitation.\",\n  \"driver_guidance\": \"Covered loading and good drainage help keep the loading area dry, while high wind protection and a suitable facing reduce wind exposure around the truck.\",\n  \"customer_message\": \"> **? LOADING-DOCK PLAN** · **? Facility:** WanDelay Miami Distribution Center\\n>  \\n> ?️ **Weather:** Jordan, it is currently cloudy and 30°, feeling like 33°, with winds of 25 km\u002Fh and gusts up to 50 km\u002Fh. Around your expected arrival, rain showers are forecast with a 70% chance of precipitation.\\n>  \\n> ? **Queue:** There are two trucks ahead, with an expected wait of one minute, at the suitable available dock with the current wait shown in this plan.\\n>  \\n> ⏱️ **ETA:** You expect to arrive in 20 minutes. That leaves a 19-minute buffer before your expected arrival.\\n>  \\n> **? DOCK PLANNING** · **Assigned Dock is 2**\\n>  \\n> ? **Why:** Rain is expected near your arrival, so a covered dock with good drainage helps keep loading dry and reduces standing water. Strong winds also make wind protection important around the truck and loading area. Dock 2 was assigned because its facing provides the best available protection from the current wind. Its shorter yard-gate route reduces the time you may spend exposed to the rain. Your verified Priority Pass also reduced the queue used for this plan from five trucks ahead to two.\\n>  \\n> ? **Priority Pass (Extra):** Applied. Your queue was reduced by 3 positions, from 5 trucks ahead to 2 trucks ahead.\",\n  \"eta_status\": \"before_arrival\",\n  \"recommendation_reason\": \"Rain makes covered loading and good drainage useful for keeping the loading area dry, while strong winds make wind protection important. The assigned dock has the best available facing away from the current wind, and the verified Priority Pass reduced its queue from five trucks ahead to two.\"\n}\n```\n\nFor no available dock, return:\n\n```json\n{\n  \"status\": \"no_available_dock\",\n  \"selected_dock\": null,\n  \"canonical_state\": {\n    \"assigned_dock_id\": null,\n    \"queue_observed_at\": null,\n    \"initial_trucks_ahead\": null,\n    \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n    \"latest_queue_status\": null\n  },\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_minutes\": 20,\n  \"target_status\": \"future\",\n  \"weather_icon\": \"\",\n  \"decision_driver\": null,\n  \"eta_margin_seconds\": null,\n  \"customer_message\": \"> **⛔ NO LOADING DOCK AVAILABLE**\\n>  \\n> No loading dock is currently available.\\n>  \\n> **? Next step:** Please try again shortly.\",\n  \"recommendation_reason\": \"No loading dock is currently available.\"\n}\n```\n\nReturn the timing fields even when no dock is available so the calling agent can\nretain an arrival target created or adjusted during that decision run. Use null\ntiming values when the driver has no ETA.\n\nFor invalid or unavailable canonical state, return:\n\n```json\n{\n  \"status\": \"state_unavailable\",\n  \"customer_message\": \"> **⚠️ QUEUE UPDATE UNAVAILABLE**\\n>  \\n> I can't safely update the pickup queue because the current assignment state is unavailable.\\n>  \\n> **? Next step:** Start a new shipment pickup request.\"\n}\n```\n\nNever return or expose a Drive Priority Pass ID, raw `tier_code`, `occupied_by`,\nother driver details, cargo, raw tool output, or private reasoning. For every\nverified pass outcome, the required Priority Pass row shows exactly one\nnormalized grade: `Standard`, `Plus`, `Extra`, or `Mega`. If no pass is\nverified, use `Not verified for this assignment` and do not invent a grade.\n","# Loading Dock Selector and Reasoner\n\nUse this skill after the shipment and pickup facility are verified. Facility\noperating status and hours do not affect whether this skill runs.\n\nThis skill owns the complete dock decision, queue interpretation, ETA comparison,\nsame-session arrival-time calculation, and evidence-based recommendation\nexplanation. Do not reveal private chain-of-thought. Return only evidence\ngrounded in supplied facts.\n\n## Operations\n\nThe calling agent must specify exactly one operation:\n\n- `recommend`: Use after live weather has been attempted and WanDelay Loading Bay Pickup MCP has\n  returned exactly one current dock snapshot. Evaluate all candidates before\n  selecting one.\n- `queue_status`: Use after a recommendation for questions about the queue,\n  readiness, remaining time, a new ETA, or an arrival-time adjustment. Keep the\n  selected dock unchanged and calculate deterministic queue progress from the\n  original `queue_observed_at` at one completed truck every 30 seconds. Do not\n  accept weather or other docks, call `list_bays`, or reselect a dock.\n\nUse `recommend` only for the initial decision or after a no-available-dock\nresult. Once a dock is assigned, it is final for the conversation and must\nnever be discarded, replaced, or reselected. Questions about whether another\ndock is better are explanation requests, not selection requests, and are\nhandled by the calling agent from retained recommendation evidence without\ninvoking this skill. Queue, ETA, and retained-weather follow-ups also keep the\nassigned dock unchanged.\n\n## Inputs\n\nUse only:\n\n- verified shipment reference, consignee name, delivery destination, canonical\n  pickup facility name, and pickup facility timezone\n- optional verified driver first name\n- exact `pass_verified` boolean supplied by the calling agent\n- operation\n- fresh timezone-aware `facility_local_time`\n- either a new optional driver ETA in minutes or the existing absolute\n  `target_local_time`, never both\n- optional `target_adjustment_minutes` only when the driver explicitly says\n  they will arrive earlier or later than the existing target\n- optional exact verified `tier_code`\n- for `recommend` only: available MSN Weather values and exactly one `list_bays`\n  snapshot\n- for `queue_status` only: selected `dock_id`, retained `queue_observed_at`,\n  retained adjusted `initial_trucks_ahead`, optional `previous_queue_update_time` copied\n  from `latest_queue_status.current_local_time`, and no other dock data\n\nTreat a missing or invalid `tier_code` as `standard`. Never infer Drive Priority\nPass from a pass ID, displayed tier, driver statement, shipment, or identity.\nTreat `pass_verified` as authoritative and never infer or change it.\n\nNever retrieve new data or call another tool or agent. For `recommend`, never\ncall `list_bays` again. Shipment and consignee values are output context only; they\nnever influence which dock is selected.\n\n## Canonical same-session state\n\nEvery successful `recommend` or `queue_status` result must include a\n`canonical_state` object containing the complete current state:\n\n- `assigned_dock_id`\n- `queue_observed_at`\n- `initial_trucks_ahead`\n- `target_local_time`, which may be null\n- `latest_queue_status`, which may be null after the initial recommendation\n\nThe complete successful `recommend` result is not a field inside\n`canonical_state`. The calling agent retains it separately as\n`recommendation_evidence`. A later `queue_status` result updates canonical queue\nstate but never replaces `recommendation_evidence`.\n\nInitialize this state only from a successful `recommend` result. Preserve values\nexactly as returned, including identifier type, timestamp, timezone offset,\nnumeric type, and null. Never initialize or update state from driver wording,\nassistant prose, examples, failed calls, partial results, or another\nconversation.\n\nFor the active assignment, `assigned_dock_id`, `queue_observed_at`, and\n`initial_trucks_ahead` are immutable. The successful `recommend` result sets\n`initial_trucks_ahead` to the selected dock's adjusted queue, after any verified\nPriority Pass reduction has been applied exactly once. A successful `queue_status` result may\nreplace only `target_local_time` and `latest_queue_status`. Failed, cancelled,\nmalformed, or permission-denied calls change no state.\n\nFor `queue_status`, copy the three immutable fields from the supplied canonical\nstate. Never replace `queue_observed_at` with the current time, replace\n`initial_trucks_ahead` with another count, apply a Priority Pass reduction\nagain, or infer a missing value. The\ncalling agent must not invoke `queue_status` when required state is missing,\nambiguous, or conflicting. If it is invoked with invalid state despite that\nguard, return `status: state_unavailable` without running Python or fabricating\nstate, with only this `customer_message`:\n`> **⚠️ QUEUE UPDATE UNAVAILABLE**\n>  \n> I can't safely update the pickup queue because the current assignment state is unavailable.\n>  \n> **? Next step:** Start a new shipment pickup request.`\n\nClear all state only for a new conversation or a new shipment. Never clear or\nreplace an active assignment because the driver asks for another, different,\ncloser, faster, or better dock. Treat that wording as a request to explain the\nretained decision. Do not clear state for queue questions, time-left questions,\nETA changes, tool failures, or ordinary follow-ups. `canonical_state` is\ninternal structured output and must never be included in `customer_message`.\n\n## Weather-policy step\n\nRun the bundled `loading_dock_reasoning.py` script before evaluating docks. Python owns\nweather policy, deterministic arrival-time arithmetic, and elapsed queue\narithmetic. Never pass it shipment, pickup facility name, Drive Priority Pass, ETA-derived dock\nassumptions, occupancy, candidate docks, or a selected dock.\n\nFor available or partial weather, pass every available Metric weather value and\nomit unavailable flags:\n\n```bash\npython3 loading_dock_reasoning.py assess \\\n  --weather-available true \\\n  --eta-minutes 20 \\\n  --current-cap \"Cloudy\" \\\n  --temp 30 --feels 33 --visibility 8 \\\n  --wind-dir 45 --wind-speed 25 --wind-gust 50 \\\n  --day-cap \"Rain showers\" --day-precip 70 \\\n  --day-summary \"Periods of rain are expected.\" \\\n  --night-cap \"Mostly clear\" --night-precip 10 \\\n  --night-summary \"Mostly clear overnight.\" \\\n  --now 2026-09-02T18:50:00-05:00 \\\n  --store-timezone America\u002FAnchorage \\\n  --sunrise 2026-09-02T06:20:00-08:00 \\\n  --sunset 2026-09-02T19:20:00-08:00\n```\n\nUse only these weather fields:\n\n- current weather: condition caption, temperature, feels-like temperature,\n  visibility, wind direction, wind speed, and wind gust\n- today's forecast: day condition, precipitation chance, and summary; night\n  condition, precipitation chance, and summary\n- almanac: sunrise and sunset only\n\nDo not pass UV, humidity, pressure, dewpoint, sky code, METAR weather code,\nprovider icons, symbols, daily high or low, moon data, or coordinates.\n\nPython determines `selected_period` from `target_local_time` when an arrival\ntarget exists, otherwise from fresh facility-local current time:\n\n- `day` when `sunrise \u003C= reference time \u003C sunset`\n- `night` otherwise\n- unknown only when the reference time, sunrise, or sunset is unavailable\n\nWhen the period is unknown but forecast values exist, Python retains the\nmore precipitation-exposed day or night forecast instead of discarding both.\n\nSunrise and sunset are internal classification evidence. Never include them in\ndriver text.\n\nPython sets `effective_temperature` to feels-like temperature when available,\notherwise current temperature. Use it for both heat and cold evaluation. In\ndriver text, mention feels-like only when both values exist and differ by at\nleast 3 degrees.\n\nOmit `--eta-minutes` when the driver provides no ETA. When no live weather\nvalue is available, run the same applicable ETA or target-time flags with:\n\n```bash\npython3 loading_dock_reasoning.py assess --weather-available false\n```\n\nFor a retry after no dock was available, preserve the original absolute\narrival target instead of restarting the original relative ETA:\n\n```bash\npython3 loading_dock_reasoning.py assess \\\n  --weather-available true \\\n  --target-local-time 2026-09-02T19:10:00-05:00 \\\n  --now 2026-09-02T19:00:00-05:00 \\\n  --store-timezone America\u002FAnchorage\n```\n\nWhen the driver explicitly changes an existing target by a relative amount,\nalso pass `--target-adjustment-minutes`. A positive value means later and a\nnegative value means earlier. When the driver supplies a completely new ETA,\npass only `--eta-minutes`; it replaces the previous target.\n\nFor a plain `queue_status` request, run:\n\n```bash\npython3 loading_dock_reasoning.py queue \\\n  --queue-observed-at 2026-09-02T19:00:00-05:00 \\\n  --initial-trucks-ahead 3 \\\n  --target-local-time 2026-09-02T19:10:00-05:00 \\\n  --now 2026-09-02T19:00:30-05:00 \\\n  --store-timezone America\u002FChicago\n```\n\nFor a completely new relative ETA, omit `--target-local-time` and run the same\nqueue command with only the replacement ETA:\n\n```bash\npython3 loading_dock_reasoning.py queue \\\n  --queue-observed-at 2026-09-02T19:00:00-05:00 \\\n  --initial-trucks-ahead 3 \\\n  --eta-minutes 30 \\\n  --now 2026-09-02T19:00:30-05:00 \\\n  --store-timezone America\u002FChicago\n```\n\nFor an explicit delay or earlier-arrival adjustment, pass the retained target\nand the adjustment together:\n\n```bash\npython3 loading_dock_reasoning.py queue \\\n  --queue-observed-at 2026-09-02T19:00:00-05:00 \\\n  --initial-trucks-ahead 3 \\\n  --target-local-time 2026-09-02T19:10:00-05:00 \\\n  --target-adjustment-minutes 10 \\\n  --now 2026-09-02T19:00:30-05:00 \\\n  --store-timezone America\u002FChicago\n```\n\nNever pass `--eta-minutes` with `--target-local-time`. Never pass\n`--target-adjustment-minutes` without `--target-local-time`.\n\nThe `queue` command rejects weather and candidate-dock inputs and returns:\n\n```json\n{\n  \"operation\": \"queue_status\",\n  \"current_local_time\": \"2026-09-02T19:00:30-05:00\",\n  \"queue_observed_at\": \"2026-09-02T19:00:00-05:00\",\n  \"queue_seconds_per_truck\": 30,\n  \"initial_trucks_ahead\": 3,\n  \"completed_trucks\": 1,\n  \"trucks_ahead\": 2,\n  \"expected_wait_seconds\": 60,\n  \"estimated_dock_ready_time\": \"2026-09-02T19:01:30-05:00\",\n  \"queue_status\": \"in_progress\",\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_seconds\": 600,\n  \"remaining_eta_minutes\": 10,\n  \"target_status\": \"future\",\n  \"eta_margin_seconds\": 540,\n  \"eta_status\": \"before_arrival\"\n}\n```\n\nFor `queue_status`, start the card with:\n\n```text\n> **? QUEUE UPDATE**\n>  \n```\n\nThen choose exactly one mutually exclusive Status row in this priority order:\n\n- `queue_status: ready`, including an initial queue of zero:\n  `> **✅ Status:** The queue ahead of your assigned dock has cleared.`\n- no completed truck yet and one order remains:\n  `> **⏱️ Status:** There is still one truck ahead. About 30 seconds remains.`\n- no completed truck yet and more than one order remains:\n  `> **⏱️ Status:** There are still [initial_trucks_ahead] trucks ahead. About [formatted expected_wait_seconds] remains.`\n- progress with more than one order remaining:\n  `> **⏱️ Status:** There are now [trucks_ahead] trucks ahead, down from [initial_trucks_ahead]. About [formatted expected_wait_seconds] remains.`\n- progress with one order remaining:\n  `> **⏱️ Status:** There is now one truck ahead, down from [initial_trucks_ahead]. About 30 seconds remains.`\n\nWhen `previous_queue_update_time` is present, add\n`Since your last update at [formatted previous_queue_update_time], ` immediately\nafter the Status label. This timestamp comes only from the retained\n`latest_queue_status.current_local_time`; never infer it from conversation text.\nFor every non-ready result, add\n`> **? Estimated ready:** [formatted estimated_dock_ready_time].` using the\ncanonical raw-string boundary. Use the exact Python field and do not calculate\nthe timestamp in the selector.\n\nWhen a new ETA or adjustment was supplied, add an `> **? Arrival:**` row using\nthe canonical raw-string boundary, followed by one short sentence confirming\nthe updated remaining arrival time. For a plain queue or time-left question,\ndo not state the obvious ETA countdown; report queue progress only. Return\n`status: queue_status`, the retained dock ID, Python queue\u002Ftiming fields,\nthe complete `canonical_state`, and `customer_message`. Set\n`canonical_state.latest_queue_status` to the complete current Python queue result,\nincluding `current_local_time` for use as the next follow-up's remembered update.\nUse Python's `eta_margin_seconds` and `eta_status`; never reconstruct them from\nrounded minutes.\nReturn no weather assessment or new recommendation.\n\nFor `recommend`, preserve Python's driver-safe weather evidence inside\n`weather_assessment`: `assessment_basis`, the recommendation\n`evidence_target_local_time`, `current_conditions`, `selected_forecast`,\n`selected_period`, `active_conditions`, and effective temperature. Keep\nlimitations and unevaluated fields internal.\n\nPython returns:\n\n```json\n{\n  \"weather_available\": true,\n  \"weather_status\": \"complete\",\n  \"assessment_basis\": \"expected_arrival\",\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_seconds\": 1200,\n  \"remaining_eta_minutes\": 20,\n  \"target_status\": \"future\",\n  \"selected_period\": \"day\",\n  \"current_conditions\": {\n    \"condition\": \"Cloudy\",\n    \"temperature\": 30,\n    \"feels_like\": 33,\n    \"visibility\": 8,\n    \"wind_direction\": 45,\n    \"wind_speed\": 25,\n    \"wind_gust\": 50\n  },\n  \"selected_forecast\": {\n    \"condition\": \"Rain showers\",\n    \"precipitation_chance\": 70,\n    \"summary\": \"Periods of rain are expected.\"\n  },\n  \"effective_temperature\": 33,\n  \"temperature_source\": \"feels\",\n  \"primary_band\": \"WET\",\n  \"active_conditions\": [\"WET\", \"WINDY\"],\n  \"preferred_dock_attributes\": {\n    \"covered\": true,\n    \"lit\": null,\n    \"good_drainage\": true,\n    \"high_wind_protection\": true,\n    \"facing_away_from_wind_degrees\": 225.0,\n    \"shorter_distance_to_yard_gate\": true\n  },\n  \"reason_codes\": [\n    \"PRECIPITATION_PROTECTION\",\n    \"WIND_PROTECTION\"\n  ],\n  \"unevaluated_conditions\": []\n}\n```\n\n`primary_band` follows\n`WET > HOT > COLD > WINDY > DARK > LOW_VISIBILITY > BENIGN` for concise\nsummarization only. Never let precedence suppress another active condition or\napplicable dock preference.\n\nFor `weather_status: partial`, use every known active condition and attribute.\nNever treat an unevaluated condition as false and never discard confirmed\nweather facts because another field is missing. A partial assessment with\nconfirmed non-hazardous conditions may still use `primary_band: BENIGN`. For\n`weather_status: unavailable`, apply no weather preference and reason from\navailability and queue only. Missing and unevaluated fields always remain\ninternal.\n\n## Dock reasoning\n\nApply these rules in order:\n\n1. Exclude every dock where `occupied` is true.\n2. If no dock remains, return `status: no_available_dock`. Do not select a dock.\n3. Start with all unoccupied docks as the candidate set.\n4. Process active weather conditions in Python's returned order.\n5. For `WET`, `HOT`, or `COLD`, prefer `covered: true`. Apply the covered filter\n   once even when several of these conditions are active, but preserve every\n   active condition in the explanation.\n6. For `WET`, rank `drainage` as `good > fair > poor` and retain candidates with\n   the best available drainage value.\n7. For `WINDY`, rank `wind_protection` as `high > medium > low` and retain\n   candidates with the best available protection value. Then, when\n   `facing_away_from_wind_degrees` exists, calculate each retained candidate's\n   smallest circular angular difference and retain the closest candidate or tied\n   closest candidates.\n8. For `DARK` or `LOW_VISIBILITY`, prefer `lit: true`.\n9. When any active condition exists, retain candidates with the shortest\n   `distance_to_yard_gate_m` after applying the other weather preferences.\n10. Apply a weather filter only when at least one current candidate has a valid\n   value that satisfies it.\n   If none does, retain the current candidates and record that exact preference\n   in `weather_degradations`.\n11. Never discard all known weather reasoning because one condition is\n   unevaluated. Record each unevaluated condition as a limitation without\n   inventing a result.\n12. After occupancy and weather suitability have produced the retained candidate\n    set, determine the verified Drive Priority Pass tier reduction:\n    - `standard`: 0 trucks\n    - `plus`: 1 truck\n    - `extra`: 3 trucks\n    - `mega`: 5 trucks\n    Use 0 when `pass_verified` is false. Never apply a reduction based only on a\n    supplied or claimed tier.\n13. For each retained candidate where `priority: true`, calculate\n    `adjusted_trucks_ahead = max(0, trucks_ahead - tier_reduction)`, then calculate\n    `adjusted_expected_wait_seconds = adjusted_trucks_ahead *\n    queue_seconds_per_truck` and derive adjusted expected-wait minutes from those\n    seconds. For `priority: false`, keep the dock's original queue values. Do not\n    apply this calculation to occupied docks or candidates removed by weather\n    suitability.\n14. Treat each candidate's adjusted queue as its actual queue for this loading\n    plan. Retain candidates with the lowest resulting `expected_wait_seconds`.\n    Track `queue_narrowed_candidates` from this adjusted-wait comparison.\n15. Drive Priority Pass never overrides occupancy or weather suitability and\n    never makes an occupied or weather-inferior dock eligible.\n16. If candidates remain tied, retain the shortest `distance_to_yard_gate_m`.\n17. If candidates still remain tied, select the lowest `dock_id`.\n\nFor `recommend`, apply the Priority Pass queue calculation exactly once during\nthe initial recommendation. In `selected_dock`, replace `trucks_ahead`,\n`expected_wait_seconds`, and `expected_wait_minutes` with the adjusted values\nused for ranking, while preserving `queue_seconds_per_truck` and\n`queue_observed_at`. Use those same adjusted values for the customer-visible\nqueue and wait, ETA comparison, top-level `initial_trucks_ahead`,\n`canonical_state.initial_trucks_ahead`, retained recommendation evidence, and\nPDF inputs. Preserve the selected dock's pre-adjustment queue and the actual\nreduction in `decision_evidence`. For `queue_status`, pass the retained adjusted\nqueue anchors to Python and use its returned elapsed queue values unchanged;\nnever subtract the Priority Pass reduction again.\n\nTreat `wind_protection`, `drainage`, and `distance_to_yard_gate_m` as comparison\ndata only. Never ask Python to evaluate docks.\n\n## Queue and ETA reasoning\n\nGenerate exact queue wording:\n\n- zero: `There are no trucks ahead.`\n- one: `There is one truck ahead.`\n- more than one: `There are [n] trucks ahead.`\n\nWhen ETA is present, use `remaining_eta_seconds`, not the original relative ETA\nor rounded minutes, for every queue comparison:\n\n- wait seconds less than or equal to ETA seconds: `eta_status: before_arrival`\n- wait seconds greater than ETA seconds: `eta_status: may_extend_beyond_arrival`\n\nWhen ETA is absent, return `eta_status: not_provided` and never invent an arrival\ntime, clock time, or availability time. When `target_status` is `due_or_passed`,\nuse zero as the remaining ETA and state that any positive wait may extend beyond\nthe expected arrival.\n\n## Decision explanation\n\nThe explanation must be composed from the actual decision evidence. It must not\nbe a fixed sentence.\n\nInclude:\n\n- why the selected dock remained available\n- every active weather condition that affected its preferred attributes\n- every weather preference that could not be satisfied\n- how drainage, wind protection, lighting, or yard-gate distance affected the\n  comparison when applicable\n- why it won the adjusted queue comparison\n- the complete verified Drive Priority Pass outcome and normalized display\n  grade, and whether lowest dock ID resolved a final tie\n\nKeep pass and weather claims in `recommendation_reason` consistent with\n`decision_evidence`. Never expose the pass ID, raw `tier_code`, unevaluated\nconditions, or missing weather fields in `recommendation_reason`. For every\nverified pass outcome, show the normalized display grade exactly as `Standard`,\n`Plus`, `Extra`, or `Mega` in the required Priority Pass row. If no pass is\nverified, do not invent `Standard`.\n\n## Driver message\n\nFor `recommend`, compose one complete `customer_message` for the calling agent\nto present unchanged. It is the only driver-facing recommendation text.\nStructured fields support orchestration, retained evidence, diagnostics, and\nPDF rendering; never restate them outside `customer_message`.\n\nEvery `customer_message` returned by this skill, including `recommend`,\n`queue_status`, `no_available_dock`, and `state_unavailable`, must be exactly\none Markdown blockquote card with no text before or after it, built as one raw\nmessage string. Start every content row with `> `. For every multi-row card,\nplace the exact literal sequence `\\n>  \\n` between every adjacent content\nrow so that each `>` begins its own physical line. Never use a line containing\nonly `>`, a bare newline, or any alternative spacing method between content\nrows. Single-row cards need no spacer. All later references to adding a row or\nspacer use only this canonical rule. Keep the current simple visual hierarchy:\nbold card title and row labels, and no bullets, tables, horizontal dividers,\nnested cards, or additional decorative spacer rows. The raw-string pattern is:\n\n```text\n> [first content row]\n>  \n> [second content row]\n```\n\nReturn a `weather_icon` selected only from confirmed weather evidence:\n\n- `WET`: `?️`\n- `HOT`: `?️`\n- `COLD`: `❄️`\n- `WINDY`: `?`\n- `DARK`: `?`\n- `LOW_VISIBILITY`: `?️`\n- `BENIGN` with a confirmed current or selected-forecast condition: `?️`\n- no confirmed current or selected-forecast condition: an empty string\n\nWhen several conditions are active, use the icon for `primary_band`; describe\nevery confirmed condition that affected selection in the prose.\n\nReturn two free-text fields composed only after deterministic comparison:\n\n- `weather_summary`: a concise natural summary using every useful confirmed\n  fact that is relevant to the expected pickup. Lead with useful current\n  conditions. Include selected-forecast facts only when they materially affect\n  dock selection, driver guidance, or conditions expected around the retained\n  arrival target. When included, connect them explicitly to the pickup with\n  wording such as `Around your expected arrival`; do not append a general daily\n  or overnight weather report. Include actual temperature, feels-like only when\n  it differs by at least 3 degrees, visibility when relevant, and current wind.\n  For `HOT`, use natural wording such as `Hot conditions are expected around\n  your arrival, feeling like [X]°C` when feels-like is available, otherwise\n  `Hot conditions are expected around your arrival, with a temperature around\n  [X]°C`. Always include `°C`. Never say `humid high near`, `high near`, or use\n  a forecast high as though it were the retained feels-like value. Do not\n  produce a raw field list or repeat equivalent facts.\n- `driver_guidance`: concise practical guidance grounded in the selected\n  dock's cover, drainage, wind protection, facing, lighting, and yard-gate\n  distance. Mention only attributes that are relevant to confirmed conditions.\n  Do not state the dock number in this field.\n\nFree text never changes the selected dock. Never enumerate unavailable\nreadings, unevaluated conditions, omitted field names, API behavior, or internal\nlimitations. When no confirmed weather evidence exists, use only the defined\nWeather-block fallback.\n\nUse `available` only for an unoccupied dock. Use `covered` and `uncovered` only\nfor overhead weather protection. Never use `open` as a synonym for either\navailable or uncovered.\n\nTrack `weather_narrowed_candidates` as true only when an applied weather filter\nreduced the candidate count. Track `queue_narrowed_candidates` as true only when\nthe adjusted shortest-wait step reduced the candidate count. Return\n`priority_pass_queue_benefit_applied` as true only when the selected dock is\npriority-enabled and its adjusted queue is lower than its pre-adjustment queue.\nAlso return the selected dock's pre-adjustment trucks ahead, adjusted trucks\nahead, and actual reduction count. A tier allowance larger than the available\nqueue reduces only to zero and records only the positions actually removed.\n\nReturn one deterministic `decision_driver` using this precedence:\n\n1. `priority_pass_queue_benefit` when a nonzero verified Priority Pass queue\n   reduction was applied to the selected dock.\n2. `lowest_dock_id_tie_break` when the lowest dock ID resolved the final tie.\n3. `weather_and_queue` when both narrowing flags are true.\n4. `weather` when only `weather_narrowed_candidates` is true.\n5. `queue` when only `queue_narrowed_candidates` is true, including when a\n   retained weather preference matched every candidate and therefore did not\n   narrow the set.\n6. `distance_tie_break` when yard-gate distance was the final candidate-reducing\n   step.\n7. `availability` when occupancy left only one candidate before weather and\n   queue reasoning, so neither narrowing flag is true.\n\nWhen ETA is present, return signed `eta_margin_seconds` as\n`remaining_eta_seconds` minus `expected_wait_seconds`. A positive value is the\nremaining buffer, zero matches the expected arrival, and a negative value is\nseconds beyond it. When ETA is absent, return `eta_margin_seconds: null`.\n\nCompose the initial recommendation card in this content order: plan and\nfacility, weather, queue, optional ETA, dock planning and assigned dock, why,\nthen Priority Pass. Use the canonical raw-string boundary between adjacent\ncontent rows. Natural wording is allowed inside each required initial-plan row.\n\n1. Start with a grouped title-and-facility row identifying the loading-dock\n   plan and canonical pickup facility.\n2. Weather row: when `weather_icon` is nonempty, identify the row as Weather\n   and address the driver by verified first name\n   when available, followed by `weather_summary`. When no confirmed weather\n   evidence is available, use exactly\n   `> **?️ Weather:** Current weather details are unavailable, so the assignment uses the available dock and queue evidence.`\n   Missing optional weather evidence never suppresses a recommendation.\n3. Queue row: identify the row as Queue. State trucks ahead and\n   expected wait, then give only the supported comparison fact, such as the\n   retained wait range or whether this is the unique shortest wait. When weather\n   affected suitability, identify the relevant group only as the suitable\n   available docks. Reserve all explanation of why the dock was assigned for\n   the Assignment block. Do not use phrases such as `narrowed the comparison`\n   or `resolved the selection`. Do not state the dock number or repeat queue\n   values elsewhere.\n4. When ETA exists, add an ETA row. State the\n   arrival estimate and use `eta_margin_seconds` to explain the exact buffer,\n   match, or overrun. Format minutes and seconds naturally. Do not repeat the\n   wait value. Omit the row when ETA is absent.\n5. Add a dock-planning and assigned-dock row. This is the only\n   place before the Why row that may state the dock number and begins the final\n   section. Every successful recommendation must finish with a plain-English\n   explanation of why this dock was assigned.\n6. Add a Why row with concise natural prose.\n     Explain the observed condition, why it matters operationally, the dock\n     feature that addresses it, and the final fact that made this dock the best\n     fit. Say, for example, that hot conditions make shade useful or that rain\n     makes cover and drainage useful. Never use internal comparison language\n     such as `narrowed the comparison`, `resolved the selection`,\n     `candidate-reducing`, or `tie-resolving` in driver-facing text. Mention\n     queue causality only when `queue_narrowed_candidates` is true or the final\n     `decision_driver` is queue-based. When `decision_driver` is\n     `priority_pass_queue_benefit`, explain the actual before-and-after queue\n     benefit. Mention lowest dock ID only when it\n     resolved the final tie. Use `uncovered docks`, never `open docks`, as the\n     opposite of covered docks.\n   - When a relevant non-decisive benefit remains, add it naturally\n     in the Why prose. Every included benefit must state why it helps under a\n     confirmed active condition and must not repeat a cause already explained\n     in Why. Never list attributes by themselves.\n   Apply these condition-to-benefit rules:\n   - For `HOT`, cover matters because it provides shade and reduces heat\n     exposure.\n   - For `COLD`, cover matters because it provides shelter and reduces cold\n     exposure.\n   - For `WET`, cover helps keep loading dry and good drainage helps reduce\n     standing water.\n   - For `WINDY`, wind protection and a suitable facing help reduce wind\n     exposure around the truck and loading area.\n   - For `DARK` or `LOW_VISIBILITY`, lighting helps the driver see the dock and\n     approach more clearly.\n   - A shorter yard-gate route may be mentioned only when it decided the\n     assignment or when its reduced exposure to a confirmed active condition is\n     explained.\n   Omit drainage without `WET`; wind protection without `WINDY`; lighting\n   without `DARK` or `LOW_VISIBILITY`; and shade or heat protection without\n   `HOT`. Do not repeat queue or ETA values. Describe an unoccupied dock as\n   `available`, never `open`.\n7. Finish the card with exactly one Priority Pass outcome selected from these\n   mutually exclusive outcomes, using exactly one supported reason:\n   - Not verified:\n     `> ? **Priority Pass:** Not verified for this assignment.`\n   - A nonzero verified reduction was applied:\n     `> ? **Priority Pass ([Grade]):** Applied. Your queue was reduced by [reduction] position[s], from [before] truck[s] ahead to [after] truck[s] ahead.`\n   - Verified `Standard`:\n     `> ? **Priority Pass (Standard):** Verified. Standard provides no queue reduction.`\n   - Verified `Plus`, `Extra`, or `Mega` with a selected non-priority dock:\n     `> ? **Priority Pass ([Grade]):** Verified, but no queue reduction was applied because Dock [dock_id] is not priority-enabled.`\n   - A selected priority-enabled dock already had zero trucks ahead:\n     `> ? **Priority Pass ([Grade]):** Verified, but no queue reduction was needed because there were no trucks ahead.`\n   Use natural singular\u002Fplural grammar for `position[s]` and `truck[s]`. The\n   applied explanation may state that the adjusted queue helped selection. Do\n   not use equal-wait language. Use only the existing verified grade, selected\n   dock priority flag, pre-adjustment queue, adjusted queue, and actual\n   reduction; add no conditions or calculations. Never expose the pass ID or\n   raw `tier_code`. Follow-ups must reuse the retained pass outcome and grade\n   without recalculating either.\n\nReturn no preface, progress update, tool narration, duplicate summary,\ndisclaimer, closing sentence, text outside the card, or PDF offer. Never expose raw field names,\nfacility operating status, operating hours, local store time, missing readings,\nunevaluated conditions, or internal limitations. Before returning, ensure the\nmessage follows the canonical raw-line boundary rule, preserves the required\ninitial recommendation content order, states the dock number only in the\ndock-planning row and Why prose, and ends with the single Priority Pass outcome.\nThese formatting checks must never suppress an otherwise successful\nrecommendation.\n\n## Output\n\nReturn this structure:\n\n```json\n{\n  \"status\": \"recommended\",\n  \"shipment_reference\": \"ORD-10502\",\n  \"consignee_name\": \"Caribbean Market Logistics\",\n  \"delivery_destination\": \"Caribbean Market Tampa Hub, 6705 East Adamo Drive, Tampa, FL 33619\",\n  \"pickup_facility_name\": \"WanDelay Miami Distribution Center\",\n  \"selected_dock\": {\n    \"dock_id\": 2,\n    \"priority\": true,\n    \"covered\": true,\n    \"lit\": true,\n    \"facing\": 180,\n    \"wind_protection\": \"high\",\n    \"drainage\": \"good\",\n    \"distance_to_yard_gate_m\": 20,\n    \"trucks_ahead\": 2,\n    \"queue_seconds_per_truck\": 30,\n    \"expected_wait_seconds\": 60,\n    \"expected_wait_minutes\": 1.0\n  },\n  \"weather_assessment\": {\n    \"weather_status\": \"complete\",\n    \"assessment_basis\": \"expected_arrival\",\n    \"evidence_target_local_time\": \"2026-09-02T19:10:00-05:00\",\n    \"primary_band\": \"WET\",\n    \"selected_period\": \"day\",\n    \"effective_temperature\": 33,\n    \"current_conditions\": {\n      \"condition\": \"Cloudy\",\n      \"temperature\": 30,\n      \"feels_like\": 33,\n      \"visibility\": 8,\n      \"wind_direction\": 45,\n      \"wind_speed\": 25,\n      \"wind_gust\": 50\n    },\n    \"selected_forecast\": {\n      \"condition\": \"Rain showers\",\n      \"precipitation_chance\": 70,\n      \"summary\": \"Periods of rain are expected.\"\n    },\n    \"active_conditions\": [\"WET\", \"WINDY\"],\n    \"reason_codes\": [\n      \"PRECIPITATION_PROTECTION\",\n      \"WIND_PROTECTION\"\n    ],\n    \"unevaluated_conditions\": []\n  },\n  \"decision_evidence\": {\n    \"weather_matches\": [\n      \"Covered for expected precipitation\",\n      \"Good drainage for expected precipitation\",\n      \"High wind protection and closest available facing for strong wind\",\n      \"Shortest weather-exposed yard route among the suitable docks\"\n    ],\n    \"weather_degradations\": [],\n    \"weather_limitations\": [],\n    \"queue_comparison\": \"Adjusted current wait for the dock meeting the retained weather preferences\",\n    \"weather_narrowed_candidates\": true,\n    \"queue_narrowed_candidates\": false,\n    \"priority_pass_queue_benefit_applied\": true,\n    \"priority_pass_original_trucks_ahead\": 5,\n    \"priority_pass_adjusted_trucks_ahead\": 2,\n    \"priority_pass_queue_reduction\": 3,\n    \"lowest_dock_id_resolved_tie\": false\n  },\n  \"weather_icon\": \"?️\",\n  \"decision_driver\": \"priority_pass_queue_benefit\",\n  \"queue_observed_at\": \"2026-09-02T18:50:00-05:00\",\n  \"initial_trucks_ahead\": 2,\n  \"canonical_state\": {\n    \"assigned_dock_id\": 2,\n    \"queue_observed_at\": \"2026-09-02T18:50:00-05:00\",\n    \"initial_trucks_ahead\": 2,\n    \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n    \"latest_queue_status\": null\n  },\n  \"eta_margin_seconds\": 1140,\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_seconds\": 1200,\n  \"remaining_eta_minutes\": 20,\n  \"target_status\": \"future\",\n  \"weather_summary\": \"It is currently cloudy and 30°, feeling like 33°, with winds of 25 km\u002Fh and gusts up to 50 km\u002Fh. The daytime forecast calls for rain showers with a 70% chance of precipitation.\",\n  \"driver_guidance\": \"Covered loading and good drainage help keep the loading area dry, while high wind protection and a suitable facing reduce wind exposure around the truck.\",\n  \"customer_message\": \"> **? LOADING-DOCK PLAN** · **? Facility:** WanDelay Miami Distribution Center\\n>  \\n> ?️ **Weather:** Jordan, it is currently cloudy and 30°, feeling like 33°, with winds of 25 km\u002Fh and gusts up to 50 km\u002Fh. Around your expected arrival, rain showers are forecast with a 70% chance of precipitation.\\n>  \\n> ? **Queue:** There are two trucks ahead, with an expected wait of one minute, at the suitable available dock with the current wait shown in this plan.\\n>  \\n> ⏱️ **ETA:** You expect to arrive in 20 minutes. That leaves a 19-minute buffer before your expected arrival.\\n>  \\n> **? DOCK PLANNING** · **Assigned Dock is 2**\\n>  \\n> ? **Why:** Rain is expected near your arrival, so a covered dock with good drainage helps keep loading dry and reduces standing water. Strong winds also make wind protection important around the truck and loading area. Dock 2 was assigned because its facing provides the best available protection from the current wind. Its shorter yard-gate route reduces the time you may spend exposed to the rain. Your verified Priority Pass also reduced the queue used for this plan from five trucks ahead to two.\\n>  \\n> ? **Priority Pass (Extra):** Applied. Your queue was reduced by 3 positions, from 5 trucks ahead to 2 trucks ahead.\",\n  \"eta_status\": \"before_arrival\",\n  \"recommendation_reason\": \"Rain makes covered loading and good drainage useful for keeping the loading area dry, while strong winds make wind protection important. The assigned dock has the best available facing away from the current wind, and the verified Priority Pass reduced its queue from five trucks ahead to two.\"\n}\n```\n\nFor no available dock, return:\n\n```json\n{\n  \"status\": \"no_available_dock\",\n  \"selected_dock\": null,\n  \"canonical_state\": {\n    \"assigned_dock_id\": null,\n    \"queue_observed_at\": null,\n    \"initial_trucks_ahead\": null,\n    \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n    \"latest_queue_status\": null\n  },\n  \"target_local_time\": \"2026-09-02T19:10:00-05:00\",\n  \"remaining_eta_minutes\": 20,\n  \"target_status\": \"future\",\n  \"weather_icon\": \"\",\n  \"decision_driver\": null,\n  \"eta_margin_seconds\": null,\n  \"customer_message\": \"> **⛔ NO LOADING DOCK AVAILABLE**\\n>  \\n> No loading dock is currently available.\\n>  \\n> **? Next step:** Please try again shortly.\",\n  \"recommendation_reason\": \"No loading dock is currently available.\"\n}\n```\n\nReturn the timing fields even when no dock is available so the calling agent can\nretain an arrival target created or adjusted during that decision run. Use null\ntiming values when the driver has no ETA.\n\nFor invalid or unavailable canonical state, return:\n\n```json\n{\n  \"status\": \"state_unavailable\",\n  \"customer_message\": \"> **⚠️ QUEUE UPDATE UNAVAILABLE**\\n>  \\n> I can't safely update the pickup queue because the current assignment state is unavailable.\\n>  \\n> **? Next step:** Start a new shipment pickup request.\"\n}\n```\n\nNever return or expose a Drive Priority Pass ID, raw `tier_code`, `occupied_by`,\nother driver details, cargo, raw tool output, or private reasoning. For every\nverified pass outcome, the required Priority Pass row shows exactly one\nnormalized grade: `Standard`, `Plus`, `Extra`, or `Mega`. If no pass is\nverified, use `Not verified for this assignment` and do not invent a grade.\n",{"name":5,"description":7},"main","61fc526426f0f3638ce793490e5032ee247c0cb0","submissions\u002Fwandelay-loading-bay-pickup\u002Fsolution\u002Fbotcomponents\u002Fcrf98_curbsidepickupassistant_Q0mRmz.file.skillmd_FPadO\u002Ffiledata",25,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 13:20:22",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add microsoft\u002Fcopilot-studio-gallery --skill loading-dock-selector",{"tool":50,"command":51},"bunx","bunx skills add microsoft\u002Fcopilot-studio-gallery --skill loading-dock-selector",{"tool":53,"command":54},"pnpm","pnpm dlx skills add microsoft\u002Fcopilot-studio-gallery --skill loading-dock-selector","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwandelay-loading-bay-pickup\u002Fsolution\u002Fbotcomponents\u002Fcrf98_curbsidepickupassistant_Q0mRmz.file.skillmd_FPadO\u002Ffiledata\u002FSKILL.md",true,[],[59,78,110,135,169,195],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":70,"publishedAt":30},"01M69B6A39RF106PPXC8V5DD32","dock-assignment-pass-pdf","Render the completed truck loading-dock assignment as a driver-facing one-page PDF.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwandelay-loading-bay-pickup\u002Fsolution\u002Fbotcomponents\u002Fcrf98_curbsidepickupassistant_Q0mRmz.file.skillmd_gYycZ\u002Ffiledata\u002FSKILL.md",[65],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[71,72,73,74,75,76,20,77],"PDF","dock assignment pass pdf","page","as","driver","render","one-page",{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":88,"publishedAt":30},"01M69B6435KYGSK2AV9QKDDWFP","newsletter-style-email-composer","Use when the user asks to email a report, findings, or metrics to someone as a polished, newsletter-style message. Builds an Outlook-safe HTML email from figures that already exist (headline, KPI tiles, up to two bar charts drawn with HTML table cells so they render in classic Outlook, Gmail and dark mode, short findings, data notes and the non-audit disclaimer) using the shared brand tokens, attaches the PDF report, and creates a draft for the user to review. Do NOT use for a short plain-text status update, or for building the underlying analysis, charts, or report itself -- this skill only composes the email.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fsales-analyser\u002Fsolution\u002Fbotcomponents\u002Fcrf9c_salesanalyser_WEs93i.file.skillmd_oCdhy\u002Ffiledata\u002FSKILL.md",[84,85],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":86,"categoryName":87,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000005","邮件与沟通",[89,90,91,92,93,94,71,95,96,97,98,99,100,101,102,103,104,105,106,76,107,108,109],"newsletter style email composer","email","email composer","newsletter","style","composer","gmail","review","safe","status","notes","analysis","Charts","text","short","only","up","shared","plain-text","mode","when",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":122,"publishedAt":30},"01M69B6247HGXJN2SMMXSZ6RA9","polished-report-builder","Use when the user asks to turn analysis results, metrics, or findings into a polished, presentation-ready report, one-pager, or executive summary -- especially when existing analysis (e.g. from the spreadsheet analysis skill) needs to become a document someone will actually read. Builds a branded PDF with reportlab from a short content file (headline, KPI tiles, one chart per point, data notes and the non-audit disclaimer) using the shared brand tokens, and runs a QA pass before delivery to catch walls of text, chart clutter, low-resolution charts, missing data notes or poor contrast. Do NOT use for a quick inline chat answer, a single ad-hoc chart with no report structure around it, a raw data export with no narrative, or to compute the figures themselves.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fsales-analyser\u002Fsolution\u002Fbotcomponents\u002Fcrf9c_salesanalyser_WEs93i.file.skillmd_k_QDN\u002Ffiledata\u002FSKILL.md",[116,117],{"categoryNo":66,"categoryName":67,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[123,124,125,126,71,99,127,128,129,100,101,102,103,130,106,131,132,133,134,109],"polished report builder","report","builder","report builder","executive summary","qa","spreadsheet","ready","chart","quick","catch","data export",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":150,"publishedAt":30},"01M69B5ZZQAN0F4G895841974H","spreadsheet-data-analysis-reporting","Use for any request that needs figures from the sales spreadsheets (Excel\u002FCSV), even a single file or a single period - e.g. 'analyse Q4', 'how did sales do last month', 'compare regions', YoY\u002FMoM\u002FQoQ\u002FYTD growth, top products, share of revenue, trends, outliers, currency-converted totals, or building\u002Fupdating a consolidated master file. Finds and loads the relevant files, cleans and normalises them, computes metrics with standard definitions and edge-case handling, flags outliers and data issues, explains every transformation, and produces on-brand charts. Use this before the report or email skills whenever numbers must be computed. Do NOT use for questions that need no data (e.g. 'what does YoY mean') or for re-formatting results already computed in this conversation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fsales-analyser\u002Fsolution\u002Fbotcomponents\u002Fcrf9c_salesanalyser_WEs93i.file.skillmd_6IAVT\u002Ffiledata\u002FSKILL.md",[141,144,147],{"categoryNo":142,"categoryName":143,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000004","电子表格",{"categoryNo":145,"categoryName":146,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":148,"categoryName":149,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000033","数据分析师",[151,152,153,154,129,100,155,156,157,101,158,159,160,161,162,163,164,165,166,167,168],"data analysis","spreadsheet data analysis reporting","reporting","data","xlsx","spreadsheets","issues","how","files","conversation","flags","currency","revenue","relevant","re","top","request","analyse",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":179,"publishedAt":30},"01M69B5YC45P39BX11JGAC2NGC","generating-podcast-script","Use this skill whenever the user asks to write, generate, or create a podcast script or podcast episode — from a topic, or from source material such as a news digest, newsletter, email review, or set of articles — and optionally convert it to audio with Azure Text-to-Speech. Handles the initial request and every follow-up refinement (source, topic, length, cast, narration) in the same task.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fpodcast-generation-agent\u002Fsolution\u002Fbotcomponents\u002Fcr88d_podcastdemo_OMpe9u.file.skillmd_A9jgI\u002Ffiledata\u002FSKILL.md",[175,176],{"categoryNo":86,"categoryName":87,"taxonomyType":68,"taxonomyTypeDesc":69},{"categoryNo":177,"categoryName":178,"taxonomyType":68,"taxonomyTypeDesc":69},"01JBSEEDCAT000000000000016","图像与多媒体",[180,181,182,183,96,184,185,186,187,188,189,102,190,105,92,191,192,74,193,194,167],"generating podcast script","podcast","script","podcast script","azure","create","generate","speech","SET","Audio","write","narration","digest","follow-up","source",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":204,"publishedAt":30},"01M69B5WQ38T2TR7RRP84SHRAX","internal-consistency-review","Use when the user asks for the Internal Consistency Review of a contract, or asks to check a contract for internal conflicts, inconsistencies between sections, or gaps and unfilled elements. Do NOT use for comparing the contract against external law - that is the separate Legal Compliance Review skill.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcopilot-studio-gallery\u002Fblob\u002Fmain\u002Fsubmissions\u002Fcontract-compliance-reviewer\u002Fsolution\u002Fbotcomponents\u002FDefault_Contract_Compliance_Reviewer_8c0b11.file.skillmd_maMHB\u002Ffiledata\u002FSKILL.md",[201],{"categoryNo":202,"categoryName":203,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000037","律师与法务",[96,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,109],"internal consistency review","consistency","legal compliance review","compliance","check","user","use","legal compliance","conflicts","legal","do","review skill","contract","elements","compliance review","for","gaps"]