---
description: Start (or continue) Workcamp-tracked work for the current task
---

<!-- workcamp-template: v1.12.0 -->
Follow the Workcamp work-tracking policy for this task.

Non-negotiable: **no work without a ticket** (open it before coding), **always
log time** on the ticket (and always before closing), and **document what you
learned on a wiki page** rather than only in comments — **tagging that page on
the ticket it came from**.

Steps:

1. Call `get_policy` if you're unsure of the current rules.
2. Determine tracking for this location:
   - Read the nearest pin file — `.workcamp.local.yml` then `.workcamp.yml` —
     searching upward but stopping at the repo boundary. Git isn't required.
   - If it sets `tracking: off`, this location is untracked (planning / scratch /
     personal): work normally, open no ticket and log no time — stop here.
   - If it has a `projectId`, use it.
   - Otherwise call `resolve_project` with this folder's name and a one-line
     description — it searches every project in the camp, including ones I'm not
     a member of — then ask me interactively, offering: (a) an accessible match →
     confirm → pin `projectId` (+ `projectName`) in `.workcamp.yml`; (b) an
     existing project I'm **not** in → with my OK, `request_project_access` (an
     owner approves in the app; `find_project_owner` says who) → pin it but wait
     for approval; (c) a new project → only with my explicit yes →
     `create_project`; (d) **don't track it** → pin `tracking: off` (use
     `.workcamp.local.yml` if the repo is shared). Never auto-create or duplicate
     an existing project. If several projects look similar, list them and let me
     pick the exact one — don't guess (prevents tickets landing in the wrong
     project).
3. If tracked, keep tickets **coarse**: one ticket = one meaningful chunk over a
   few days (a feature, or a batch of fixes through to going live), not one per
   micro-edit. Before opening a new one, check for an open ticket to continue
   (`search_tasks`: status "In Progress", assignee me) and reuse it. Only for a
   genuinely new chunk, call `start_task` with a clear title + description (and
   acceptance criteria). Report the ticket number.
4. As we work, call `log_progress` for each meaningful step or decision.
5. Track **meaningful** time: log the hands-on hours actually spent on THIS
   ticket — not wall-clock/session time, not time on other tasks in between. If I
   resume after days, don't log the gap — add a fresh `log_time` for that day's
   real effort (date defaults to today). Many entries per person/date; never overwrite.
6. **Close on definition of done.** You may close a ticket yourself once its full
   scope / acceptance criteria are met and verified — `log_time`, then
   `complete_task(taskId, projectId, summary, scopeComplete: true)` — and move on
   (`find_next_task`). Don't close eagerly after one small change while I'm
   mid-conversation and likely to add more to the same ticket; keep it In Progress
   and keep working. If unsure the scope is done, ask.
7. **Pick & raise.** Use `find_next_task` to choose what to work on next — you may
   pick up **unassigned** backlog tickets, not only ones assigned to me. Use
   `raise_task` to file unassigned backlog tickets for anyone to pick up later.
   Use `attach_evidence` to attach screenshots/files as proof when it helps.
8. **Wikis hold what outlives the ticket — and the ticket points at them.**
   Before investigating anything, call `search_wikis` for this project — the
   research may already be written up. Afterwards, put findings, decisions and
   reference material on a wiki page (`create_wiki`, or `update_wiki` with
   `mode: "append"`), not in a ticket comment, and pass `taskId` + a one-line
   `brief` so the ticket carries a hint of what the page covers and a clickable
   tag of it. The ticket records what is happening to this work; the wiki records
   what is now known.
9. **Tag entities instead of naming them.** Tickets, milestones, wikis, teams and
   channels can be tagged in any comment or note with `refs: ["wiki:<id>"]` — the
   same `#` tagging the app does, rendering as live clickable chips. Plain-text
   `#Something` links to nothing. `search_refs` finds the id by name.
10. **Check the project brief once.** The first time we work in a project, call
    `ensure_project_brief` — a project's default "Project Description" wiki ships
    full of placeholder text. If it reports `needs_brief`, write a real one from
    the repo and call again with it.

$ARGUMENTS