task-tickets

Original：🇨🇳 Chinese

Translated

1 scripts

Ticket Assignment and Cross-Session To-Dos: One task per Markdown file, stored in the workspace's .yomi/tickets/ directory. Use this when breaking down tasks to assign to subagents for concurrent execution, reporting or updating task progress, and reviewing and aggregating outputs from subagents.

5installs

Sourcecrescent617/yomi-extensions

Added on2026-08-23

NPX Install

npx skill4agent add crescent617/yomi-extensions task-tickets

SKILL.md Content (Chinese)

View Translation Comparison →

Tickets

tickets are stored in the

.yomi/tickets/

directory of the workspace, with one ticket file per task, persisting across sessions. The core use case is task assignment: the ticket file serves as a work order, with status transitions recorded within the file. The only way others can track your work is through the ticket status.

Creating Tickets: Use the Script

Create tickets using

scripts/ticket.sh

(located in this skill directory) instead of writing the frontmatter manually—the script ensures compliance with ID/slug/timestamp/format requirements:

bash

<baseDir>/scripts/ticket.sh new --dir <workspace> --title "Task Name" --body "Description + Acceptance Criteria"   # Outputs file path

If

--body

is omitted and stdin is not a tty, the body will be read from stdin.

Status Transitions: Modify the File Directly

State machine:

pending → claimed → done | blocked

;

blocked → claimed

(resume work);

claimed → pending

(reset);

done

is a final state with no transitions (create a new ticket if rework is needed).

Claim a ticket: Change
```
status:
```
to
```
claimed
```
; add (or modify) the line
```
owner_session_id: "sess_..."
```
in the frontmatter—fill in your own session ID (found in the Environment section of system prompts).
Complete a ticket: Change
```
status:
```
to
```
done
```
; add a section titled exactly
```
## Result
```
at the end of the body (include a result summary + paths to key deliverables).
Mark as blocked: Change
```
status:
```
to
```
blocked
```
; append a line
```
> [YYYY-MM-DD] Blocked on X, needs Y
```
at the end of the body.
Reset to pending: Change
```
status:
```
to
```
pending
```
; delete the
```
owner_session_id:
```
line; you may append a note explaining the reason.

When modifying the frontmatter: keep the key names unchanged; do not add
updated_at
(display time is derived from the file's mtime).

File Format

.yomi/tickets/<id>-<slug>.md

:

markdown

---
title: One-line Task Name
status: pending | claimed | done | blocked
owner_session_id: sess_...    # Fill in your session ID when claiming
created_at: 2026-08-09T10:00:00+08:00
---

> **Ticket Rules** (read before editing this file; follow even if you haven't installed the task-tickets skill):
> - State machine: pending → claimed → done | blocked; blocked → claimed (resume); claimed → pending (reset); done is final (create new ticket for rework).
> - Claim: Change status to claimed; add `owner_session_id: "sess_..."` (your session ID) to frontmatter.
> - Complete: Change status to done; add `## Result` section at end (summary + deliverable paths).
> - Blocked: Change status to blocked; append `> [YYYY-MM-DD] Blockage and needs` at end.
> - Keep frontmatter keys unchanged; do not add updated_at (display time derived from file mtime).

Task description + verifiable acceptance criteria.

## Result
(When completed: Result summary + paths to key deliverables)

The top rule block is automatically injected by the ticket creation script—tickets are self-explanatory, so executors don't need to install this skill. The ID is a 7-character random alphanumeric string (e.g.,

t3m9q2x

), automatically generated by the script when creating a ticket—the kernel extracts the part before the first

in the filename as the ID.

Task Assignment (Coordinator)

Break down work into packages, and create a ticket for each package using the
```
new
```
script. Include full context in the ticket body—executors don't have your context, so the ticket is all they know.
When spawning subagents, specify their ticket path in the prompt (e.g., "Your ticket is
```
.yomi/tickets/t3m9q2x-xxx.md
```
"); multiple tasks can be assigned concurrently. The top of the ticket includes editing rules, so executors can follow them even without installing this skill.
Completion criteria: Every work package has a ticket assigned upon spawning, and
```
grep -l "status: pending" .yomi/tickets/*.md
```
lists all unclaimed tickets.

Task Execution (Executor)

Claim the ticket before starting work after being assigned a task (set status to
```
claimed
```
and fill in the owner as per the "Status Transitions" section)—claiming ensures the ticket matches reality.
Perform the task. Mark as
```
done
```
and write the Result when finished; mark as
```
blocked
```
and specify the blockage if stuck. Record process updates/findings in the blackboard (for multi-agent collaboration, see the blackboard skill); the ticket only tracks status and results, no need to include process details.
Completion criteria: The ticket status matches the actual progress. Saying "done" verbally doesn't count—it's only done when marked as
```
done
```
in the file.

Aggregation and Acceptance (Coordinator)

Use
```
grep "^status:" .yomi/tickets/*.md
```
to check the overall status; subagents will update the files themselves, so aggregate by reading the files instead of asking each one individually.
After all tickets are marked
```
done
```
, conduct a unified review (you can assign a
```
verifier
```
template for independent review), and move approved files to
```
.yomi/tickets/archive/
```
.
Completion criteria: Only incomplete tickets remain in the main directory.