triage-applicationlisted

# /triage-application — Application Triage (Score, Sort, Route) > **Purpose.** Score and sort an incoming application submission. Triggered by the `lead.applied` webhook fired from `/build-application` Step 7 (per the FSM in `workflows/divisions/acquisition.md`: ApplicationSubmitted → AppTriaged). Output is one of three routes: **Booked** (calendar link sent automatically), **AppDQ** (archive with reason + decline message), **AppOperatorReview** (borderline — surfaces to operator with full triage rationale). Per `INVARIANTS.md` N-12, calendar links are minted *only* by this skill, only after triage, only for the Booked tier. Per A-13, hard-DQ trips default to **AppOperatorReview**, not auto-archive — operator confirms or overrides. > > **Bar.** Time from `lead.applied` event to one of the three routes is < 30 seconds for the workspace's automated portion. Operator's portion (AppOperatorReview queue review) takes < 90 seconds per item per the partner skill `/build-application` validation Check 2. > > **The load-bearing role.** Triage is where the calendar gate becomes binding. The form (`/build-application`) collects signal; this skill converts signal into an FSM state transition. Get the tier boundaries wrong and either close rate collapses (over-permissive Booked) or qualified prospects slip out the side door (over-restrictive AppDQ). Get A-13 wrong and the operator loses authorship of the DQ decision, which is the strongest brand signal the agency emits. ## When to invoke