Skip to content

Latest commit

 

History

History
128 lines (86 loc) · 3.18 KB

File metadata and controls

128 lines (86 loc) · 3.18 KB

CAR Ticket Skill

Use this with ChatGPT, Claude, Codex, or any other assistant when you want help converting a plan into CAR-compatible tickets.

Prompt pattern:

  1. Share your implementation plan.
  2. Attach or paste this skill doc.
  3. Ask the assistant to produce TICKET-###*.md files that follow these rules.

1) Ticket files

  • Filename: TICKET-###*.md Examples: TICKET-001.md, TICKET-120-api-parity.md
  • Tickets must be in ascending numeric order.
  • Numbers do not need to be consecutive. Leave gaps if follow-up tickets are likely.

2) Required frontmatter (minimum)

---
ticket_id: "tkt_0123456789abcdef"
agent: "codex"
done: false
---

Required (linted):

  • ticket_id: stable logical ticket identity used by CAR state; normal CAR writer flows auto-generate this, and repair tools can backfill it for older tickets
  • agent: registered CAR agent id for this repo (for example codex, opencode) or the special value user
  • done: boolean

Do not use assistant product names as agent values (for example chatgpt or claude) unless those exact ids are configured in CAR for this repo.

Common optional fields:

  • title: short, outcome-focused summary
  • goal: one-sentence statement of intent
  • model: pin a specific model when necessary

3) Recommended ticket body structure

Keep tickets concise and independently verifiable.

Preferred sections:

  • ## Tasks - concrete implementation steps
  • ## Acceptance criteria (or ## Exit criteria) - observable outcomes
  • ## Tests - commands or explicit verification steps
  • ## Notes - only if necessary

Write criteria so another agent can prove completion without guesswork.


4) Sequencing rules (critical)

CAR's ticket_flow:

  • Executes tickets in ascending order
  • Picks the first ticket where done != true

Implications:

  • Put prerequisites in lower-numbered tickets.
  • Never make a lower-numbered ticket depend on a higher-numbered one.
  • If reverse dependencies appear, reorder or split tickets.
  • Each ticket must be independently completable when its turn arrives.

5) Assignment defaults

  • Implementation work -> repo agents (codex, opencode, etc.).
  • Final human review/signoff -> user-assigned ticket near the end.
  • In PMA mode, prefer delegation, not direct code edits.

6) Quality bar for good tickets

A good ticket:

  • Has a single, well-scoped outcome
  • References specific files/modules when useful
  • Includes explicit verification (tests, checks, or observable behavior)
  • Avoids vague language ("improve", "clean up", "fix issues") without criteria

7) Copy-paste ticket template

---
title: "<Outcome-focused title>"
agent: "codex"
done: false
goal: "<What will be true when this ticket is complete>."
---

## Tasks
- <Concrete implementation step>
- <Concrete implementation step>

## Acceptance criteria
- <Observable behavior or artifact>
- <Observable behavior or artifact>

## Tests
- <Commands to run or explicit checks>

8) Anti-patterns to reject

  • Missing or invalid frontmatter
  • Cross-ticket dependency deadlocks
  • Tickets that rely on unstated or hidden context
  • done: true without evidence against acceptance criteria