GitHub label taxonomy reference for the Architect Agent. Use when designing architecture, identifying components, or recommending labels. Trigger with architecture label requests.
npx claudepluginhub emasoft/emasoft-plugins --plugin emasoft-architect-agentThis skill uses the workspace's default tool permissions.
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.
Manages GitHub issue labels via gh CLI using AMOA taxonomy. Applies categories like assign:*, status:*, priority:* ensuring cardinality rules. Triggers on label queries or assignments.
Creates ADRs in MADR format, arc42 documentation, and plan-context.md for architecture proposals. Handles branch verification, GitHub issue/PR creation, artifact triage, and backlog updates.
Share bugs, ideas, or general feedback.
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.
gh) installed and authenticatedCopy this checklist and track your progress:
Architecture Label Workflow:
component:api, component:database)effort:s → effort:m)Architecture Handoff Checklist:
component:* labels are seteffort:* is validated and correcttype:epic| Output Type | Format | Example |
|---|---|---|
| Component recommendations | Issue comment | Affected components: api, database, auth |
| Label updates | CLI stdout | ✓ Labels updated for #456 |
| Sub-issue creation | Issue URL | Created #457 for API changes |
| Effort validation | Issue comment | Recommend upgrading effort:s → effort:m |
| Error | Cause | Solution |
|---|---|---|
label not found | Component label doesn't exist | Create label first via gh label create |
permission denied | No write access to repo | Verify GitHub token scopes |
issue not found | Invalid issue number | Verify issue number with gh issue list |
duplicate label | Label already applied | No action needed, continue |
component:*)EAA recommends component labels during architecture design.
| Label | Description | When EAA Recommends It |
|---|---|---|
component:api | API endpoints | Feature touches REST/GraphQL APIs |
component:ui | User interface | Feature has UI changes |
component:database | Database/storage | Schema or query changes |
component:auth | Authentication | Auth/authorization changes |
component:infra | Infrastructure | DevOps/deployment changes |
component:core | Core business logic | Central logic changes |
component:tests | Test infrastructure | Test framework changes |
component:docs | Documentation | Doc system changes |
EAA Component Responsibilities:
The full workflow uses these 8 status columns:
| # | Column Code | Display Name | Label | Description |
|---|---|---|---|---|
| 1 | backlog | Backlog | status:backlog | Entry point for new tasks |
| 2 | todo | Todo | status:todo | Ready to start |
| 3 | in-progress | In Progress | status:in-progress | Active work |
| 4 | ai-review | AI Review | status:ai-review | Integrator agent reviews ALL tasks |
| 5 | human-review | Human Review | status:human-review | User reviews BIG tasks only (via EAMA) |
| 6 | merge-release | Merge/Release | status:merge-release | Ready to merge |
| 7 | done | Done | status:done | Completed |
| 8 | blocked | Blocked | status:blocked | Blocked at any stage |
Task Routing Rules:
EAA may recommend type changes based on architecture analysis:
| Scenario | Type Recommendation |
|---|---|
| "Add feature" requires refactoring first | type:refactor for prep issue |
| Feature spans multiple systems | type:epic parent + type:feature children |
| Security implications discovered | Add type:security issue |
priority:*)EAA uses priority to scope architecture:
priority:critical - Minimal viable design, fastest pathpriority:high - Solid design, balance speed/qualitypriority:normal - Full architecture considerationpriority:low - Can consider future extensibilityeffort:*)EAA validates effort estimates:
effort:m be upgraded to effort:l?# 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"
# 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"
# 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
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`
| Architecture Complexity | Effort Recommendation |
|---|---|
| Single component, clear pattern | effort:s |
| 2-3 components, existing patterns | effort:m |
| Multiple components, new patterns | effort:l |
| System-wide, new architecture | effort:xl |
# 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
# 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
# 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
# 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
| Action | Labels Involved |
|---|---|
| Analyze requirements | Read type:*, priority:* |
| Identify components | Recommend component:* |
| Validate effort | Recommend effort:* changes |
| Create sub-issues | Set type:*, component:*, status:backlog |
| Design change | May update type:* (with EOA approval) |
assign:* - Set by EOA/ECOSstatus:* - Set by working agentreview:* - Managed by EIApriority:* - Set by EAMA/EOAWhen handing off design to EOA, EAA should ensure:
component:* labels are seteffort:* is validatedtype:epicWhen 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"