Tracking

Filing or closing work.

SKILL.md.agents/skills/thorbis-tracking/

Follow the skill selection policy and shared Linear baseline. For mobile-app work, the Native contract (D-025) is required.

Scope and required context

Linear baseline: This skill specializes one part of Thorbis; it does not introduce another product grammar. Preserve quiet chrome, one dominant work region, structured density, stable action neighborhoods, contextual surfaces, visible keyboard paths, durable state, and role-adaptive mobile. Use the Thorbis × Linear pattern matrix only when the owning pattern is ambiguous.

Mobile platform gate (D-025): Every mobile-app task requires the Native contract, HIG-001–HIG-022, and relevant live Apple Human Interface Guidelines (opens in a new tab). Apple HIG governs iOS/iPadOS behavior over conflicting web/Linear rules. Cite rule IDs and topic URLs in specifications, component contracts, PRs, and release evidence. Android retains host conventions. Normative requirements and exceptions have one owner: Native.

Linear is the source of truth. Not a side tool. Not a second board in another app.

This is its own skill. Drop it at .agents/skills/tracking.md. Pick this file. Do not average it with the others.

`AGENTS.md` is the contract. This file is how work is filed and closed. A visual change still follows UI. A new surface still follows Product. This skill does not replace those. It is the loop around them.

Live: https://design.thorbis.com/skills/tracking

Rules is what we ship. Research is the homework. `DESIGN.md` is the constitution.

This skill holds: AG-001 (search before you create), AG-006 (a structural decision is written down first), AG-007 (say what changed and how you checked it), AG-008 (report failures; do not hide a skipped step), AG-009 (an agent does not approve its own exception), AG-010 (do not merge your own work), AG-011 (if the change is large, split it), D-007 (search the registry the same way), D-011 (gold screens have screenshot baselines).

Homework: Tuomas Artman, papercuts in seven days; the team is trained to see them. Karri Saarinen, quality is the north star; reduce scope. Linear is the board we keep. Grammar, not a second tracker.

thorbis-tracking-SKILL.md

First

Search. Reuse the issue that exists. Do not open a twin.

Search by outcome, by file, by the last title you almost typed. If it is already In Progress, comment and join. Do not file a shadow. Search the registry the same way: a duplicate component is a defect. AG-001. D-007.

If the change is large, split it before you call it done. AG-011.

A structural decision gets written down first. Then you build it. AG-006.

Choose the decision's owning skill using the skill selection policy. Record that owner and any required specialist or mandatory Native context. Do not average competing rules.

File

Every issue has a milestone. If it is not on one, it is not planned.
Titles are outcomes (Focus ring matches accent), not chores (Fix CSS).
One outcome per issue. Description is the brief. Acceptance is a list the next person can check against Rules and the skill you followed.
Papercuts are real. File them. Do not batch “we’ll polish later.”
A due date without a milestone is decoration. Prefer the milestone. Use a date only when the outside world constrains us (launch, payroll, install).
Name the person the work is for. Dispatcher, tech, or owner. Name the profile. Workbench, Guided, Evidence, or Showcase.
Record the owning skill and required context selected under that policy.

Lifecycle

Search → reuse or file → milestone → start → evidence → done.

State	Meaning	You may
Backlog	Not this milestone	Leave it. Do not start it.
Todo	Ready	Start it.
In Progress	Someone is on it	Work it. Leave a note if you stop overnight.
In Review	Built, not checked	Attach evidence. Ask for the check.
Done	Checked. Evidence in the thread.	Nothing. It is closed.

Done means verified. A successful build alone is not completion. Report what each check actually proves and supply the applicable interaction and accessibility evidence.

Leave In Progress overnight only with a note: what landed, what is open, where to pick up.

In Review is not Done. Attach the check. Then close.

Nothing ready sits in Backlog. Nothing unfinished sits in Done.

Evidence

In the thread, say:

What you opened (desktop, 390px, both themes)
What you pressed (keyboard path, ⌘K, the commit)
What you refused (a second shell, a gradient, a solid colored side rail, a word on a mark)
Which skill owned the decision and what additional context was required
A screenshot or a clip when the change is visual

This is AG-007 and AG-008. Report failures. Do not hide a skipped step.

Gold screens have screenshot baselines. D-011. If the screen and DESIGN.md disagree, the constitution wins and the screen is a bug.

Two AG failures: do not ship.

Close

The issue matches reality. Evidence is attached. Blockers are named as their own issues, on a milestone.

An agent does not approve its own exception. A human does. AG-009. A comment in the PR that says “had to” is not an exception.

Do not merge your own work. AG-010.

Worked: a papercut

The miss: hover wash behind a nav word on Jobs.

Search Linear for “nav hover” and “Jobs wash.” Search the registry for the nav primitive.
Reuse the issue if it exists. If not, file: Nav word hover is color only. Milestone: this week’s papercuts. Person: dispatcher. Profile: Workbench. Skill: UI.
Acceptance: no wash behind the word; hover gated to a real mouse; both themes; 390px unchanged.
Build against UI. Do not open Color to invent a grey.
Evidence: desktop hover, a phone (no hover), light and dark, a screenshot of Jobs.
In Review. A human checks. Then Done.

Do not batch this with “also the focus ring, also the empty state.” Those are other issues.

Worked: a large change

The ask: a canvas of workflow nodes.

Write the decision first. Room: Canvas. Occupant: CanvasWorkspace. Surface: route. Skill: Product. AG-006. Product.
Split before you call it done. AG-011. Issues, not a saga:

Workflow is a Canvas occupant of AppShell
A step is a small sheet with trade words
Inspector holds the selected step
Library theme is stripped

Each issue names Product, or UI, or Composition. Not all three.
Evidence on each. Screenshot baselines on the gold screen. D-011.
Do not merge your own work. AG-010.

Report

When you finish, say:

The profile
The pattern
The skill you followed
What you reused
What you refused
How you checked it (desktop, 390px, keyboard, both themes, console)

If you skipped a step, say so. A hidden skip is a defect. AG-008.

Never

A second board in another tool
“I’ll file it later”
Issues with no project or milestone
Marking Done because the build passed
Twin issues for the same outcome
Averaging three skills into one ticket
An exception written as “had to” in a PR
Batching papercuts into a polish epic that never ships
Starting work that sits in Backlog
Closing In Review without evidence

Audit

Linear searched. Issue reused or filed. AG-001
Milestone present
Title is an outcome
One skill named
Person and profile named
Evidence in the thread. AG-007
Failures reported. AG-008
No self-exception. AG-009
Someone else merges. AG-010
Large work is split. AG-011
Gold screen has a baseline if the change is visual. D-011

Two failures: do not ship.

Done

The issue matches the screen. Evidence is in the thread. The next person could check it against Rules and the skill you named.

Applied bookmark research

Reviewed 2026-09-06. These are Thorbis applications and review exercises, not replacements for DESIGN.md, COMPONENTS.md, or the owning skill. Linear remains the operational baseline. External advice that conflicts with the constitution stays out.

These worked examples are not a claim that the product behaviors have been implemented or verified.

Close the loop with evidence, not the word polished

Owning skill: tracking.

Vague design requests produce repeated subjective revisions and hide which parts of the result were actually checked.

A review records the person and task, the observed defect, the owning rule, the smallest correction, and its verification. Preserve source access limits. Turn repeated feedback into a better existing default rather than another detached instruction file.

Thorbis example: Instead of make the button premium, record that its pending state moves the label, identify the UI owner, compare the corrected state under the same content, and attach the relevant checks and remaining uncertainty.

Verify: Separate a source that was read from a demo that was exercised. Separate a passing content test from a browser check, and a committed branch from a deployed release. Report failed and skipped checks explicitly.

Do not import: No fabricated research, inferred paid lesson content, unmeasured uplift claim, or declaring work live because a commit exists.

Evidence: Agents with Taste (opens in a new tab); Train Your Judgement (opens in a new tab); Developing Taste (opens in a new tab); How we think about design (opens in a new tab); Design Engineer Principles (opens in a new tab). Source access limits.

All 26 sources and review limits.

All skills

The bundle includes every skill. Use Resources to choose the smallest context for a task.