Public guide only. Install the skill in your IDE; this site never fetches tickets, commits code, or posts to chat. Companion to the AI-Assisted SDLC Playbook.
Thirty minutes to wire Ticket Flow into a team. Prefer the Flow view once you know the steps.
Copy .cursor/skills/ticket-flow/ and .cursor/rules/*.mdc into your product repo’s .cursor/ directory (or open this repo as a multi-root workspace).
Next: wire the thin script wrappers to your CLIs.
Edit wrappers under scripts/ so they call your tools. Unconfigured scripts exit with an error — they never invent ticket text or claim a chat send succeeded.
issue-get.sh → Jira / Linear / gh issue viewgit-branch.sh, git-commit.sh, git-push.sh, git-pr.shnotify-chat.sh → webhook or chat CLI (channel required)Next: initialize a private progress board.
Copy docs/progress-template.md to .local/progress.md (gitignored). Use it for morning multi-ticket queues.
Next: try a phrase that loads the skill.
In Cursor chat, say something like:
work on ticket PROJ-123
or fix bug PROJ-123 / process morning queue. Expect Confirm gates before commit and before PR.
Vague requirements first? Use the playbook review-markdown before tickets exist, then return here for Develop one story.
Choose what you already have. Start there, then work through one step at a time.
Ticket Flow sequences how an IDE agent moves from a real ticket ID to a PR—with human Confirm gates—without becoming a platform.
These stay on even if the agent only partially loads the skill.
Paste into validation gates and PR bodies. Copy before you open the PR.
Before tickets exist, use the AI-Assisted SDLC Playbook. During implementation, pair with Develop one story.
Team setup, boundaries, and how this fits the SDLC playbook. Markdown sources also live in the repository.
Ticket Flow is meant to be copied or multi-rooted into the apps you change—not run as a SaaS.
.cursor/skills/ and .cursor/rules/ into the app (or keep this repo in a multi-root workspace).scripts/ where the agent can execute them; configure tracker and chat CLIs.Source repo: github.com/smg99/ticket-flow
The playbook owns stage prompts from vague requirements through release. Ticket Flow owns the IDE checklist once a real ticket ID exists.
Wrappers forward to existing CLIs. They must not reimplement tracker or chat business logic.
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).On failure: report the error envelope, offer recovery, do not invent success.
This repository and site are public. Keep real tickets, code, credentials, and proprietary designs in approved private systems. Use synthetic examples only.
A thin orchestration layer—Cursor skill, always-applied rules, and thin script wrappers—that sequences ticket ID → merged change with human Confirm gates before commit and before PR. Not a SaaS product or ticket platform.
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.
No. It only displays guidance and copyable prompts. PRs happen in your local clone via configured scripts and your code host after explicit Confirm.
One before commit (diff + Impact Area) and one before push/PR (title + body). Silence never counts as Confirm.
A pasteable handoff block: App, Surfaces, Components/APIs, Regression Risk, and Tests—used at validation and in PR descriptions.
The script must fail with setup instructions. Do not invent ticket descriptions; wire your tracker CLI and re-run.
Also available as a crawlable page: guides/ · Agents: llm.txt · llms-full.txt