Skill · Operate and improve

ticket-pipeline

Use when running a ticket from discovery through a draft PR. Sequences how, plans, verify-loop, TDD, verification, review, optional interrogate, then pr.

Written by Kunanon Jarat

Original
You invoke
MIT
Superstacks v6.1.1

View on GitHub

Install this skill

Installs only ticket-pipeline, globally, as a copy

DISABLE_TELEMETRY=1 npx skills add KunanonJ/superstacks -g -s ticket-pipeline --copy -y

Third-party installer; DISABLE_TELEMETRY=1 turns its telemetry off.

Folder layout (ticket-pipeline/SKILL.md). Unzip it into your agent’s skills directory.

Download ticket-pipeline.zip

Flat layout: SKILL.md sits at the zip root, ready to upload as a skill.

Download ticket-pipeline-flat.zip

Copy this folder from the repo at v6.1.1 into your agent’s skills directory

plugins/superstacks/skills/ticket-pipeline/

ticket-pipeline ships in the Superstacks plugin with the other skills. In Claude Code:

/plugin marketplace add KunanonJ/superstacks
/plugin install superstacks@superstacks

Run them one at a time. Codex, Cursor and ZIP steps are on the Skills page.

How it runs

You invoke it.

Its frontmatter sets disable-model-invocation: true, so the agent never loads it on its own. Ask for it by name.

Files

Folder on GitHub →

Origin

Original

Written for Superstacks

Written for Superstacks; sources.lock.json credits no upstream. Released under MIT with the rest of the pack.

License: MIT
Release: v6.1.1 · 2026-10-06

More in Operate and improve

Run tickets end to end and turn repeated mistakes into guardrails.

All 20 skills →

SKILL.md

View on GitHub

---
name: ticket-pipeline
description: Use when running a ticket from discovery through a draft PR. Sequences how, plans, verify-loop, TDD, verification, review, optional interrogate, then pr.
license: MIT
disable-model-invocation: true
---

# Ticket pipeline

Run a ticket from discovery through a **draft** pull request. `safety-overrides` beat every step.

Put evidence in the PR body under the headings this skill names. Then run the status script. Do not argue in prose about which steps are done:

```text
python <this-skill>/scripts/pipeline_status.py --pr-body BODY.md

```

Re-run until the script prints `missing: 0`.

## Sequence

1. **how** — build a mental model before changing code. Heading: `## How`.
2. **writing-plans** — plan in the pull request body. Heading: `## Plan`.
3. **verify-loop** — define the deterministic check, run it red (`VERIFY_FAIL`), then iterate.
4. **test-driven-development** — if the check is a test: failing test, then minimal code. Heading: `## TDD` (include `red-green`).
5. **verification-before-completion** — paste fresh `verify-loop` runner output. Heading: `## Evidence`.
6. **code-review** — Standards and Spec axes on the branch diff. Heading: `## Code review`.
7. **interrogate** — required for one-way doors (money movement, schema or data migrations, auth, data deletion, infra or prod config, licences). Heading: `## Interrogate`, or write `N/A (two-way door)`.
8. **pr** — draft pull request body. Run `pr/scripts/check_pr_body.py`. Ticket links are `Refs #N` only.

## Hard rules (also in safety-overrides)

- Draft PRs. Never mark ready. Merge only as `trust_level` in safety-overrides allows.
- Push only this branch. Rewrite with `--force-with-lease` only.
- No production credentials, live infrastructure, runtime package installs, or secret-using CI jobs.
- No tracker or chat writes from a ticket.
- Skip a blocking approval gate only with `Ruling: what / why` in the PR body.

## Stacked pull requests

When one ticket is too large for a single reviewable PR, split it into layers:

- One concern per layer. Dependencies belong in the same layer or a lower one.
- Open the next layer while the lower one is still in review.
- Merge bottom-up. When merging through the API, use the asynchronous merge endpoint for stacks.
- Prefer `gh stack` for cascading rebases. If stacks are unavailable, chain pull requests with plain base-branch targeting.