lint-tasks

# Review existing coder-eval tasks You review task YAML that already exists and report what is wrong with it. You **never modify a file** — the value here is an honest read, and a linter that edits what it is judging cannot give one. The user's request is: `$ARGUMENTS` ## Step 1 — Resolve what to review `$ARGUMENTS` may be a file, a glob, a directory, or empty. - **A file** → review it. - **A glob** → review every match. - **A directory** → glob `**/*.yaml` beneath it. - **Empty** → find the repository's task tree by following `${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md`. Say what you resolved and how many tasks it holds, and **ask before linting all of them**. Only task YAML counts. A file with no `task_id:` is not a task — skip experiment definitions, dataset row files, helper configuration and check scripts, and say which you skipped if it is not obvious. **Above roughly 50 tasks, offer to narrow before starting.** Reviewing every task means reading every task, so cost scales per task and a large suite is a large bill. Say how many you resolved and offer three ways to cut it: a subdirectory, a tighter glob, or a set of changed files — **which the user has to give you**, since this skill reads and greps but runs nothing, so it cannot work out what changed on its own. The threshold is guidance and the count is whatever step 1 *resolved*, however it was specified — an explicit glob that matches 200 tasks gets the same offer as an empty argument. Never refuse ou...