Ticket worker

Work on a single ticket from start to finish. Follow each step in order. Do not skip verification.

Workflow

1. Read the ticket

tk show <id>

Check that the ticket has the

ready-for-development

tag. If it doesn't, stop — the ticket is not refined enough for automated work. Add a note and exit:

tk add-note <id> "Skipped: ticket not tagged ready-for-development. Needs refinement before work can start."

If the tag is present, mark the ticket as in progress:

tk start <id>

Understand the title, description, acceptance criteria, and any file hints.

2. Explore the codebase

• If

  lat.md/

  exists at project root: run

  lat search

  with keywords from the ticket title and description. Read relevant sections with

  lat section

  to understand the architecture before exploring code files.
• Read the files mentioned in the description
• grep for relevant patterns, function names, imports
• Understand the scope of changes needed
• Do not start implementing yet

3. Discover verification commands

Check these files in order to find how to build, test, and lint:

1. devenv.nix

   — look for

   scripts

   ,

   tasks

   ,

   processes

   ,

   git-hooks

   , test commands

2. package.json

   — look for

   scripts.test

   ,

   scripts.lint

   ,

   scripts.build

3. Makefile

   — look for

   test

   ,

   lint

   ,

   check

   ,

   build

   targets

4. flake.nix

   — look for

   checks

Remember what you find. You will need these after every change.

4. Implement incrementally

• Make one focused change
• Run the verification commands you discovered in step 3
• If broken: fix before moving on
• If context is getting heavy: commit what you have, stop — the next session can continue

5. Verify each acceptance criterion

Go through the acceptance criteria one by one. For each criterion:

• If it specifies a command: run that command and check the output
• If it says "tests pass": run the test suite
• If it says "linter clean": run the linter
• If it is behavioral: verify by reading the changed code or running relevant commands
• Explicitly state whether each criterion passes or fails

If

lat.md/

exists at project root: run

lat check

. If it fails, update

lat.md/

to reflect your changes and re-run until it passes. The ticket is not complete with a failing

lat check

.

Do not declare victory until every criterion is verified.

6. Commit and close

If all acceptance criteria pass:

1. Commit using the conventions in the

   git-commit

   skill (

   git commit -S -m "type(scope): description"

   ). If

   lat.md/

   was updated, include those changes in the same commit.
2. Close the ticket:

   tk close <id>

   (not

   done

   —

   done

   is not a valid status)
3. Add a summary note:

   tk add-note <id> "Summary of what was done"

7. If stuck

If you cannot complete the ticket:

1. Add a note to the ticket explaining the blocker:

   tk add-note <id> "Blocked because..."

2. Do not close the ticket
3. Commit any partial progress if it makes sense
4. Exit cleanly

Rules

• Verify, don't assume. Run the commands. Check the output.
• Stay focused. Only change files relevant to the ticket.
• No bonus refactoring. Fix what the ticket asks, nothing more.
• Weak acceptance criteria? Fall back to: description satisfied + existing tests pass.
• One ticket per session. Don't carry context from unrelated work.
• Work in the current checkout. The pipeline handles worktree setup (task-pipeline skill). When invoked manually or via work-tickets.sh, just work in the current directory.
• Commit message format. Always use conventional commits, single line, GPG-signed, no AI attribution.