Use when selecting a detection strategy and implementation primitive for a context-intelligence signal — classifies signals as deterministic/probabilistic/llm-evaluated/hybrid and applies the cheapest-sufficient-capability principle.
SKILL.md
Context Intelligence Tool Design
Phase 2 specialist skill, called by the context-intelligence-tool-designer agent via self-delegation with context_depth="none", scoped to one signal (or one logical batch of related signals) at a time.
Design depth for how a chosen primitive is shaped. These are mode-only design guidance; they
point to existing homes rather than restating them.
R1 — Wrapper form by consumer: module vs CLI
The shared-library → thin-wrapper pattern itself already has a home: it is the mode's
Standing Rule 3 (modes/context-intelligence.md). Do not restate that pattern — point to
Standing Rule 3. R1 adds only the new nuance: once you have a shared library, choose its
wrapper form by who consumes it:
An agent consumes it → wrap the shared library as an Amplifier module (agent tool).
A human or script consumes it → wrap it as a CLI (bash subcommand).
Same library, wrapper form chosen by consumer — module vs CLI is a consumer decision, not a
default.
R2 — Exploit narrow-domain knowledge
When the domain is specific enough, build a specialized tool that returns exactly what is
needed — avoiding discovery round-trips and bloated tool responses. A narrow, purpose-built
result beats a general query the caller must post-process.
R3 — Progressive over upfront
Prefer progressive discovery + pagination/navigation over big upfront reads. The operational
rules for this (probe-first, ≤3-strategy ladder, head-limited extraction, summarize-and-discard,
the call budget) live in the authoritative discipline file — open it on demand:
context-intelligence:context/navigation-budget-discipline.md. Do not rephrase those rules
here.
Guard — event semantics: Do not restate the event-semantics authority principle here. It
is named once in context-intelligence:context/context-intelligence-strategy.md — reference
it there.
Scope
In Scope
Classify detection strategy for a signal (deterministic / probabilistic / llm-evaluated / hybrid)
Select the correct Amplifier primitive for the signal
Populate the five enrichment fields: detection_strategy, detection_notes, ai_dependency, reasoning_requirement, suggested_primitive
Out of Scope
Investigating signals
Refining concept definitions
Designing evaluation scenarios
Anything that cannot be classified due to a vague concept → return a structured gap entry, do not investigate.
Per-Signal Classification Process
Step 1: Read the Signal Entry
Read the signal entry from domain-signals.md — read only that entry, not the full file.
Step 2: Apply Detection Strategy Tier Decision
Apply detection strategy tier decision in the following exact order:
Deterministic first — event structure parsing only:
Event type presence
Field value match
Count threshold
Time window
Sequence
Probabilistic second — pattern matching + thresholds:
Regex
Ratio
Shape
Size threshold
LLM-evaluated only if neither deterministic nor probabilistic works. Before committing to pure LLM-evaluated, ask whether deterministic feature extraction can narrow scope. If yes → choose hybrid.
