Create and refine tickets for the tk ticket system. Use when the user says 'create tickets for X', 'refine ticket X', 'break this into tickets', 'seed tickets from plan', or anything about creating or refining tk tickets.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Create and refine tickets for the tk ticket system. Use when the user says 'create tickets for X', 'refine ticket X', 'break this into tickets', 'seed tickets from plan', or anything about creating or refining tk tickets.
Ticket creator
Create well-structured tickets that the ticket-worker skill can consume without ambiguity.
Numbered, each independently verifiable. Prefer criteria that map to a command
Type
Yes
bug, feature, task, epic, chore
Dependencies
When order matters
tk dep <id> <blocks-id> — the second arg depends on the first
Parent
For subtasks
--parent <epic-id> — ticket is a subtask of an epic
Good ticket example
tk create "Fix token refresh returning 401 on expired tokens" \
-d "The /auth/refresh endpoint returns 401 when the refresh token is expired.
Should return 403 with a clear error message instead.
Relevant code in src/auth/refresh.ts and src/auth/middleware.ts." \
--acceptance \
-t bug
"1. POST /auth/refresh with expired token returns 403 (not 401)
2. Response body includes 'error' field with descriptive message
3. Existing tests pass
4. New test covers expired token case"
Bad ticket example
tk create "Fix the bug" -d "There's a bug somewhere in auth"
No acceptance criteria, no file hints, no verification command. The agent will wander.
Acceptance criteria guidelines
Each criterion must be independently verifiable
Prefer criteria that map to a command: "tests pass", "linter clean", "curl returns X"
Always include "existing tests still pass" as one criterion (unless no tests exist)
For refactors: "behavior unchanged" + "tests pass" is sufficient
Never use vague criteria like "code is clean" or "well-structured"
Parent vs dependency
Use --parent when one ticket is a logical subtask of an epic (e.g., "implement login form" under "add auth system"). Use dep when two tickets are independent work items where one must finish before the other starts. When in doubt, use dep — it's the more common relationship.
Only add dep when there is a real ordering constraint (e.g., ticket B requires code that ticket A will create). If two tickets could be worked on in parallel, do not link them with deps.
Tagging rule
Only add --tags ready-for-development when the ticket is fully refined: description, acceptance criteria, and file hints are all present. Vague or wishlist tickets should have no tag — they live in the backlog until refined.
Refining is done via Mode 4 — do not hand-edit YAML frontmatter.
Size rule
A single ticket should be completable in one agent session (~30 min of agent work). If a task is larger, split it into multiple tickets with dependencies.
Modes
Mode 1: single ticket
User says: "create a ticket for X" or "add a ticket for X"
Clarify scope if ambiguous
Explore the codebase to find relevant files
Create the ticket
Commit the ticket: git add .tickets/ && git commit -m "feat(tickets): add ticket for <short description>"
Show the created ticket to the user
If the request is vague ("add a ticket for that auth thing I mentioned"), create a backlog ticket: brief title, minimal description, no tag. The user or a later refine session will fill in the details.
If the request is specific enough to write proper acceptance criteria and file hints, create a fully-formed ticket with--tags ready-for-development.
Mode 2: decompose
User says: "break this goal into tickets" or "create tickets for refactoring X"
Understand the full goal
Explore the codebase to understand scope and relevant files. If lat.md/ exists at project root, run lat search "<goal description>" to discover relevant context from the knowledge graph
Seed context file if it doesn't exist (see "Context seeding" below)
Break into small, independently completable tickets
Create tickets in dependency order (create the prerequisite tickets first so you have their IDs)
Set dependencies: tk dep <downstream-id> <upstream-id> (downstream depends on upstream)
Validate the dep graph: tk dep cycle and tk ready — if there are cycles or no ready tickets, fix before proceeding
Show all created tickets and their dependency chain
Mode 3: seed from plan
User says: "seed tickets from this plan" or provides a plan file path
Read the plan file
Explore the codebase to understand scope and relevant files. If lat.md/ exists at project root, run lat search "<goal description>" to discover relevant context from the knowledge graph
Seed context file if it doesn't exist (see "Context seeding" below)
Identify discrete work items
Create tickets for each, preserving the plan's ordering via dependencies
Show the created tickets
Mode 4: refine
User says: "refine ticket X" or "refine backlog tickets"
Turn a vague backlog ticket into a workable one. If the ticket is too large, split it first (Mode 2).
Read the ticket: tk show <id>
If the ticket already has ready-for-development tag, tell the user it's already refined and stop
Explore the codebase to find relevant files, understand scope, and gather context
If the ticket is unclear, ask the user for clarification before proceeding
Batch refine: if the user says "refine backlog tickets" or "refine all", repeat for each untagged open ticket. Stop on the first one that needs user clarification — don't guess.
To rewrite a ticket file, use the write tool on the file path shown by tk show. Preserve the existing YAML frontmatter fields (id, created, deps, links, parent) and only update: title, description, acceptance criteria, type, tags.
Context seeding
Modes 2 and 3 create a context file to avoid redundant discovery in each ticket-worker session.
Prerequisite: if a lat.md/ directory exists at the project root, skip context seeding entirely. The lat search command (run in step 2) provides living, queryable context that makes a static context file redundant.
After exploring the codebase (step 2 in both modes), check if plans/.ticket-context.md exists. If it does, skip — the context is already seeded. If not, create it:
mkdir -p plans
Write plans/.ticket-context.md with three sections:
