EAA Label Taxonomy

Overview

This skill provides the label taxonomy relevant to the Architect Agent (EAA) role. Each role plugin has its own label-taxonomy skill covering the labels that role manages.

Prerequisites

1. •GitHub CLI (gh) installed and authenticated
2. •Active issue number for architecture work
3. •Understanding of EAA role responsibilities (see AGENT_OPERATIONS.md)
4. •Completed architecture analysis for the feature

Instructions

1. •Analyze requirements to identify all affected components
2. •Review priority labels to understand design constraints
3. •Check effort labels against design complexity
4. •Recommend component labels based on module breakdown
5. •Create sub-issues with appropriate type and component labels
6. •Validate effort estimates and recommend changes if needed

Checklist

Copy this checklist and track your progress:

Architecture Label Workflow:

• • Analyze requirements to identify all affected components
• • Review priority labels to understand design constraints
• • Check effort labels against design complexity
• • Recommend component labels based on module breakdown
• • Create sub-issues with appropriate type and component labels
• • Validate effort estimates and recommend changes if needed
• • Add component labels to parent issue (e.g., component:api, component:database)
• • If effort needs adjustment, update effort label (e.g., effort:s → effort:m)

Architecture Handoff Checklist:

• • Ensure all component:* labels are set
• • Ensure effort:* is validated and correct
• • Create sub-issues if type:epic
• • Document component breakdown in handoff to EOA

Output

Error Handling

Labels EAA Manages

Component Labels (component:*)

EAA recommends component labels during architecture design.

EAA Component Responsibilities:

• •Analyze requirements to identify affected components
• •Recommend component labels in handoff to EOA
• •Update component labels when design changes

Type Labels EAA Clarifies

EAA may recommend type changes based on architecture analysis:

Labels EAA Reads (Set by Others)

Priority Labels (priority:*)

EAA uses priority to scope architecture:

• •priority:critical - Minimal viable design, fastest path
• •priority:high - Solid design, balance speed/quality
• •priority:normal - Full architecture consideration
• •priority:low - Can consider future extensibility

Effort Labels (effort:*)

EAA validates effort estimates:

• •Does design complexity match effort label?
• •Should effort:m be upgraded to effort:l?
• •EAA recommends effort changes to EOA

EAA Label Commands

When Completing Architecture

# Add component labels based on analysis
gh issue edit $ISSUE_NUMBER --add-label "component:api" --add-label "component:database"

# If effort estimate needs adjustment
gh issue edit $ISSUE_NUMBER --remove-label "effort:s" --add-label "effort:m"

When Creating Sub-Issues

# Create component-specific sub-issues
gh issue create \
  --title "[$PARENT_ID] API changes for $FEATURE" \
  --body "Part of #$PARENT_ISSUE" \
  --label "type:feature" \
  --label "component:api" \
  --label "status:backlog"

When Design Changes Scope

# Update type if scope changed during design
gh issue edit $ISSUE_NUMBER --remove-label "type:feature" --add-label "type:epic"

# Create child issues for the epic

Architecture-to-Labels Mapping

Module Breakdown → Component Labels

When EAA breaks down a feature:

## Architecture Breakdown

### Feature: User Authentication

**Components Affected:**
- API layer (new endpoints) → `component:api`
- Database (user schema) → `component:database`
- Auth module (new) → `component:auth`
- UI (login form) → `component:ui`

**Recommended Labels:**
- `component:api`
- `component:database`
- `component:auth`
- `component:ui`

Complexity Analysis → Effort Labels

Examples

Example 1: Adding Component Labels After Architecture Analysis

# Scenario: Issue #123 requires API endpoint and database schema changes
# Action: Add component labels based on architecture breakdown
gh issue edit 123 --add-label "component:api" --add-label "component:database"
# Result: Issue now tagged with all affected components

Example 2: Validating Effort Estimate

# Scenario: Issue #123 labeled effort:s but architecture reveals 3 components
# Action: Recommend effort upgrade
gh issue comment 123 --body "Architecture analysis suggests effort:m (3 components: API, DB, Auth)"
gh issue edit 123 --remove-label "effort:s" --add-label "effort:m"
# Result: Effort estimate now matches architecture complexity

Example 3: Creating Component-Specific Sub-Issues

# Scenario: Issue #123 is complex, needs breakdown
# Action: Create sub-issues for each component
gh issue create \
  --title "[#123] API endpoints for user authentication" \
  --body "Part of #123 - Implements REST API for auth flow" \
  --label "type:feature" \
  --label "component:api" \
  --label "status:backlog" \
  --label "effort:s"
# Repeat for database and auth components
# Result: Epic decomposed into manageable sub-issues

Example 4: Architecture Decision Record (ADR)

# Scenario: Major architecture decision needs documentation
# Action: Create ADR issue with appropriate labels
gh issue create \
  --title "[ADR-005] PostgreSQL vs MongoDB for user storage" \
  --body "Evaluating database options..." \
  --label "type:docs" \
  --label "component:database" \
  --label "priority:high"
# Result: ADR tracked and linked to affected component

Quick Reference

EAA Label Responsibilities

Labels EAA Never Sets

• •assign:* - Set by EOA/ECOS
• •status:* - Set by working agent
• •review:* - Managed by EIA
• •priority:* - Set by EAMA/EOA

EAA Handoff Labels

When handing off design to EOA, EAA should ensure:

1. •All component:* labels are set
2. •effort:* is validated
3. •Sub-issues created if type:epic

ADR Labels Pattern

When creating Architecture Decision Records:

# Create ADR-related issue
gh issue create \
  --title "[ADR-001] Database choice for user storage" \
  --body "Architecture decision record..." \
  --label "type:docs" \
  --label "component:database" \
  --label "priority:high"

Resources

• •AGENT_OPERATIONS.md - EAA role definition and responsibilities
• •eaa-modularization - Module breakdown procedures