Guides

Ticket Flow is a free public method for running an IDE agent from ticket ID to PR with mandatory human gates. Use it after tickets exist; use the AI-Assisted SDLC Playbook earlier in the lifecycle.

What Ticket Flow is

A thin orchestration layer: skill checklist, trigger rules, and script wrappers that call your existing git / issue / chat CLIs. Product standards stay in each app’s own rules. Ticket Flow only sequences how work moves from ID → merged change.

Companion to the AI-Assisted SDLC Playbook

• Review markdown before tickets
• Develop one story — trigger Ticket Flow phrases here

Install into a product repo

1. Copy .cursor/skills/ and .cursor/rules/ into the app (or multi-root this repo).
2. Configure scripts/ for tracker and chat; unconfigured wrappers fail loudly.
3. Keep client tickets and code out of this public repository.

Detail: Quick start · Source: github.com/smg99/ticket-flow

Script wrappers and failures

• Unconfigured issue-get.sh / notify-chat.sh exit non-zero with instructions.
• git-branch.sh refuses a dirty tree and reuses an existing ticket branch if present.
• git-push.sh blocks direct push to main/master.
• git-pr.sh seeds an Impact Area body (or accepts a body file).

Security boundary

This repository and site are public. Keep real tickets, source, credentials, and proprietary designs in approved private systems. Use synthetic examples only.

Glossary

Primary app

The main product repository only.

Product suite

Primary app plus sibling product repos in the same family.

Suite + shared UI

Those products plus the shared UI package. Shared UI is not “the app” and not “the suite.”

Confirm

Explicit human approval at a gate. Silence never counts.

Impact Area

Pasteable handoff: App, Surfaces, Components/APIs, Regression Risk, Tests.

FAQ

What is Ticket Flow?

A thin orchestration layer—skill, rules, and scripts—that sequences ticket ID → merged change with human Confirm gates. Not a product platform.

How does it relate to the AI-Assisted SDLC Playbook?

The playbook owns stage prompts from vague requirements through release. Ticket Flow owns the IDE checklist once a real ticket ID exists, especially during Develop one story.

Does this site create PRs?

No. It only displays guidance. PRs happen in your local clone via configured scripts and your code host after Confirm.

Why two Confirm gates?

One before commit (diff + Impact Area) and one before push/PR (title + body). Silence never counts as Confirm.

What is an Impact Area?

A pasteable handoff block: App, Surfaces, Components/APIs, Regression Risk, and Tests—used at validation and in PR descriptions.

What if issue-get is not configured?

The script must fail. Do not invent ticket descriptions; wire your tracker CLI and re-run.

Open interactive flow · llm.txt · llms-full.txt