---
roadcrew_template_name: "classify-feedback.md"
roadcrew_template_type: "command"
execution_mode: "auto-execute"
roadcrew_template_version: "v1.0"
roadcrew_last_updated: "2025-10-25"
roadcrew_min_version: "1.5.0"
roadcrew_license: "See LICENSE file in .roadcrew folder"
roadcrew_copyright: "Copyright (c) 2025 North Star Holdings, LLC"
spdx_license_identifier: "LicenseRef-RoadcrewLicense-1.0"
---

# classify-feedback

<!-- Usage: /classify-feedback [--repo https://github.com/org/repo] -->

You are analyzing and classifying user feedback to create structured, prioritized roadmap items.

**Standalone Mode Support:** If --repo flag provided, use that repo for analysis and look for config in config/repos/org-repo/. If no --repo flag, use current repo (integrated mode).

MANDATORY CURSORRULES COMPLIANCE: Reference @.cursorrules.md throughout this work.

## Overview

This command analyzes raw feedback and classifies it into:
- **Type A (Surgical Updates)**: Bug fixes, performance, usability, small functionality enhancements → `memory-bank/releases/minor-release.md`
- **Type B (Strategic Features)**: New use cases, architectural changes, major features → `memory-bank/releases/future-releases.md`

## Workflow

### 0. CONTEXT REVIEW

- Review @.cursorrules.md (coding standards, workflow preferences)
- Review @classify-feedback.md (this file - classification steps)
- Review @memory-bank/techContext.md (project type, architecture, deployment)

### 1. LOCATE & READ FEEDBACK

**Sources** (check all that exist):
- `docs/feedback/feedback-YYYY-MM-DD.md` (automated collection - future)
- `docs/minor-release-feedback.md` (manual collection - current)
- Any other `docs/feedback/*.md` files

**If no feedback found:**
- Display: "No feedback files found. Please create feedback in `docs/minor-release-feedback.md` or `docs/feedback/` before running /classify-feedback."
- STOP

**Extract from feedback:**
- Application areas (e.g., "Epic Analysis", "Issue Management", "Template Generation")
- Current implementation issues (bugs, performance, UX)
- Feature requests (improvements, new functionality)
- Source/context (who provided feedback, when)

### 2. ANALYZE CURRENT IMPLEMENTATION

**Understand the codebase:**
- Search for relevant files/functions mentioned in feedback
- Identify affected components
- Assess current architecture
- Note technical debt or constraints

**Reference product context:**
- Review `memory-bank/activeContext.md` for product strategy
- Review `memory-bank/requirements/specs/*.md` for technical specifications
- Ensure feedback aligns with product vision and strategic position
- Use vision to inform Type B (Strategic) classification

**Use codebase search:**
```
How does [feature mentioned in feedback] work?
Where is [component mentioned in feedback] implemented?
```

**Document findings:**
- Current implementation approach
- Complexity level
- Dependencies
- Technical debt

### 3. REVIEW RELEASE CONTEXT

**Read milestone files:**
- `memory-bank/releases/current-release.md` - Current major release scope
- `memory-bank/releases/minor-release.md` - Current minor release items
- `memory-bank/releases/future-releases.md` - Existing future epics

**Understand:**
- What's already planned
- What's in progress
- Version strategy
- Existing epic structures

### 4. CLASSIFY FEEDBACK ITEMS

For each feedback item, determine:

**Type A - Surgical Updates** (→ `minor-release.md`)
Characteristics:
- ✅ Fixes bugs or issues in existing features
- ✅ Improves performance of existing functionality
- ✅ Enhances usability without changing core behavior
- ✅ Small functionality additions (< 1 day implementation)
- ✅ Low risk, isolated changes
- ✅ No architectural changes
- ✅ Doesn't introduce new use cases

Examples:
- "Fix error message formatting in /analyze-epic"
- "Improve performance of template parsing"
- "Add validation for missing parameters"
- "Better error handling for GitHub API failures"

**Type B - Strategic Features** (→ `future-releases.md`)
Characteristics:
- ✅ Enables new use cases or workflows
- ✅ Requires architectural changes
- ✅ Major features (> 1 day implementation)
- ✅ Cross-cutting concerns (affects multiple components)
- ✅ Medium-to-high risk changes
- ✅ Introduces new capabilities
- ✅ May have breaking changes

Examples:
- "Add support for multi-repo operations"
- "Integrate AI for automatic PR review"
- "Build dashboard for roadmap visualization"
- "Add automated testing framework"

### 5. GROUP INTO EPICS

Uses `scripts/utils/issue-classification.ts` for epic grouping rules:

**For Type A items** (minor release):
- Group related items together
- Max 7 issues per epic (best practice)
- Create epic if 2+ related items
- If 1 item, keep as standalone issue

**For Type B items** (future releases):
- Group by strategic theme or use case
- Max 7 issues per epic
- Consider dependencies between epics
- Think in terms of phases

**Epic naming:**
- Type A: "[Epic] [Area] Improvements" (e.g., "Error Handling Improvements")
- Type B: "[Epic] [Feature Name]" (e.g., "Multi-Repo Support")

### 6. SEQUENCE EPICS

**Order epics by:**
1. **Dependencies** - Foundational features first
2. **User value** - High-impact items earlier
3. **Risk** - Balance high-risk and low-risk items
4. **Feasibility** - Quick wins vs. long-term projects

**For Type A** (minor release):
- Bug fixes before enhancements
- Critical issues before nice-to-haves

**For Type B** (future releases):
- Infrastructure before features that depend on it
- Core features before extensions
- Phase 1 → Phase 2 → Phase 3

### 7. GENERATE STRUCTURED RECOMMENDATIONS

Present analysis in this format:

```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 FEEDBACK CLASSIFICATION REPORT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Feedback Sources Analyzed:**
- [List sources with dates]

**Total Feedback Items:** X
- Type A (Surgical): Y items
- Type B (Strategic): Z items

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TYPE A - SURGICAL UPDATES (→ minor-release.md)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Epic 1: [Epic Name]** (Y issues)
Rationale: [Why these items are grouped, why they're Type A]

1. [Issue Title]
   - **Feedback**: [Original feedback quote]
   - **Current Implementation**: [What exists today]
   - **Proposed Change**: [What to do]
   - **Effort**: [X hours]
   - **Classification**: [1-3] (ai-solo)

[Continue for all Type A items...]

**Standalone Issues** (not in epics):
- [Issue Title] - [Brief description]

**Recommended Sequence:**
1. Epic 1: [Name] - [Rationale for order]
2. Epic 2: [Name] - [Rationale for order]
3. Standalone issues

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TYPE B - STRATEGIC FEATURES (→ future-releases.md)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Phase X: [Phase Name]**

**Epic 1: [Epic Name]** (Y issues)
Rationale: [Why these items are grouped, why they're Type B]

1. [Issue Title]
   - **Feedback**: [Original feedback quote]
   - **Use Case**: [What new capability this enables]
   - **Proposed Approach**: [High-level design]
   - **Effort**: [X-Y hours]
   - **Classification**: [4-6] (ai-led)

[Continue for all Type B items...]

**Dependencies:**
- Epic A depends on Epic B because [reason]

**Recommended Sequence:**
1. Phase X: [Name] - [Rationale]
2. Phase Y: [Name] - [Rationale]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CLASSIFICATION RATIONALE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Type A Items:**
[Explain why items were classified as Type A]
- [Reasoning for specific items if needed]

**Type B Items:**
[Explain why items were classified as Type B]
- [Reasoning for specific items if needed]

**Epic Grouping:**
[Explain grouping strategy]
- Max 7 issues per epic (best practice)
- [Other grouping rationale]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### 8. REQUEST APPROVAL

Display:
```
Ready to update milestone files with this classification?

Changes:
- Update memory-bank/releases/minor-release.md with [X] Type A items
- Update memory-bank/releases/future-releases.md with [Y] Type B items

Type 'approve' to proceed, or provide feedback for adjustments.
```

**Wait for user approval before proceeding.**

### 9. UPDATE MILESTONE FILES

**Only after approval**, update the milestone files:

#### A) Update `memory-bank/releases/minor-release.md`

**Structure:**
```markdown
# Minor Release

## Epics

### [Epic] [Epic Name]

**Rationale**: [Why these items are grouped]

**Issues:**

1. **[Issue Title]**
   - **Problem**: [Description of issue/need]
   - **Current Implementation**: [What exists today]
   - **Proposed Change**: [What to do]
   - **Acceptance Criteria**:
     - [ ] [Criterion 1]
     - [ ] [Criterion 2]
   - **Effort**: [X hours]
   - **Classification**: [1-3] (ai-solo)

[Continue for all issues in epic...]

### [Epic] [Next Epic Name]

[Continue for all epics...]

## Standalone Issues

1. **[Issue Title]**
   [Same structure as above]

[Continue for standalone issues...]
```

#### B) Update `memory-bank/releases/future-releases.md`

**Structure:**
```markdown
# Future Releases

## Phase X: [Phase Name]

**Timeline**: [Estimated timeframe]
**Prerequisites**: [Dependencies or blockers]

### Epics

#### [Epic] [Epic Name]

**Rationale**: [Why this epic, what use cases it enables]

**Issues:**

1. **[Issue Title]**
   - **Use Case**: [What new capability this enables]
   - **Proposed Approach**: [High-level design]
   - **Acceptance Criteria**:
     - [ ] [Criterion 1]
     - [ ] [Criterion 2]
   - **Effort**: [X-Y hours]
   - **Classification**: [4-6] (ai-led)

[Continue for all issues...]

### Dependencies

- [Dependency description]

## Phase Y: [Next Phase Name]

[Continue for future phases...]
```

### 10. DISPLAY SUMMARY

After updates complete:

```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ FEEDBACK CLASSIFICATION COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**Updated Files:**
- ✅ memory-bank/releases/minor-release.md ([X] items added)
- ✅ memory-bank/releases/future-releases.md ([Y] items added)

**Type A - Minor Release:**
- [X] total items
- [Y] epics created
- [Z] standalone issues

**Type B - Future Releases:**
- [X] total items
- [Y] epics created
- [Z] phases affected

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NEXT STEPS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. **Review** the updated milestone files
2. **Edit** as needed (refine descriptions, adjust priorities)
3. **Run** `/scope-release --minor` to create GitHub issues for Type A items
4. **Run** `/scope-release --future` to create GitHub epics for Type B items (when ready)

Ready to run /scope-release to create GitHub issues?
```

## Classification Guidelines

### Type A vs Type B Decision Framework

Ask these questions:

1. **Does it fix vs. create?**
   - Fixes existing functionality → Type A
   - Creates new functionality → Type B

2. **How much code changes?**
   - Single file or isolated changes (classification 1-3) → Type A
   - Multiple files or architectural changes (classification 4-10) → Type B

3. **What's the classification level?**
   - ai-solo (1-3), well-understood → Type A
   - ai-led/ai-assisted/ai-limited (4-10), requires design → Type B

4. **How long will it take?**
   - < 1 day (classification 1-3) → Type A
   - > 1 day (classification 4-10) → Type B

5. **Does it enable new use cases?**
   - No, improves existing (classification 1-3) → Type A
   - Yes, enables new workflows (classification 4-10) → Type B

### When in Doubt

Default to **Type B** for:
- Anything requiring external APIs
- Anything requiring new dependencies
- Anything requiring database changes
- Anything affecting multiple areas

Default to **Type A** for:
- Pure bug fixes
- Error message improvements
- Validation additions
- Performance optimizations (without changing behavior)

## Edge Cases

**Mixed feedback item** (has both Type A and Type B aspects):
- Split into two separate items
- Example: "Improve error handling (Type A) and add retry logic with exponential backoff (Type B)"

**Unclear classification**:
- Mark as Type B (safer)
- Add note: "Classification uncertain - review in context"

**Duplicate feedback**:
- Consolidate into single item
- Note all sources in description

**Out of scope feedback**:
- Create separate list: "Out of Scope Items"
- Document for future consideration
- Don't add to milestone files

## Behavior

- If invoked with trailing text, interpret as notes/context for classification
- Always present full analysis before requesting approval
- Never update files without explicit user approval
- Guide user to run `/scope-release` when ready
- Preserve existing content in milestone files (append, don't overwrite)

---

**Phase 1:** Command structure only (Markdown)
**Future Phases:** Automated collection (Epic #26)