fix(skills): prevent LLM from refusing pagination and denying filter support

src/lightspeed_agent/core/skills/multi-step-workflows/SKILL.md

@@ -25,15 +25,18 @@ then query its CVEs with the appropriate filter parameters (Vulnerability).
 When a tool supports filter or query parameters, use them to narrow results rather
 than retrieving everything and telling the user to ask again.
 
-### Common filter parameters
+### Common filter parameters [STRICT]
+
+These parameters are confirmed available — use them directly without a schema lookup.
+Do NOT claim a tool lacks filtering support when these parameters are listed here.
 
 **vulnerability__get_cves**: `limit`, `offset`, `sort` (e.g., `-cvss_score`),
 `severity` (Critical, Important, Moderate, Low), `known_exploit` (true/false),
 `affecting` (true/false — only CVEs affecting at least one system).
 
-**vulnerability__get_system_cves**: `limit`, `offset`, `sort`, `severity`,
-`status` (Applicable, Not applicable), `known_exploit`, `remediation`
-(Applicable — has a remediation available).
+**vulnerability__get_system_cves**: `limit`, `offset`, `sort`, `severity`
+(Critical, Important, Moderate, Low), `status` (Applicable, Not applicable),
+`known_exploit` (true/false), `remediation` (Applicable — has a remediation available).
 
 **inventory__list_hosts**: `limit`, `offset`, `hostname_or_id`,
 `display_name`, `tags`, `operating_system`, `order_by`, `order_how` (ASC/DESC).
@@ -68,6 +71,13 @@ health report
 (breaking changes) → inventory__list_hosts + inventory__get_host_system_profile
 (current versions) → assess readiness
 
+**"How many critical remediable CVEs are on host X?"** (counting query)
+→ inventory__list_hosts (hostname_or_id=X) → get the host ID →
+vulnerability__get_system_cves (severity=Critical, remediation=Applicable, limit=1) →
+read **`meta.total_items`** from the response → report the count.
+You do NOT need to fetch every page to answer "how many" — `meta.total_items` gives
+the total matching the filters in a single call.
+
 When a request is simple and genuinely maps to a single tool (e.g., "list my hosts" →
 inventory__list_hosts), a single tool call is fine. The point is: think first, don't
 default to one-and-done.

src/lightspeed_agent/core/skills/pagination-handling/SKILL.md

@@ -75,3 +75,23 @@ report that fewer pages were available (avoids empty-page / out-of-range errors)
 parameter names or response shapes. After each response, advance `offset`/`page`
 using `meta`/`links.next` or `total`/`per_page` as appropriate for that API.
 If the pagination shape is unfamiliar, use `*_get_openapi` to confirm before looping.
+
+## Never Refuse to Paginate or Count [STRICT]
+
+Do NOT tell the user that paginating, counting, or filtering results is "beyond your
+operational capacity" or would "exceed resource limits." You have no such limits — the
+tools support pagination and filtering, and you can call them as many times as needed.
+
+When the result set is large:
+1. **Apply filters first** — use `severity`, `remediation`, `status`, `known_exploit`,
+   or other parameters documented in the `multi-step-workflows` skill to narrow results
+   before paginating.
+2. **Use `meta.total_items` for counting** — a "how many" question never requires
+   fetching every page. Make one filtered call with `limit=1` and read
+   `meta.total_items` from the response.
+3. **Paginate when needed** — if the user needs actual data (not just a count), paginate
+   through all pages using the stop conditions above.
+
+If a tool result triggers a `tool_result_too_large` error, follow the retry strategies
+in the `error-handling` skill (reduce page size, add filters). Never treat a large
+result set as a reason to give up.