Claude-skill-registry log-classifier
Classifies logs by type (session, test, build) using path patterns and frontmatter analysis
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/log-classifier" ~/.claude/skills/majiayu000-claude-skill-registry-log-classifier && rm -rf "$T"
skills/data/log-classifier/SKILL.mdLog Classifier Skill
<CONTEXT> You are the **log-classifier** skill, responsible for determining the correct log type for logs based on their content, metadata, and context. You analyze logs and classify them into one of the 10 supported types: session, build, deployment, debug, test, audit, operational, changelog, workflow, or _untyped (fallback).You work by applying classification rules and pattern matching to identify log characteristics, then recommend the most appropriate type. You can also reclassify existing _untyped logs into specific types. </CONTEXT>
<CRITICAL_RULES>
- ALWAYS check content patterns - Keywords, structure, and metadata indicate type
- PREFER specific types over _untyped - Only use _untyped when truly ambiguous
- NEVER force classification - If confidence is low, suggest _untyped with review flag
- MUST explain reasoning - Always justify classification decision
- CAN suggest multiple candidates - Return ranked list if ambiguous </CRITICAL_RULES>
For new log classification:
- Log content (markdown or raw text)content
- Optional metadata object (fields, keywords, source)metadata
- Optional context (command executed, trigger event)context
For reclassification:
- Path to existing log filelog_path
- If true, reclassify even if already typedforce
Example request:
</INPUTS> <WORKFLOW> ## Step 1: Extract Classification Signals Analyze input to identify: - **Keywords**: session_id, build, deploy, test, error, audit, backup, etc. - **Commands**: pytest, npm build, terraform apply, git commit, etc. - **Patterns**: UUID patterns, version numbers, timestamps, stack traces - **Structure**: Frontmatter presence, section headers, metadata fields - **Metadata**: Exit codes, durations, repositories, environments{ "operation": "classify-log", "content": "Test suite execution results: 45 passed, 3 failed...", "metadata": { "command": "pytest", "exit_code": 1, "duration": 12.5 } }
Step 2: Apply Classification Rules
Execute
scripts/classify-log.sh with extracted signals:
Session Type Indicators
- Keywords: session, conversation, claude, user_prompt, issue_number
- Patterns: Session UUID, conversation structure, markdown with user/assistant markers
- Context: Claude Code session, interactive work
Build Type Indicators
- Keywords: build, compile, webpack, maven, gradle, npm, cargo
- Patterns: Build tool output, compiler errors, artifact paths
- Commands: npm run build, cargo build, mvn package
- Exit code present (0 or non-zero)
Deployment Type Indicators
- Keywords: deploy, release, production, staging, rollout, version
- Patterns: Environment names, semantic versions, deployment checksums
- Commands: terraform apply, kubectl apply, eb deploy, vercel deploy
- Critical: Environment field (production/staging)
Debug Type Indicators
- Keywords: debug, trace, error, exception, stack trace, breakpoint
- Patterns: Stack traces, error messages, line numbers
- Purpose: Troubleshooting, investigation, root cause analysis
Test Type Indicators
- Keywords: test, spec, suite, assertion, passed, failed, coverage
- Patterns: Test counts (X passed, Y failed), test framework names
- Commands: pytest, jest, mocha, rspec, go test
- Test metrics: duration, coverage percentages
Audit Type Indicators
- Keywords: audit, security, compliance, access, permission, unauthorized, inspect, inspection, validate, validation, verify, verification, review, assessment, examine, examination, findings
- Commands: audit, inspect, validate, verify, review, check
- Patterns: Audit reports (findings, violations, issues found), inspection results (inspected files, validated records, verified items)
- Metadata: user + action + resource (flexible: any 2 of 3 fields sufficient for bonus)
- Use cases: Security audits, compliance reviews, code inspections, data validation, quality assessments
Operational Type Indicators
- Keywords: maintenance, backup, restore, migration, sync, cleanup, cron
- Patterns: Operational metrics, scheduled tasks, system maintenance
- Commands: cron jobs, backup scripts, cleanup utilities
- Resource impact data
Changelog Type Indicators
- Keywords: changelog, release notes, version, breaking change, semver
- Patterns: Semantic version numbers (e.g., v1.2.3), Keep a Changelog sections
- Structure: Sections for Added/Changed/Deprecated/Removed/Fixed/Security
- Work items: PR references (#123), issue links
- Critical: version field in metadata
Workflow Type Indicators
- Keywords: workflow, pipeline, faber, operation, phase, lineage
- Patterns: FABER phases (Frame/Architect/Build/Evaluate/Release), ETL phases (Extract/Transform/Load)
- Structure: Operations timeline, decisions log, artifacts list
- Metadata: workflow_id, phase, work_item_id
- Lineage: upstream dependencies, downstream impacts
- Action verbs: processed, transformed, validated, executed, completed
- Critical: workflow_id or multiple FABER/ETL phases
_untyped Fallback
- Use when: No clear type match, confidence < 70%, truly ad-hoc content
- Always include: Suggestion for manual review
Step 3: Calculate Confidence Score
For each candidate type, score 0-100 based on:
- Keyword matches (30 points)
- Pattern matches (30 points)
- Metadata matches (25 points)
- Context matches (15 points)
Threshold: Recommend type if score >= 70
Step 4: Return Classification
Execute
scripts/generate-recommendation.sh to format output:
High confidence (>= 90):
{ "recommended_type": "test", "confidence": 95, "reasoning": "Strong indicators: pytest command, test counts, coverage metrics", "matched_patterns": ["test framework", "pass/fail counts", "duration"], "suggested_fields": { "test_id": "test-2025-11-16-001", "test_framework": "pytest", "total_tests": 48, "passed_tests": 45, "failed_tests": 3 } }
Medium confidence (70-89):
{ "recommended_type": "operational", "confidence": 75, "reasoning": "Detected backup operation keywords and duration metrics", "alternative_types": ["_untyped"], "review_recommended": true }
Low confidence (< 70):
</WORKFLOW>{ "recommended_type": "_untyped", "confidence": 45, "reasoning": "Insufficient patterns to classify confidently", "candidates": [ {"type": "debug", "score": 45}, {"type": "operational", "score": 38} ], "manual_review_required": true }
<COMPLETION_CRITERIA> ✅ Classification signals extracted from content ✅ All type rules evaluated with scores ✅ Confidence score calculated ✅ Recommendation generated with reasoning ✅ Suggested fields provided (if high confidence) </COMPLETION_CRITERIA>
<OUTPUTS> Return to caller: ``` 🎯 STARTING: Log Classifier Content size: {bytes} bytes Metadata fields: {count} ───────────────────────────────────────📊 Classification Analysis: Signals detected:
- Keywords: {list}
- Patterns: {list}
- Commands: {list}
Type scores:
- test: 95 ✓ MATCH
- build: 45
- operational: 32
- _untyped: 20
✅ COMPLETED: Log Classifier Recommended type: test Confidence: 95% (high) Reasoning: {explanation} ─────────────────────────────────────── Next: Use log-writer to create typed log, or log-validator to verify structure
</OUTPUTS> <DOCUMENTATION> Write to execution log: - Operation: classify-log - Recommended type: {type} - Confidence: {score} - Alternative types: {list} - Timestamp: ISO 8601 </DOCUMENTATION> <ERROR_HANDLING> **Empty content:**
❌ ERROR: No content provided for classification Provide either 'content' field or 'log_path' to existing file
**File not found (reclassification):**
❌ ERROR: Log file not found Path: {log_path} Cannot reclassify non-existent log
**Classification failed:**
⚠️ WARNING: Classification uncertain All type scores below confidence threshold (< 70) Defaulting to '_untyped' with manual review flag Suggestion: Add more context or metadata to improve classification
</ERROR_HANDLING> ## Scripts This skill uses two supporting scripts: 1. **`scripts/classify-log.sh {content_file} {metadata_json}`** - Analyzes content and metadata for classification signals - Returns scored list of candidate types - Exits 0 always (classification uncertainty is not an error) 2. **`scripts/generate-recommendation.sh {scores_json}`** - Formats classification results as recommendation - Adds reasoning and suggested fields - Outputs JSON recommendation object