| name | input-classification-system |
| description | Deterministic rule-based system for classifying clarified input into a single primary task category and assigning execution complexity. Use when the Main Agent needs to categorize user requests before task decomposition, route tasks to appropriate handlers, assess complexity and risk levels, or determine if clarification is needed. Triggers after clarification is complete and before decomposition begins. |
Input Classification System
1. Skill Name
Input Classification System
Identifier: input-classification-system
2. Version
1.0
This is the initial release of the Input Classification System skill.
3. Skill Purpose
Provide a deterministic, rule-based classification system that enables the Main Agent to categorize clarified user input into exactly one primary task category, assign execution complexity, assess risk level, and determine confidence score before any task decomposition or execution planning occurs.
Measurable Objectives:
- Achieve 100% single-category classification (no ambiguous multi-category outputs)
- Provide deterministic tie-breaking for all edge cases
- Assign complexity levels using measurable thresholds
- Calculate confidence scores with explicit formulas
- Route ambiguous inputs to clarification with specific triggers
4. What This Skill Does
- Classifies clarified input into exactly one primary category from a fixed list
- Assigns complexity level based on measurable operation counts and time estimates
- Calculates risk level based on impact scope and reversibility criteria
- Computes confidence score using explicit scoring factors
- Determines if input requires additional clarification
- Sets the appropriate state transition after classification
- Applies deterministic tie-breaking logic when multiple categories match
- Validates that input has been clarified before classification
- Logs all classification decisions with full context
- Provides secondary tags for additional context (maximum 3)
- Enforces boundary definitions between categories
- Triggers escalation for high-risk or low-confidence classifications
- Prevents misclassification through explicit rules
- Outputs structured ClassificationResult for downstream systems
- Maintains audit trail for all classification decisions
5. What This Skill Must Not Do
- Must not perform task decomposition or breakdown
- Must not solve or execute any tasks
- Must not create execution plans or strategies
- Must not apply emotional reasoning or sentiment analysis
- Must not assign multiple primary categories to a single input
- Must not overlap with Clarification System responsibilities
- Must not modify the original input content
- Must not make assumptions about user intent without explicit indicators
- Must not skip complexity assessment for any classification
- Must not bypass risk assessment for any classification
- Must not assign confidence scores below threshold without escalation
- Must not classify inputs that have not been clarified first
- Must not use probabilistic or non-deterministic classification methods
- Must not ignore tie-breaking rules when categories conflict
- Must not proceed to execution without setting state transition
6. Activation Conditions
This skill activates when ALL of the following conditions are met:
- Clarification Complete: Input has been processed by the Clarification System and marked as clarified
- No Pending Questions: No outstanding clarification questions remain
- Classification Not Yet Performed: Input has not been previously classified
- Valid Input Structure: Input contains recognizable task indicators
Pre-Activation Checklist:
Do NOT activate if:
- Input is still being clarified
- Input is a clarification question itself
- Input is a response to a clarification question
- Input has already been classified
7. Classification Categories
The following 15 categories form the fixed classification list:
| Category | Code | Description |
|---|
| CODE_GENERATION | CG | Writing, modifying, or generating source code |
| CODE_REVIEW | CR | Reviewing, analyzing, or auditing existing code |
| DEBUGGING | DB | Identifying and fixing bugs, errors, or issues |
| DATA_ANALYSIS | DA | Analyzing, processing, or visualizing data |
| FILE_OPERATIONS | FO | Reading, writing, moving, or managing files |
| DOCUMENTATION | DC | Creating or updating documentation |
| REFACTORING | RF | Restructuring code without changing behavior |
| TESTING | TS | Writing, running, or managing tests |
| DEPLOYMENT | DP | Deploying applications or infrastructure |
| RESEARCH | RS | Investigating, searching, or gathering information |
| CONFIGURATION | CF | Setting up or modifying configurations |
| COMMUNICATION | CM | Drafting messages, emails, or communications |
| CONVERSION | CV | Transforming data or files between formats |
| ANALYSIS | AN | General analysis not covered by other categories |
| PLANNING | PL | Creating plans, strategies, or roadmaps |
Category Priority Order (for tie-breaking):
- DEBUGGING (highest - immediate attention needed)
- DEPLOYMENT
- CODE_GENERATION
- REFACTORING
- TESTING
- CODE_REVIEW
- DATA_ANALYSIS
- CONFIGURATION
- FILE_OPERATIONS
- CONVERSION
- DOCUMENTATION
- RESEARCH
- ANALYSIS
- COMMUNICATION
- PLANNING (lowest)
8. Category Boundary Definitions
CODE_GENERATION vs CODE_REVIEW
- CODE_GENERATION: Input requests creating new code or modifying existing code
- CODE_REVIEW: Input requests analysis of existing code without modifications
- Boundary: If modification is implied, classify as CODE_GENERATION
CODE_GENERATION vs REFACTORING
- CODE_GENERATION: Creating new functionality or features
- REFACTORING: Restructuring existing code without new functionality
- Boundary: "Improve performance" without feature change = REFACTORING
DEBUGGING vs CODE_GENERATION
- DEBUGGING: Input explicitly mentions errors, bugs, or failures
- CODE_GENERATION: Input requests new features without error context
- Boundary: "Fix this bug" = DEBUGGING; "Add error handling" = CODE_GENERATION
DATA_ANALYSIS vs ANALYSIS
- DATA_ANALYSIS: Input involves data processing, statistics, or visualization
- ANALYSIS: Input involves general analysis of concepts, requirements, or situations
- Boundary: If data files/sets are mentioned = DATA_ANALYSIS
FILE_OPERATIONS vs CONVERSION
- FILE_OPERATIONS: Input requests file management (read, write, move, delete)
- CONVERSION: Input requests format transformation between file types
- Boundary: "Convert X to Y format" = CONVERSION; "Read file X" = FILE_OPERATIONS
RESEARCH vs ANALYSIS
- RESEARCH: Input requests information gathering or investigation
- ANALYSIS: Input requests evaluation or assessment of known information
- Boundary: "Find information about X" = RESEARCH; "Evaluate X" = ANALYSIS
TESTING vs CODE_GENERATION
- TESTING: Input specifically requests test creation or test execution
- CODE_GENERATION: Input requests production code
- Boundary: "Write tests for X" = TESTING; "Write X with tests" = CODE_GENERATION (primary)
CONFIGURATION vs DEPLOYMENT
- CONFIGURATION: Input requests setup of settings or configurations
- DEPLOYMENT: Input requests deployment to environments or infrastructure
- Boundary: Local setup = CONFIGURATION; Remote/environment setup = DEPLOYMENT
9. Single-Primary-Category Rule
Rule: Every classified input MUST have exactly one primary category.
Enforcement Rules
- No Multi-Category Output: Never output multiple primary categories
- Tie-Breaking Required: When multiple categories match, apply tie-breaking logic
- Category Exclusivity: Primary category is mutually exclusive with other primary categories
Tie-Breaking Logic
When input matches multiple categories, apply in order:
Step 1: Keyword Dominance
- Count explicit keyword matches for each candidate category
- Category with highest keyword count wins
- If tied, proceed to Step 2
Step 2: Action Verb Analysis
- Identify primary action verb in input
- Map action verb to category using verb-to-category mapping
- If still tied, proceed to Step 3
Step 3: Priority Order
- Apply category priority order (see Section 7)
- Higher priority category wins
Step 4: Default Fallback
- If all steps fail, default to ANALYSIS category
Tie-Breaking Example
Input: "Debug and fix the error in the authentication code, then add logging"
- Keywords: DEBUGGING (debug, fix, error), CODE_GENERATION (add, logging)
- Action Verb: "Debug" (primary action) → DEBUGGING
- Result: DEBUGGING (primary), secondary_tags: [CODE_GENERATION]
10. Secondary Tag Rules
Secondary tags provide additional context without affecting primary routing.
Rules
- Maximum 3 Tags: No more than 3 secondary tags per classification
- No Primary Duplicate: Secondary tags cannot duplicate primary category
- Related Categories Only: Secondary tags must be from the fixed category list
- Relevance Threshold: Only add tags with >50% keyword match confidence
Secondary Tag Selection Process
- Identify all categories with keyword matches (excluding primary)
- Calculate relevance score for each (0.0-1.0)
- Sort by relevance score (descending)
- Select top 3 with score > 0.5
- Add to ClassificationResult
When to Apply Secondary Tags
- Input contains multiple distinct sub-tasks
- Input references multiple technology domains
- Input implies follow-up work in other categories
- Input has context from previous interactions in different categories
When NOT to Apply Secondary Tags
- Input is single-focused with no additional context
- Relevance scores are below threshold (0.5)
- Would duplicate primary category
- Would exceed 3-tag limit
Secondary Tag Examples
| Input | Primary | Secondary Tags |
|---|
| "Debug the API and update the docs" | DEBUGGING | [DOCUMENTATION] |
| "Refactor the auth module and add tests" | REFACTORING | [TESTING] |
| "Analyze sales data and create a report" | DATA_ANALYSIS | [DOCUMENTATION, COMMUNICATION] |
| "Fix this bug" | DEBUGGING | [] |
Classification Models Reference
For detailed complexity, risk, confidence, and state transition models, see classification-models.md.
For system integration, failure conditions, logging, and examples, see system-integration.md.
