tracker

Tools used: Bash(gh:*) for every tracker read and write, Bash(git:*) for branch context, Read for the standards and the per-repo config, Write for issue body files passed to --body-file.

The user invoked this skill with the argument: $ARGUMENTS

This is a routing skill. Read $ARGUMENTS and the conversation context, pick exactly one workflow, read that workflow file, and follow its instructions inline. Do nothing else.

All paths below are relative to this skill's own directory. Resolve them against wherever this skill is installed rather than assuming a location: it ships inside a plugin, so its root is whatever the harness installed the plugin to, and the working directory is the repository being tracked.

Issue, ticket and task all mean the same thing here: a GitHub issue. The owner uses the three interchangeably and expects you to. "Write tickets for X", "break this into issues" and "give me the next task" are requests about the same object, and none of them implies a different tool, a different tracker or a different level of granularity.

Every file here is written to the agent, so you is the agent reading it. The human is the owner, always in the third person. The exceptions are workflows/help.md, whose contents are printed to the owner, and README.md, which the owner reads rendered; both address them directly.

Who this is for

One person owns the repository, writes the issues and does the work. That assumption is load-bearing and it is why this skill is shorter than a team equivalent. What is absent is coordination between developers: no estimate to defend to peers, no ticket handed over for someone else to pick up, no sprint boundary another developer is waiting on. Where a team process adds a gate to keep two people in sync, this one records a fact and moves on. Who else may be around it turns on one test: whether they write to the repository.

The team habit it keeps is assignment, repurposed: @me means work has started on this. A GitHub issue has only open and closed, and assignment supplies the missing middle. Assign when work starts, unassign when it is set aside unfinished. It deliberately does not mean queued: the only operation that assigns is Start work, which cuts the branch in the same breath, so nothing in this skill can produce a queued issue and a wider meaning would describe a state the tooling cannot reach. Closing needs no unassign: the issue keeps @me and drops out of the list anyway, because every view that matters filters on open. The one place that bites is reopening, which brings the old assignee back with it. assignee:@me is:open is then a live answer to "what am I in the middle of", across every repository at once.

Ownership is not what it records. Every issue in the owner's own repository is implicitly theirs, so assigning on creation would say nothing and cost the signal its meaning.

Pull requests follow the same rule: whoever opens one is assigned to it. It needs saying because GitHub will not do it, recording the author but leaving the assignee empty, so it takes an explicit --assignee @me at creation. The scheme is consistent, not two rules: assigned means in flight. An issue is only in flight while the owner is working on it, so it is assigned and later cleared; a PR is in flight for its whole life, so it is assigned once at creation and needs no clearing. This skill does not open pull requests itself — pr-flow does, and it sets the assignee at creation — but the rule holds wherever one is opened.

The test is write access, not headcount: the owner owns the repository and is the only person who writes to it. Other people may be involved, and it changes nothing as long as the tracker and the code have one author.

• A client who sets scope, priorities and deadlines: fine. They decide what matters, the owner still writes every issue.
• A mentor or reviewer who reads issues, comments on them and reviews pull requests: fine. Comments are not writes, and nothing in these standards waits on their approval.
• A second committer, a QA sign-off that gates a merge, or anyone else who creates or edits issues: out of scope. Stop and raise it rather than adapting these standards to fit, because they will quietly under-serve it.