issue-classification

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:

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:

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:

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:

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

# 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

# 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

# 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:

"Fix the broken login AND add remember me feature"

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

Unclear issues:

"Improve the performance"

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

Not classifiable:

"Question about the API"

Approach: Return 0
Action: Human triage required

Custom Problem Classes

For specialized workflows, extend the base classes:

Example: Refactor Class

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

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

Example: Security Class

### /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:

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