Claude-skill-registry detect
Determine whether a specific pattern, entity, or condition exists in the given data. Use when searching for patterns, checking existence, validating presence, or finding signals.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/detect" ~/.claude/skills/majiayu000-claude-skill-registry-detect && rm -rf "$T"
skills/data/detect/SKILL.mdIntent
Scan data sources to determine whether a specified pattern, entity, or condition is present. Detection is binary (present/absent) with associated signal strength.
Success criteria:
- Clear boolean determination of presence/absence
- At least one evidence anchor for positive detections
- False positive risk assessment provided
- Confidence score justified by evidence quality
Compatible schemas:
schemas/output_schema.yaml
Inputs
| Parameter | Required | Type | Description |
|---|---|---|---|
| Yes | string|object | The data source to scan (file path, URL, or structured data) |
| Yes | string|regex | The pattern, entity type, or condition to detect |
| No | object | Detection sensitivity settings (e.g., min_matches, confidence_floor) |
| No | string | Limit search to specific regions (e.g., "functions", "imports", "comments") |
Procedure
-
Define detection criteria: Clarify exactly what constitutes a positive detection
- Convert vague patterns to concrete search terms or regex
- Establish minimum evidence threshold for positive detection
-
Scan target systematically: Search the target data for matching signals
- Use Grep for text patterns with appropriate flags (-i for case-insensitive, etc.)
- Use Read for structural inspection when pattern requires context
- Record location (file:line) for each potential match
-
Evaluate signal strength: For each match, assess how strongly it indicates true presence
- Strong: exact match with clear context
- Medium: partial match or ambiguous context
- Weak: possible match requiring human verification
-
Assess false positive risk: Determine likelihood that detections are spurious
- High risk: generic patterns, noisy data, few matches
- Low risk: specific patterns, clean data, multiple corroborating signals
-
Ground claims: Attach evidence anchors to all detection signals
- Format:
for file-based targetsfile:line - Include snippet of matched content for verification
- Format:
-
Format output: Structure results according to the output contract below
Output Contract
Return a structured object:
detected: boolean # True if pattern/entity was found target_type: string # What was being detected (e.g., "security vulnerability", "deprecated API") signals: - signal: string # Description of what was found strength: low | medium | high # Signal strength location: string # file:line or path where found false_positive_risk: low | medium | high # Likelihood of spurious detection confidence: number # 0.0-1.0 based on evidence quality evidence_anchors: array[string] # File:line references assumptions: array[string] # Explicit assumptions made next_actions: array[string] # 0-3 suggested follow-ups if uncertain
Field Definitions
| Field | Type | Description |
|---|---|---|
| boolean | True if the target pattern/entity was found |
| string | Category of what was searched for |
| array | List of individual detection signals with strength |
| enum | Assessment of detection reliability |
| number | 0.0-1.0 based on evidence completeness |
| array[string] | File:line references or tool outputs |
| array[string] | Explicitly stated assumptions |
Examples
Example 1: Detect SQL Injection Vulnerability
Input:
target: src/api/user_controller.py pattern: "SQL injection pattern" threshold: min_matches: 1
Output:
detected: true target_type: "SQL injection vulnerability" signals: - signal: "String concatenation in SQL query with user input" strength: high location: "src/api/user_controller.py:47" - signal: "Raw SQL execution without parameterization" strength: medium location: "src/api/user_controller.py:52" false_positive_risk: low confidence: 0.85 evidence_anchors: - "src/api/user_controller.py:47" - "src/api/user_controller.py:52" assumptions: - "User input flows from request.params to query variable" - "No input sanitization in calling function" next_actions: - "Verify data flow from user input to SQL query" - "Check for parameterized query alternatives in codebase"
Evidence pattern: Grep for SQL keywords combined with string formatting patterns, then Read to verify context.
Example 2: Detect Deprecated API Usage
Input:
target: src/ pattern: "componentWillMount|componentWillReceiveProps" scope: "*.jsx,*.tsx"
Output:
detected: true target_type: "deprecated React lifecycle method" signals: - signal: "componentWillMount usage" strength: high location: "src/components/Dashboard.jsx:23" false_positive_risk: low confidence: 0.95 evidence_anchors: - "src/components/Dashboard.jsx:23" assumptions: - "Project uses React 16.3+ where these methods are deprecated" next_actions: - "Migrate to componentDidMount or useEffect hook"
Verification
- Output contains
boolean matching signal presencedetected - At least one evidence anchor exists for positive detections
- Confidence score correlates with number and strength of signals
- All referenced file:line locations are valid and accessible
- False positive risk assessment is justified
Verification tools: Read (to verify file:line references exist)
Safety Constraints
: falsemutation
: falserequires_checkpoint
: falserequires_approval
: lowrisk
Capability-specific rules:
- Do not access paths outside the specified target scope
- Do not modify any files during detection
- Stop and request clarification if detection criteria are ambiguous
- Report uncertainty rather than guessing when signals are weak
Composition Patterns
Commonly follows:
- Detection often follows initial observation of a systeminspect
- Detection may refine broad search resultssearch
Commonly precedes:
- Positive detection often leads to classification of what was foundidentify
- Detection of anomalies feeds into risk assessmentestimate-risk
- Detected issues may trigger remediation planningplan
Anti-patterns:
- Never use detect for complex entity classification (use
instead)identify - Avoid detect for quantitative assessment (use
instead)estimate
Workflow references:
- See
for detection in risk workflowsreference/composition_patterns.md#risk-assessment - See
for detection in agentic loopsreference/composition_patterns.md#observe-model-act