| name | yegor-tickets |
| description | All meaningful project communication lives in the issue tracker. No Slack, DMs, or meetings as the primary channel. Decisions don't exist until written as a ticket comment. Use when making a design decision, changing direction, answering a project question, or proposing a new approach. |
| version | 0.3.0 |
| last_reviewed | 2026-06-26T00:00:00.000Z |
Yegor Ticket-as-Conversation
If it isn't in the issue tracker, it didn't happen. Write the comment first; chat is just a courtesy summary of the artifact.
Triggers
- About to make a design decision
- About to answer a project-specific question
- About to change direction mid-work
- User proposes a new approach informally in chat
What lives in tickets
- Every question
- Every design decision
- Every blocker
- Every assumption (recorded as a comment)
- Every "won't do because X" (closes the ticket with justification)
What does NOT live elsewhere as the primary record
- Decisions in Slack/Discord/Telegram: forbidden as primary
- Decisions in meetings: meeting output is N issue comments, otherwise the meeting didn't exist
- Decisions in commit messages: rationale lives in the ticket; the commit references it
- Decisions in your head: especially for solo work — your head is not a database
Comment hygiene
- Every comment is addressed to a specific person via
@-mention.
- Every comment advocates closing the ticket OR keeping it open until a specific condition.
- "+1" / "agreed" / "thanks" → use reactions, not comments.
Closing discipline (Five Principles of Bug Tracking)
Two rules govern when and how a ticket ends:
- Keep it one-on-one. A ticket is a transaction between one reporter and
one solver, not a forum. Others are secondary. Don't let a ticket sprawl into
a committee thread — if it needs many voices, that's a smell to split or
escalate, then land the outcome back here.
- Never close it empty-handed. Close fast — long-lived tickets waste
attention — but never close a ticket without delivering some solution,
even a temporary or partial one (a workaround, a disable, a "can't reproduce"
proof test, a follow-up ticket). "Closing with nothing" is forbidden; closing
with the smallest honest deliverable is the goal.
Correcting an existing description
A ticket description is an authored artifact. When you find an error in someone else's description — a wrong cross-reference, a stale dependency, an outdated premise — do not silently rewrite the body. Redline it instead, so the correction stays additive and auditable like every other decision here:
- Add a banner at the very top:
> ⚠️ **SEE COMMENTS FOR CORRECTIONS**.
~~Strike through~~ the wrong/outdated text in place — leave it visible, marked as superseded. Never delete it.- Post the correction as one or more comments — what was wrong, the right value, and why.
This keeps the original visible (the audit trail), the author's voice intact, and the authoritative fix in the timestamped comment stream — the same "additive, in-the-tracker" discipline as the rest of this skill. The issue's own owner doing normal scope/spec edits is unaffected; this targets a second party fixing a factual error.
Rules for Claude
Before answering a design question in chat:
- Ask: "Should I write this as a comment on issue #N first?"
- Write the comment, then summarize back to the user. The artifact is primary; the chat reply is courtesy.
When the user changes direction:
- "Let me write this rationale into the relevant issue first, then we'll continue."
When the user says "I decided to X":
- Ask which ticket it lands on. If none, create one or attach as a comment to a related one. Spoken decisions evaporate.
When reviewing a project:
- Read the issue tracker first, not the code. The tracker is the project's mind.
Solo developer ritual
- Write the issue before writing the code — even for 15-minute work.
- Comment on the issue when you change your mind: "Earlier I thought X; now Y because Z."
- Close the issue with a one-line outcome: "Closed by commit abc123 — chose approach Y, see comment above."
- End-of-session journal: comment on the active issue with where you stopped and what's next.
Pitfalls
- Over-ticketing trivia (typos don't need tickets — threshold is anything that involves a decision or could be questioned later).
- "I'll write it later" — reverse the order: write the comment first, then chat.
- Walls of text in comments — keep each one short and focused (problem → refinement → explanation → solution → close).
- Locking arguments in comment threads — escalate to a synchronous conversation, but the output still lands back in the ticket as a final comment.
Cross-references
yegor-bdd — tickets are complaints, not chats.yegor-architect — architect decisions land as ticket comments before any PR opens.yegor-velocity — if it's not a ticket, it can't be counted.yegor-nohelp — answers to questions live in docs, but the question itself is a ticket.
Deep reference
research/philosophy_04_tickets_ticket_as_conversation.mdresearch/philosophy_17_bug_tracking_hygiene.md (the Five Principles of Bug Tracking, shared with yegor-bdd)
