1.8 KiB
Work items
Yoi project work is tracked through work-items/ and ./tickets.sh. Git history plus work item files are the authoritative state-transition record.
Do not treat ad-hoc chat summaries, memory records, or Pod notifications as the final source of project state.
Basic commands
./tickets.sh create --title "..." [--slug slug] [--kind task] [--priority P2] [--label a,b]
./tickets.sh list [--status open|pending|closed|all]
./tickets.sh show <id-or-slug>
./tickets.sh comment <id-or-slug> [--role comment|plan|decision|implementation_report] [--file path]
./tickets.sh review <id-or-slug> --approve|--request-changes [--file path]
./tickets.sh status <id-or-slug> open|pending|closed
./tickets.sh close <id-or-slug> [--resolution text|--file path]
./tickets.sh doctor
Granularity
One work item should describe a complete change that can be explained as a feature, behavior, design decision, or maintenance outcome when closed.
Avoid tickets that only mirror an implementation step unless that step is independently reviewable and useful. Phase/step lists inside a ticket are execution order, not a separate dependency system.
Contents
A useful work item states:
- background and motivation
- requirements
- acceptance criteria
- relevant constraints
- review/implementation reports when work is submitted
- final resolution when closed
Keep long research dumps out of the item body. Put necessary artifacts under the ticket's artifacts/ directory and summarize the conclusion in the thread.
Workflow
Create or refine the work item before opening a separate implementation worktree. When using child Pods, the orchestrator should provide a scoped task and later verify concrete evidence: diff, tests, worktree status, and child output.
Closing a ticket means the repository records are ready, not merely that a child Pod announced completion.