issue-classification

What this skill does

# Issue Classification

Guide for configuring automatic classification of issues into problem classes.

## When to Use

- Setting up ADW issue routing
- Improving classification accuracy
- Handling edge cases in classification
- Designing custom problem classes

## Why Classification Matters

Classification routes issues to the correct template:

```text
Issue: "Login button not working"
  ↓
Classification: /bug
  ↓
Template: Bug fix plan with root cause analysis
```

Without classification, agents don't know which workflow to use.

## Standard Problem Classes

### Chore

Maintenance tasks, updates, cleanup:

```text
Examples:
- "Update dependencies to latest"
- "Clean up unused imports"
- "Rename function to follow convention"
- "Add missing documentation"

Signals:
- "update", "upgrade", "clean", "remove", "rename"
- "documentation", "comment", "format"
- No user-facing change
- Maintenance in nature
```

### Bug

Defects, errors, unexpected behavior:

```text
Examples:
- "Login form submits twice"
- "404 error on profile page"
- "Data not saving correctly"
- "Crash when clicking button"

Signals:
- "error", "bug", "fix", "broken", "crash"
- "not working", "fails", "incorrect"
- Something that worked before now doesn't
- Unexpected behavior
```

### Feature

New functionality, enhancements:

```text
Examples:
- "Add dark mode toggle"
- "Implement user authentication"
- "Create new dashboard page"
- "Add export to CSV"

Signals:
- "add", "create", "implement", "new"
- "enhance", "improve", "extend"
- User-facing new capability
- Didn't exist before
```

## Classification Command

### Basic Structure

```markdown
# Issue Classification

Analyze the issue and respond with exactly one of:
- `/chore` - maintenance, updates, cleanup
- `/bug` - defects, errors, unexpected behavior
- `/feature` - new functionality, enhancements

If the issue doesn't fit any category, respond with `0`.

## Issue
$ARGUMENTS
```

### Enhanced with Examples

```markdown
# Issue Classification

Classify the GitHub issue into one of these categories.

## Categories

### /chore
- Maintenance and cleanup tasks
- Dependency updates
- Refactoring without behavior change
- Documentation improvements

Examples: "update deps", "clean up code", "rename variables"

### /bug
- Something broken that should work
- Errors, crashes, incorrect behavior
- Regressions from previous functionality

Examples: "button doesn't work", "error on page", "crash when..."

### /feature
- New functionality
- Enhancements to existing features
- User-facing improvements

Examples: "add dark mode", "create API endpoint", "implement..."

## Rules
1. Respond with exactly one: /chore, /bug, /feature, or 0
2. If unclear, prefer /chore (safest default)
3. If multiple types, choose the primary purpose

## Issue
$ARGUMENTS
```

## Classification Accuracy

### Testing Classification

```bash
# Test chores
claude -p "/classify-issue 'Update all dependencies'"
# Expected: /chore

claude -p "/classify-issue 'Clean up unused imports'"
# Expected: /chore

# Test bugs
claude -p "/classify-issue 'Login form submits twice on enter'"
# Expected: /bug

claude -p "/classify-issue '404 error on profile page'"
# Expected: /bug

# Test features
claude -p "/classify-issue 'Add dark mode toggle'"
# Expected: /feature

claude -p "/classify-issue 'Implement OAuth with Google'"
# Expected: /feature
```

### Handling Edge Cases

**Multi-type issues:**

```text
"Fix the broken login AND add remember me feature"

Approach: Classify by primary purpose
If equal: Request issue be split
```

**Unclear issues:**

```text
"Improve the performance"

Approach: Default to /chore
Rationale: Safest, lowest risk
```

**Not classifiable:**

```text
"Question about the API"

Approach: Return 0
Action: Human triage required
```

## Custom Problem Classes

For specialized workflows, extend the base classes:

### Example: Refactor Class

```markdown
### /refactor
- Code restructuring
- Architecture changes
- Performance optimization
- No functional change

Examples: "refactor auth module", "optimize queries", "restructure..."
```

### Example: Security Class

```markdown
### /security
- Vulnerability fixes
- Security improvements
- Access control changes
- Compliance requirements

Examples: "fix XSS vulnerability", "add rate limiting", "update auth..."
```

## Integration with ADW

In your ADW orchestrator:

```python
def classify_and_route(issue):
    # Classify
    result = execute_agent("classifier", issue)
    issue_type = parse_classification(result)

    # Route to template
    if issue_type == "/chore":
        return execute_agent("planner", "/chore", issue)
    elif issue_type == "/bug":
        return execute_agent("planner", "/bug", issue)
    elif issue_type == "/feature":
        return execute_agent("planner", "/feature", issue)
    else:
        return mark_for_triage(issue)
```

## Model Selection

For classification, use Haiku:

| Model | Speed | Cost | Accuracy |
| --- | --- | --- | --- |
| Haiku | Fast | Low | Good for simple decisions |
| Sonnet | Medium | Medium | Better for nuanced cases |

Haiku is usually sufficient since classification is a simple decision.

## Quality Metrics

Track classification quality:

- **Accuracy**: % correctly classified
- **Confusion matrix**: Which misclassifications happen
- **Override rate**: How often humans change classification

## Related Memory Files

- @piter-framework.md - Classification is the "I" in PITER
- @adw-anatomy.md - How classification fits in ADW
- @template-engineering.md - Templates for each class

## Version History

- **v1.0.0** (2025-12-26): Initial release

---

## Last Updated

**Date:** 2025-12-26
**Model:** claude-opus-4-5-20251101