← WingspanCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Wingspan
Snapshot Sep 30, 2026 · 23:10 UTC · version 1.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "List the contractors who have one named onboarding requirement outstanding, such as a W-9, a certificate of insurance or a background check. Run it with the requirement's name. It reports who has not finished the requirement; it does not confirm whose payments are blocked by it.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 354
}
],
"name": "outstanding",
"skill_md_contents": "---\nname: outstanding\ndescription: List the contractors who have one named onboarding requirement outstanding, such as a W-9, a certificate of insurance or a background check. Run it with the requirement's name. It reports who has not finished the requirement; it does not confirm whose payments are blocked by it.\n---\n\n# Who still has this outstanding: $ARGUMENTS\n\nA **requirement** is something a contractor must satisfy before the company can\npay them. The company configures each one once, and every contractor placed on\nan engagement gets their own copy. This answers \"who has not finished\n$ARGUMENTS\". It does not answer \"whose payment is blocked\": whether an\noutstanding copy blocks payment depends on where it was attached, which these\ntools do not read.\n\nIf no requirement was named, list the company's requirements with\n`search_requirements` and ask which one the user means. Do not guess.\n\n## Step 1 — find the requirement\n\nCall `search_requirements`. Match `$ARGUMENTS` against the `name` of each\nresult, case-insensitively and in full. A partial name does not count as a\nmatch. The result is one page; if nothing on it matches and the result carries\n`pagination.nextPageArgs`, call again with those arguments and keep going until\na match appears or there is no next page. Only then is \"no match\" true.\n\n- **No match on any page.** Show the names that came back and ask which one\n was meant. Do not substitute a similar-sounding one.\n- **More than one match.** Show the candidates and ask. Requirement names can\n be near-identical across engagements, and answering for the wrong one is\n worse than asking.\n\nKeep two fields from the match: its `requirementDefinitionId` and its\n`blocking` value.\n\n## Step 2 — find who has not finished it\n\nCall `search_contractors` with `requirement` set to that\n`requirementDefinitionId` and `requirementState` set to `incomplete`, which\nmeans outstanding — the contractor has not finished it.\n\nThat returns one page. Report the page, then offer the next one using the\nresult's `pagination.nextPageArgs`; do not fetch further pages unasked.\n\n## Step 3 — report\n\nLead with the count and the requirement's full name, worded as \"have this\noutstanding\", not \"are blocked\". Then list the contractors by name, with their\nonboarding state, so the user can see who has not even signed up yet versus\nwho signed up and has not finished.\n\nAlways add this caveat, whatever the definition's `blocking` value says:\nwhether an outstanding copy actually holds up a payment depends on where the\nrequirement was attached to that contractor. A placement that is not blocking\nonly tracks the copy; an engagement placement can also block eligibility while\nstill allowing payment. `get_contractor` does not read that setting and treats\nevery incomplete requirement as blocking, so the Wingspan app is the place to\nconfirm before telling anyone their payment is or is not blocked. If the\ndefinition is not marked blocking, say so as well: an outstanding copy is then\nusually tracked rather than holding anyone up.\n\nThen add whichever of these applies:\n- **If the user wants a different slice**, the same pair of calls answers it\n with a different `requirementState`: `pendingReview` for submitted and not\n yet reviewed, `expiring` for satisfied but about to lapse, `expired` for\n lapsed, `complete` for finished.\n- **A rejected or revoked requirement reads as outstanding again.** One the\n company rejected, or one whose underlying record was revoked or failed, is\n reopened rather than failed, with a reason recorded. There is no failed\n state, so say \"reopened after review\" rather than \"never started\" about such\n a contractor.\n\nFor one contractor's full picture, `get_contractor` with their `contractorId`.\n\n## What cannot be done from here\n\nNudging a contractor, approving or rejecting what they submitted, resetting or\nrenewing a requirement, and extending an expiry date all happen in the Wingspan\napp. So does everything the contractor does themselves — signing, uploading,\nverifying identity. Sharing tax information is usually the contractor's step\ntoo, but a company can instead record and verify a contractor's taxpayer\ndetails itself, in the app.\n"
}SHA-256 of public snapshot: a4b78a48c9af868221e340be0acb3ec234a8cddc3dfa0e15405dd8b7955de05c