--- name: smartling-localisation-job-triage description: Triage open Smartling translation jobs and issues the way an experienced localisation manager does, finding what is stuck, overdue or blocked and sorting it into what needs a human decision today. Read-only. Use when the user asks what is stuck in translation, which jobs are overdue, what needs attention this week, or wants a status review of open localisation work. --- # Triage open localisation work The goal is a short, ranked list of what needs a human decision today, with the reason each item is stuck. A job list with statuses is not triage. Triage says which job is blocking a release, which one is only slow, and which one will miss its date unless someone acts. This skill only reads. It never changes a job, issue or account. If the fix is a state change, say what it is and stop for approval. ## 1. Confirm the account and project scope first Before listing anything, establish which account and project you are looking at. Use `smartling_get_available_accounts_for_current_user` to see what the user can access, and `smartling_get_project` to confirm the project id and its target locales. If the user has more than one account, ask which one, and do not guess from a previous conversation. Switching the active account changes the context for every later call, so wait for the user's explicit yes before you switch. ## 2. Pull the open jobs, then their history Start with the jobs that are not finished. Use `smartling_get_job` for each job the user cares about, and read its target locales, status, due date and any authorisation state. Then use `smartling_get_job_history` for the jobs that look stalled. A job that has not moved in several days is a different problem from one that is simply new. Work in this order, because it narrows the problem fastest: 1. **Due date within about 3 working days and not authorised or not complete.** This is the most urgent group. 2. **Stalled jobs with no history movement for more than about 5 working days.** Check whether anyone is waiting on a decision. 3. **Jobs with many open issues.** Go to step 3 for these. 4. **Everything else.** Batch it into one line each. ## 3. Count the open issues before reading them Use `smartling_count_project_issues` for the project and `smartling_count_account_issues` for the wider account to see the size of the backlog before you pull details. Then use `smartling_find_project_issues` or `smartling_find_account_issues` to list the open ones, and page through them rather than requesting everything at once. For each issue that matters, read it with `smartling_get_issue` and check the latest comments with `smartling_get_issue_comment`. Issues blocking a job matter more than issues that are informational. Sort by whether the issue touches a job that is due soon. ## 4. Separate "stuck" from "slow" from "waiting on a person" Each item in the list needs one of these labels, because each has a different owner: - **Blocked on a source or content decision:** the issue asks what the source means or whether a string should change. The owner is the content team, not localisation. - **Blocked on a glossary or terminology decision:** the issue is about a term. The owner is whoever owns the glossary. - **Slow:** work is progressing but the due date is at risk. The owner is the translation vendor or the project manager. - **Waiting on authorisation:** the job is ready but nobody has approved it. The owner is whoever holds the authorisation step. - **No movement, no reason visible:** history shows nothing and no issue explains it. Say so; this is itself a finding. Do not label something "blocked" unless you can point to the issue or the missing authorisation that blocks it. ## 5. Check for what is missing The most useful findings are often absent: - A due date that is empty on a job that has a deadline elsewhere. - A target locale with no work on it at all. - A job with issues raised but no comment from anyone in the last week. - Strings added to a job after it was authorised, which may not have been translated. Use `smartling_get_job` and the history to check these before reporting them. ## Common patterns and traps - **Open issue counts that look large but are mostly old.** Check the age of the issues. A backlog of six-month-old informational issues is noise. Report it briefly and move on. - **A job that is "in progress" with no history for a week.** This usually means it is waiting on a person, not on the vendor. Say that before blaming the vendor. - **Several jobs blocked by one issue.** Report the issue once, with the jobs it blocks, instead of repeating it under each job. - **Due dates that are in a different time zone from the user.** Note the time zone when a deadline is within a day. - **Confusing the count with the list.** A count is a snapshot. Page the list before you say how many items exist in a category. - **Treating every issue as a translation error.** Many are source-text questions. Route those to the content owner, not the translators. ## Output ``` Scope: / , open jobs, open issues (counted, not all read) Needs a decision today 1. :