implement-tickets

Orchestrate dependency-linked work items through isolated workers, worktrees, and human-controlled merges.

2|Updated May 14, 2026
One-click install
npx skills add https://github.com/AnthonyPoschen/agent-skills --skill implement-tickets-anthonyposchen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: implement-tickets
Source: https://github.com/AnthonyPoschen/agent-skills/tree/main/skills/implement-tickets
Command: npx skills add https://github.com/AnthonyPoschen/agent-skills --skill implement-tickets-anthonyposchen

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) and assets (resource) components.

What problem does it solve? Coordinating multiple backlog tickets across parallel AI workers is error-prone: dependencies get violated, workers overwrite each other, review feedback goes unanswered, and tracker state drifts from Git reality. This Skill provides a supervised orchestration workflow that dispatches isolated workers per ticket, enforces dependency gates, and keeps humans in control of merges. ## Core Features & Use Cases - Dependency-gated scheduling: Builds the work graph only from explicit blocker references and dispatches a ticket only when every blocker is verifiably merged into the target branch. - Multi-source and multi-harness adapters: Works with GitHub, GitLab, and Jira work sources, and Codex, Grok, or OpenCode worker harnesses, with a bundled Go supervisor for durable unattended runs. - Centralized publication authority: Workers never push, open reviews, or touch the tracker; the supervisor verifies diffs, creates checkpoint commits, pushes via explicit refspecs, and opens draft reviews. - Use Case: Select a Jira Story with Sub-tasks, and the supervisor discovers ready children, launches up to three isolated workers in separate checkouts, publishes draft merge requests as each finishes, processes authorized review feedback, and closes items only after human merges are verified on the target branch. ## Quick Start Ask the agent to implement the ready tickets from the backlog using the implement-tickets orchestration workflow with the appropriate tracker and harness adapters.

Frequently Asked Questions about implement-tickets

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

FAQPage Schema
How do I run multiple tickets in parallel with AI coding agents?▼

Select the tickets by number, range, query, or Jira container, then the supervisor dispatches one isolated worker per ready ticket up to a concurrency cap of three by default. Each worker gets its own branch and self-contained checkout, and completed items are verified and published independently without waiting for a batch.

Which issue trackers and AI harnesses does ticket orchestration support?▼

Work sources include GitHub, GitLab, and Jira, with Jira requiring the authenticated acli CLI and a GitLab remote for merge-request publication. Worker harnesses include Codex, Grok, and OpenCode; OpenCode and unattended runs use the bundled Go supervisor for durable state.

How are ticket dependencies handled during orchestration?▼

Dependencies come only from explicit blocker references or a Blocked by section, never from ticket order or inferred relationships. A ticket is ready only when every blocker is merged into the target branch, proven by Git ancestry, not merely closed on the tracker.

Can AI workers merge pull requests or close issues themselves?▼

No. Only a human may merge, and workers cannot push, open reviews, or touch the tracker at all. The supervisor publishes draft reviews and closes a ticket only after the human merge commit is verified as an ancestor of the target branch.

How is review feedback authorized before a follow-up worker acts on it?▼

Feedback is actionable only from provider-native CI failures, recognized scanner bots, the authenticated tracker account, or third-party comments endorsed by that account via a positive reaction or explicit authorization comment. Unendorsed third-party feedback and AI-generated comments are ignored.

What happens when a worker stalls or fails mid-run?▼

The supervisor detects dead processes and stalled logs, preserves the checkout, diff, prompts, and logs, then launches at most one replacement worker that validates the existing state before continuing. Payment errors like HTTP 402 are treated as resumable stalls, not failures.