Capability Scanner

Capability Scanner

Use this skill to assess whether a product, implementation, model-access record, or provider belongs in the AI Capability Reference.

Load references/GOVERNANCE.md when:

• a candidate seems borderline
• ontology placement is unclear
• you need the current capability taxonomy or scope heuristic
• you need the current tracked set for comparison

Load references/SCAN_WORKFLOW.md when:

• you are running a broader scan rather than evaluating one candidate
• you need signal-gathering guidance
• you need source-priority or recommendation conventions

Core Job

For each candidate:

1. Determine what kind of thing it is.
2. Check whether it is consumer-facing, commercially available, or practically usable by an ordinary person.
3. Assess whether tracking it would materially help the audience understand capabilities, access, constraints, or deployment choices.
4. Recommend one of: ADD, UPDATE, WATCH, SKIP.
5. Cite the best available sources, preferring official sources.

Output Format

Use this structure:

CANDIDATE: [brief name]
ENTITY TYPE: [Capability | Implementation | Product | Provider | Plan | Surface | Deployment Mode | Model Access | Constraint]
PROVIDER: [if applicable]
PRODUCT: [if applicable]

WHAT CHANGED:
[1-2 sentence summary]

ONTOLOGY FIT:
- Why this entity type is correct
- Any entity-type ambiguity that remains

CAPABILITY MAPPING:
- [capability slug]
- [capability slug]

SCOPE ASSESSMENT:
- Commercially available or practically usable: [Yes/No + reason]
- Audience relevance: [Yes/No + reason]
- Affects capability, access, or deployment choice: [Yes/No + reason]

RECOMMENDATION: [ADD | UPDATE | WATCH | SKIP]
RATIONALE:
- [short point]
- [short point]

EVIDENCE:
- [Official source]
- [Official source]
- [Secondary source, if useful]

OPEN QUESTIONS:
- [only if needed]

Decision Rules

• Prefer official sources over press coverage.
• Do not treat a marketing name as a capability.
• Do not treat a model family as a product.
• Do not force open/self-hosted things into one bucket.
• Treat ~1% market share as a heuristic, not a hard threshold.
• Use WATCH for borderline candidates or incomplete evidence.
• If the case is weak, do not invent certainty.

What To Look For

Good candidates usually involve one of these:

• a new consumer-facing product with meaningful public visibility
• a new implementation on an already tracked product
• a pricing or entitlement change that affects user decisions
• a meaningful new surface or deployment option
• an open model family or runtime that real people can select or run locally

Usually skip:

• enterprise infrastructure with no clear end-user product
• API-only changes with no user-facing impact
• minor renames or vague model-quality claims
• obscure releases that do not clear the audience-relevance bar

Watchlist Rule

If a candidate may belong but does not clearly justify active tracking yet, recommend WATCH rather than ADD. Treat that as a watchlist candidate, not a failed evaluation.

Related Skill

Use the capability-audit skill instead when:

• You want to check whether existing tracked products are correctly mapped to a capability
• A capability card looks thin (too few products listed) and you want to know why
• You've added a new capability definition and want to populate it from existing data

The scanner evaluates incoming candidates (one at a time, from outside). The capability audit checks internal completeness (systematically, across all tracked products for a given capability).