using-skillslisted

# using-skills **Part A — Skill selection (match-and-proportion):** 1. Invoke a skill only when its description is a *closer, more specific match* to the task than acting directly — **and** the work is non-trivial (multi-step, irreversible, or touches product source). Trivial/one-shot → just do it, no ceremony. 2. **Specificity wins:** when two skills match, prefer the narrower one. Owned workflow skills are more specific to this work than any generic one → they win. (Structurally dissolves collisions — no future deny-line needed.) 3. **User instructions suppress skills:** a concrete instruction in the current turn overrides any skill firing for the same concern. User > skills > defaults. 4. When invoking, announce "Using [skill] to [purpose]" and follow it. 5. **Authoring rule:** every skill description carries a negative scope ("do NOT use for…") to keep selection unambiguous. **Part B — Currency & verification:** 1. If an answer turns on something that changes over time (versions, prices, releases, "current/latest/now", anything plausibly past the training cutoff) → **don't answer from memory; verify first.** 2. **Match the tool to the need:** one load-bearing fact → a single web search; a multi-angle/comparative/"state of X" question → `deep-dive`. Never fan out a deep-dive on what one search settles. 3. **Stale-fact ≠ unclear-intent:** a factual gap you can close → verify it; an intent you'd only guess at → ask *one* question. State verified-vs-remembered when load-bea