linear-maintenance

# Linear maintenance A regular housekeeping sweep over the evlog team's Linear backlog so it stays readable and current between passes. The goal is a tidy, trustworthy backlog, not a census. Listing every issue is not the point; correcting the drift and flagging what needs a decision is. Where the other skills draw the line: `self-review` owns the coherence and reach of the agent's own surface, `repo-health-sweep` owns the repository and docs, `cost-watchdog` owns gateway spend. This skill owns Linear housekeeping only, and stops there. When a pass finds evidence that shipped work is now live (a schedule, a skill, a merged PR), the finding belongs to this skill's "close it" bucket, not to building anything. ## Two halves, in order **Apply** what is mechanically verifiable. These are the unambiguous fixes, and they are the point of the run: the sibling set or the issue history is evidence enough that a write is correct. Apply them directly via `linear__save_issue`. **Surface** what needs a judgement call about intent. Anything you cannot verify, or whose correct value is a matter of taste, stays open and is written down as a finding for Hugo. Never guess a decision that a sibling set or the issue history cannot support. ## The lenses Enumerate the open surface first: `linear__list_issues` on the evlog team, across states. Then for each item check: - **Project**: every open issue sits in the project its title and content point to, or in `Triage` if it is genuinely unplaced. An issue whose peers carry a project but it does not is a fix, not a finding. - **Priority**: an item `In Progress` should carry a priority consistent with its siblings; a `Backlog` item with no priority next to prioritized peers is inconsistent. A priority change that relies on an estimate of intent is a finding. - **Label**: every open issue carries one of the team's labels. A feature request with no label is a fix. A label that duplicates another, or has a single use, is a hygiene finding. - **Stale**: triage older than several months with no movement, parked next to a canceled sibling, or an investigation that outlived its question, is a finding (close it or kick it to the community). - **Done but open**: an item whose work already shipped in another issue, a schedule, or a merged PR, and is still open, is a close. Only when the shipped evidence is verifiable from the issue history or linked work. - **Consistency**: a true duplicate of a completed or archived sibling, a sub-issue misread as a duplicate, work whose state contradicts its neighbors. ## Grounding - **Absence is proven by listing, never by recall.** Before writing that a project, label or priority is missing, enumerate the real surface with `linear__list_issues` and the label list. A value you do not remember seeing is not a value that is absent. - **Run before you assert.** A "this is shipped" close is grounded in the issue history, a linked PR, or a live schedule that the issue thread or the repo confirms. If it could not be verified, it is a finding written as a question, not a close. - **One counter-example kills a claim of inconsistency.** Check the sibling set in the same project and state before declaring something misfiled. ## Deliver The report is a Linear document per run: the fixes already applied, and the open decisions each with the evidence and the question to resolve. Post one line per artifact to the thread, links inline. Then stop; do not read the report back to confirm it. - **Mechanical fix, unambiguous → apply it** with `linear__save_issue` and list it in the report under "applied". - **Decision → a finding** in the report under "left open", naming the evidence and the exact call to make. A finding that needs a decision Hugo has not asked you to take stays open; do not close it unilaterally. Never invent a fix to fill the run, and never report a lens as clean when it ran and found nothing of note. A quiet pass is a real result: one line saying so.