paired-ticket

Create loop-ready Linear tickets with research, adversarial review, and acceptance criteria.

12|4|Updated May 14, 2012
One-click install
npx skills add https://github.com/sethvoltz/dotfiles --skill paired-ticket
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: paired-ticket
Source: https://github.com/sethvoltz/dotfiles/tree/main/claude/claude/skills/paired-ticket
Command: npx skills add https://github.com/sethvoltz/dotfiles --skill paired-ticket

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill turns a substantial change request into a loop-ready Linear ticket, so teams can research the work, pressure-test the plan, and avoid starting implementation on an unvetted design.

Core Features & Use Cases

  • Two-stage workflow: First drafts a research-based ticket, then sends a cold-start reviewer to challenge every claim and tighten the same ticket in place.
  • Repo-grounded analysis: Re-reads files, inventories affected surfaces, cites file and line numbers, and uses runtime probes when behavior needs proof.
  • Ticket quality control: Produces atomic acceptance criteria, explicit out-of-scope notes, and pinned defaults for any unresolved owner decisions.
  • Use case: Ideal for new features, refactors, and design changes that are big enough to warrant a Linear ticket before kicking off implementation.

Quick Start

Ask the paired-ticket skill to research, file, and adversarially review a Linear ticket for your feature or refactor.

Frequently Asked Questions about paired-ticket

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

FAQPage Schema
How do I create Linear tickets for complex refactors that require repo research?

It uses a two-stage workflow that first drafts a research-based ticket, then runs a cold-start adversarial reviewer to challenge every claim and tighten the ticket in place before implementation begins.

Can I pressure-test a design decision in Linear before starting implementation?

This ensures atomic acceptance criteria are established and any unresolved owner decisions are pinned as BLOCKED ON OWNER, preventing implementation on an unvetted design.

What is the best way to ensure a feature ticket has atomic acceptance criteria?

The Skill enforces these quality control measures during the adversarial review stage, tightening the ticket in place so implementation boundaries are clear.

Does this ticketing workflow require exact file and line citations from my repo?

It re-reads files and inventories affected surfaces, using runtime probes when behavior needs proof, so the resulting Linear ticket accurately reflects the codebase state.

When should I use an adversarial review loop for creating Linear tickets?

It applies a cold-start reviewer to challenge claims and tighten the ticket in place, preventing teams from starting implementation on an unvetted design.

What limitations exist when using this approach to draft and tighten Linear tickets?

Additionally, the adversarial review operates as a cold-start challenge, meaning the tightening process focuses on pressure-testing claims within the ticket itself rather than validating external dependencies.