run

Orchestrates a feature's ticket queue with one fresh subagent per ticket.

2|Updated Aug 3, 2026
One-click install
npx skills add https://github.com/GeraldoNeto123/ticket --skill run-geraldoneto123
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: run
Source: https://github.com/GeraldoNeto123/ticket/tree/main/skills/run
Command: npx skills add https://github.com/GeraldoNeto123/ticket --skill run-geraldoneto123

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Running a long queue of implementation tickets in a single AI session degrades quality as context accumulates, and parallel sessions corrupt shared build state. This Skill orchestrates the queue autonomously: it dispatches one fresh subagent per ticket, tracks progress in a resumable ledger, and enforces review and checkpoint cycles without losing work when a session dies. ## Core Features & Use Cases - Frontier-based queue execution: Computes the unblocked ticket frontier from the issue tracker, recalculating after each ticket, and escalates tickets with foreign assignees or open design decisions. - Fresh subagent per ticket with two-axis review: Each ticket gets its own subagent with an inline brief; after implementation, two parallel reviewers (Standards axis and Spec axis) write reports that are returned to the implementing subagent to apply via amend. - Resumable ledger and checkpoint cycles: A per-feature ledger records SHAs, timings, and outcomes for crash recovery, and every five closed tickets the checkpoint skill runs a cross-ticket consistency review. - Use Case: You have a feature sliced into 20 tickets by /to-tickets. Invoke /ticket:run with the spec path, and the orchestrator executes the queue sequentially, reviewing and committing each ticket, pausing only to escalate blockers or spec-design conflicts to you. ## Quick Start Run /ticket:run with the path to your feature spec to execute its ticket queue autonomously with one fresh subagent per ticket.

Frequently Asked Questions about run

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a queue of implementation tickets autonomously with an AI agent?▼

Invoke /ticket:run with the path to the feature spec. The orchestrator computes the unblocked ticket frontier, dispatches one fresh subagent per ticket with an inline brief, and updates a resumable ledger after each ticket until the frontier is empty.

How does automated code review work for each implemented ticket?▼

After a subagent commits, the orchestrator dispatches two parallel reviewers: one checks the diff against documented repo standards and a Fowler smell baseline, the other checks it against the spec and ticket. Reports are written to files and returned to the implementing subagent to apply via git amend.

Can tickets run in parallel instead of one at a time?▼

Sequential execution is the default because tickets collide on shared files and build caches. Parallelism is allowed only when the frontier partitions into clusters sharing no files, each cluster running in its own mandatory git worktree.

What happens if the session crashes in the middle of a ticket queue?▼

The ledger in .scratch/ticket-run records every ticket's status, SHA, and timestamps. On restart, the retomada reference reconciles ledger lines, git log, and ticket status so completed work is never reimplemented; ambiguous states escalate to the user.

When does the orchestrator stop and ask the user instead of continuing?▼

It escalates on tickets with foreign assignees, bodies ending in open design decisions, SPEC_DESIGN conflicts between spec and code, BLOCKED subagents, and any return outside the defined status contract. It never guesses a resolution.

What are the limitations of autonomous ticket queue execution?▼

It requires the mattpocock-skills plugin for the TDD skill and a repo with documented conventions for test layers, tracker states, and quarantine location. Tickets with unresolved blockers or dependency cycles remain unreachable and are reported at the end.