Actions

Stop Conditions:

• Issue requirements are ambiguous -- flag as human-required and note the ambiguity
• Missing project context needed for language inference
• Conflicting dependencies that need human resolution

Recovery:

• If Linear data is incomplete, classify what is available and list gaps
• If priority scoring inputs are missing, use complexity + parallelizability as fallback ranking
• Default to human-ai when parallelizability is unclear

Sprint Master Classification Reference

Reference data for classifying sprint issues. Provides complexity definitions, parallelizability categories, team agent routing, and estimation guidelines.

1. Complexity Definitions

Low Complexity (2-4 hours)

• Bug fixes with clear reproduction steps
• Simple refactors with isolated impact
• Documentation updates
• Configuration changes
• Test additions for existing functionality

Medium Complexity (4-8 hours)

• Standard features with defined requirements
• API integrations with documented endpoints
• UI components following existing patterns
• Multi-file changes with predictable impact
• Database migrations with rollback plans

High Complexity (8-16 hours)

• Architecture decisions requiring research
• Security-critical implementations
• Complex state management
• Cross-cutting concerns affecting multiple systems
• Performance optimizations requiring profiling

2. Parallelizability Categories

ai-parallel

Tasks that agents can handle independently without human oversight.

Characteristics:

• Clear specifications with testable outcomes
• No ambiguous requirements
• Follows established patterns

Examples:

• Boilerplate generation
• Test writing with clear specs
• Documentation updates
• Bug fixes with clear repro steps
• Linting/formatting cleanup
• Type annotations

human-ai (Collaborative)

Tasks requiring human and AI collaboration throughout.

Characteristics:

• Standard complexity with some judgment calls
• May need mid-task clarification
• Design checkpoints recommended

Examples:

• Standard feature implementation
• API integrations
• UI component development
• Database schema changes
• Configuration system updates

human-required

Tasks requiring significant human judgment and oversight.

Characteristics:

• Ambiguous requirements needing interpretation
• Security or privacy implications
• Architectural impact
• User-facing decisions

Examples:

• Architecture decisions
• Security-critical code
• Complex state management
• Performance-critical paths
• User experience flows
• API design decisions

3. Team Agent Catalog

Reference: team-members.json for complete structure.

Note: Agent routing (general-purpose vs language-specific engineers) is determined at execution time by Araba based on current operational state. Refer to workspace:development-pipeline for the pipeline order.

Engineering Teams (Reports to Addy)

Design Reviewers (Reports to Alara)

Escalation Paths

4. Estimation Guidelines

Estimation Matrix

Estimation Heuristics

1. Start with complexity - Assess scope and technical difficulty
2. Apply parallelizability multiplier - Human involvement adds overhead
3. Add context-switching buffer - +25% for multi-day tasks
4. Consider dependencies - Blocked issues need buffer

Example Classifications

5. Weekend Flexibility Rules

weekendOk: false

Apply when:

• Issue blocks other critical path work
• Part of a dependency chain with weekday deadlines
• Requires synchronous collaboration
• Time-sensitive (external dependency, launch date)

weekendOk: true

Apply when:

• Issue is independent (no blockers, not blocking)
• Stretch goal that can slip without impact
• Research or exploration task
• Nice-to-have improvement

Critical Rule

Never create dependency chains where weekend work blocks weekday work.

Bad Pattern:

Mon: WOR-100 (blocked by WOR-101)
Sat: WOR-101 (weekendOk: true)  ← WRONG: blocks Monday work

Good Pattern:

Mon-Thu: WOR-100 (critical path)
Sat: WOR-102 (independent stretch) ← OK: no dependencies

6. Priority Framework

Addy Lens (Engineering)

Evaluates from technical perspective:

• Complexity: How hard is this to build?
• Dependencies: What does this block/depend on?
• Technical debt: Does this reduce or add debt?
• Execution order: What's the optimal build sequence?

Alara Lens (Design/Product)

Evaluates from product perspective:

• User impact: How many users benefit?
• Design complexity: How much design work needed?
• Review checkpoints: Where do we need approval?
• Goal alignment: Does this advance our objectives?

Combined Priority Score

Priority = (UserImpact × 3) + (TechnicalUrgency × 2) + (DependencyScore × 2) + (GoalAlignment × 1)

7. Classification Output Schema

Return this JSON structure for each classified issue:

{
  "issueId": "WOR-123",
  "title": "Issue title",
  "complexity": "low|medium|high",
  "parallelizable": "ai-parallel|human-ai|human-required",
  "estimateHours": 6,
  "suggestedAgent": "typescript engineer",
  "weekendOk": false,
  "dependencies": ["WOR-120", "WOR-121"],
  "goalAlignment": "Q1 Goal: Ship auth feature",
  "notes": "Needs design review checkpoint"
}

Field Definitions

8. Autopilot Enrichment Checklist

Reference for auditing tickets against autopilot eligibility requirements.

Label Gate

Every autopilot-eligible ticket MUST have:

Description Gate

Ticket description MUST contain acceptance criteria in one of these forms:

• Heading: ## Acceptance Criteria or ## AC
• Checkbox list: - [ ] criteria item
• Numbered requirements: 1. requirement

Minimum: 2 acceptance criteria items.

Estimate Gate

Ticket MUST have a Linear estimate set. Use the estimation matrix from Section 4 to propose values.

Language Inference Table

When a ticket has a project label but no language label, infer language:

Enrichment Output Schema

{
  "issueId": "WOR-240",
  "identifier": "WOR-240",
  "title": "Issue title",
  "status": "ready | needs-enrichment",
  "missing_labels": ["typescript"],
  "missing_estimate": true,
  "missing_acceptance_criteria": false,
  "proposed_labels": ["typescript"],
  "proposed_estimate": 4,
  "notes": "Language inferred from project label 'portfolio'"
}

9. Development Pipeline Integration

All ticket execution follows the workspace:development-pipeline skill as the canonical pipeline order. This applies to both manual and autopilot ticket execution.

Pipeline Order

1. Codex reviewer -- reviews ticket context, Slack threads, and supporting information
2. Language architect -- reviews Codex output, designs implementation approach
3. Engineer -- implements using TDD (red/green cycle)
4. Code reviewer -- reviews implementation for quality, patterns, and standards
5. Security reviewer -- reviews for vulnerabilities, secret exposure, and access control
6. PR creation -- branch, commit, push, and open PR with full context

Key Rules

• Agent type (general-purpose vs language-specific) resolved at runtime by Araba
• Load workspace:development-pipeline skill for pipeline order
• Each pipeline step produces artifacts consumed by the next step
• If any step fails, fix and re-run that step before proceeding

Batch Output

When classifying multiple issues:

{
  "classification": [
    { "issueId": "WOR-123", "..." },
    { "issueId": "WOR-124", "..." }
  ],
  "totalHours": 16,
  "weekdayHours": 12,
  "weekendStretch": 4,
  "notes": "WOR-123 blocks WOR-124"
}