The 10-ticket rule: when to use Auto-Play (and when not to)

Auto-Play transforms how teams process large batches of work. Instead of executing tickets one at a time (open, write prompt, execute, review, approve, create PR, repeat), you queue an entire Epic and let JuhJuh process it sequentially. Each ticket builds on the context of completed siblings.

But Auto-Play is not always the right choice. Some work patterns benefit from batch execution. Others need manual control. Here is a practical framework for deciding.

How Auto-Play works

When you trigger Auto-Play on an Epic or Story:

1. JuhJuh identifies all child tickets
2. Tickets are ordered by priority (highest first)
3. Each ticket executes in sequence
4. Sibling context passes between executions
5. Execution continues until the queue empties or you pause

The sibling context is the key differentiator. When ticket #5 executes, its prompt includes what tickets #1-4 accomplished: which files changed, what architectural decisions were made, what naming conventions were established. Ticket #5 builds on that foundation instead of starting from scratch.

When Auto-Play excels

Pattern 1: Refactoring waves

You are renaming a concept across 15 modules. Each module is its own ticket. The tickets are independent (each can succeed or fail on its own) but related (they follow the same pattern).

Auto-Play handles this efficiently. The first ticket establishes the renaming pattern. Subsequent tickets inherit that pattern through sibling context. The AI does not reinvent the transformation for each file.

Pattern 2: Feature buildouts with clear layers

A feature that touches database, API, service layer, and frontend in sequence. Each layer is a ticket. The dependencies are linear: database before API, API before service, service before frontend.

Auto-Play's sequential execution matches the natural dependency order. Each layer knows what the previous layer created.

Pattern 3: Test coverage expansion

You are adding integration tests for 20 endpoints. Each test is a ticket. The tests share fixtures, patterns, and conventions.

The first test ticket establishes the testing patterns. Subsequent tickets inherit those patterns. The tenth test knows how the first nine were structured.

Pattern 4: Documentation passes

Updating docstrings across a codebase. Each module is a ticket. The changes are independent but should follow consistent style.

The sibling context ensures documentation style stays consistent across the batch. The last ticket matches the first.

When to execute manually

Pattern 1: Complex dependencies

Tickets where the order of execution depends on runtime decisions. "If the API change requires a migration, do that first; otherwise, skip it." Auto-Play cannot make conditional choices.

Execute these tickets manually. Review each output before deciding the next step.

Pattern 2: Exploration work

You are not sure what the right approach is. The first ticket might reveal that the entire Epic needs restructuring.

Manual execution lets you learn from early results and adjust the plan. Auto-Play would charge ahead with an outdated understanding.

Pattern 3: High-stakes changes

Database migrations, authentication changes, billing system updates. Work where a mistake has serious consequences.

The safety model still applies: five review layers between execution and production. But manual execution adds an additional checkpoint: you review each ticket's output before the next begins.

Pattern 4: Unrelated tickets

An Epic that contains tickets for organizational convenience, not logical grouping. "Q1 Tech Debt" with unrelated cleanup tasks.

Sibling context adds no value here. It might even confuse the AI by injecting irrelevant information. Execute these individually.

The 10-ticket rule

A useful heuristic: if your Epic has 10 or more related tickets that follow similar patterns, Auto-Play likely saves significant time. Below 10, the overhead of reviewing batch output versus sequential output is comparable.

This is a guideline, not a law. An Epic with 5 highly-patterned tickets might be perfect for Auto-Play. An Epic with 20 loosely-related tickets might not be.

The real question is: "Will later tickets benefit from knowing what earlier tickets accomplished?" If yes, Auto-Play. If no, manual.

Monitoring Auto-Play execution

Auto-Play is not fire-and-forget. The dashboard shows:

• Queue position: Which ticket is currently executing
• Completed tickets: Results from finished executions
• Real-time output: Live streaming of the current execution
• Pause button: Stop the queue at any point

If an execution produces surprising results, pause the queue. Review what happened. Decide whether to continue, adjust the remaining tickets, or abort.

Good practice: start Auto-Play, monitor the first 2-3 tickets closely, then check back periodically. If the early tickets look good, the later ones usually follow the same pattern.

Sibling context in practice

What actually flows between tickets?

• File changes: Which files were created, modified, or deleted
• Code patterns: Naming conventions, structural decisions
• Architectural choices: Where new code was placed, how it was organized
• Error context: If a previous ticket failed, why it failed

This context is injected into the prompt as structured data. The AI sees what changed, not just that something changed.

Example sibling context (simplified):

Previous tickets in this Epic:
- Ticket #1: Created user_preferences table migration
  - New file: migrations/0047_user_preferences.py
  - New columns: notification_email, notification_sms, timezone, language

- Ticket #2: Added UserPreference model
  - Modified: models/user.py
  - New class: UserPreference with FK to User

Ticket #3 does not have to guess at the schema. It has the exact column names, the exact model structure, the exact file locations.

Making the decision

Before triggering Auto-Play, ask:

1. Are these tickets genuinely related, or just grouped together?
2. Will later tickets benefit from knowing what earlier tickets did?
3. Is the execution order deterministic, or does it depend on runtime results?
4. How much does a mistake in one ticket affect the others?

If the answers favor automation, use Auto-Play. If they favor control, execute manually. The tool is powerful precisely because you can choose when to use it.