Work

The two moments a task touches all three systems. start opens it: timer running, Jira In Progress, Work row Doing, the brief on screen. stop closes the session on it: timer stopped, Jira moved to where the code says it is, Work row and Actions logged. Everything in between, a forgotten hour or a mid-day note, stays with harvest and work-log.

Read first: ~/.claude/skills/harvest/references/ticket.md (finding and fetching the ticket), ~/.claude/skills/harvest/references/project-ladder.md (Harvest project and task), and the Work database, Actions database and Notion mechanics sections of ~/.claude/skills/work-sync/references/notion.md. stop also reads the Code-state ladder table at the end of ~/.claude/skills/work-sync/references/sources.md.

Hard rules

• Interactive only. The user is at the keyboard; this never runs from launchd. A subagent may run it read-only to test it, printing every write and question instead of making or asking them.
• This is the one place in these skills that writes to Jira, and only transitionJiraIssue and the assignee via editJiraIssue, on the ticket being started or stopped. Comments, other fields and worklogs stay untouched. Jira calls use the mcp__atlassian__* tools with cloudId https://{{ATLASSIAN_SITE}}.atlassian.net.
• Harvest writes are start_timer and stop_timer; existing entries keep their hours and notes, and get_account_settings is re-read only when a write is rejected. Notion writes follow work-log's rules: never Last synced; Code state, PR Link and Due belong to the sync.
• One block, then the writes. Every write appears as System old → new before it happens; the Harvest line's new value is the harvest skill's statement <client> / <project> [<code>] · <task> · "<notes>". A stop transition in Jira is always confirmed; the rest go on the start gate below.
• Partial failure is reported per system: what was written, what was not, and the command that finishes it by hand (/harvest start KEY, /work-log KEY doing).
• Slack is read at start only, never written. When the Slack tools are absent, the Recent Slack section is left out and nothing else changes.

start

1. Resolve. Key or free text per ticket.md, then the fetch. Free text → Harvest only, plus the Work row when one's title matches; say that Jira is skipped. The review flag comes with the key. No review word in the argument → gh pr list --head "$(git branch --show-current)" --state open --json number,url,author; an open PR by someone other than the user makes it a review, and the block says so.
2. Gather, in parallel:
   • Harvest: project and task per the ladder (a review takes Testing and the - reviewing PR notes suffix; the ladder's Task section has the rule); get_running_timer.
   • Jira: getTransitionsForJiraIssue; status and assignee came with the fetch.
   • Notion: open rows for the key, WHERE ("Status" != 'Done' OR "Status" IS NULL) AND ("Jira Code" = ? OR "Title" LIKE ?) on the Work data source; several share the key → keep the one whose title describes this work.
   • Slack: slack_search_public_and_private with keywords: ["<KEY>"], natural_language_query: "", sort: timestamp, limit: 5; read the thread of each hit from the last 30 days. Only with the user's standing consent to read private channels and DMs (recorded in their CLAUDE.md); without it, use the public search tool. Free text with no key → skip.
3. Decide the writes.
   • Harvest: same key already running → "already running, Xh", no Harvest write. Another timer from today → it will be switched; its ticket's Jira and Work row stay as they are, because a switch is not a stop. A timer from an earlier day → stop here and show it; it needs fixing in Harvest by hand before anything starts.
   • Jira: status already In Progress-like (name contains "progress") → no transition. Otherwise the transitions whose target status contains "progress": several to the same target → take the first and name the others; targets that differ, or none → ask with the list. Unassigned → assign to the user (atlassianUserInfo for the account ID). Assigned to someone else → ask before taking it.
   • Jira on a review: the board's review status comes first. Status already review-like (name contains "review") → no transition. Otherwise a transition whose target status contains "review" (boards name it differently: Review, Dev review, Code Review) → take it; several → the first, name the others. No such transition → the "progress" rule above. Assigned to someone else → take it without asking; the implementer gets it back at stop.
   • Notion: one row → Status Doing, whatever the sync last wrote; the user starting is the freshest statement of intent. Since today when Status changes and Since is not already today. No row → create per work-log §4 with Status Doing. Several → ask which. On a review, Next step = You: review <repo>#<n>.
4. Gate. Go without asking when the key came from the argument or branch, the project is strong, the Jira transition is unambiguous, and the Notion match is one row or none. Anything else → one AskUserQuestion with a question per open item (project, transition, row, assignee), recommendation first, runners-up after.
5. Write in this order: Harvest, Jira, Notion. The timer first: time is the one thing that cannot be recovered.
6. Report the block as written, then the brief: ticket summary and issue type, on a review the PR's number, author and review decision too, the whole description when it is under 40 lines, else its acceptance criteria section when it has one, else the first 15 non-blank lines; then the row's Notes and Next step as "where you left off"; then Recent Slack: up to five lines, newest first, <day> <who>: <one-line gist> — <permalink>, with a question to the user that nobody answered marked unanswered. No hits → no section. The user chose a project the ladder did not recommend → append the row to harvest/references/learned.md as the harvest skill does, keyed <KEY>/<repo> for a derived-client ticket.

Done when: a timer runs on the key, Jira and the Work row both say in progress (or the block says why not), and the brief is on screen.

stop

1. Stop the clock first. get_running_timer. Running → stop_timer at once and keep the hours; the discussion below is not billable. The timer's notes name the ticket: a key there beats the branch, and the argument beats both. Notes ending - reviewing PR mark the session a review; so does a review word in the argument. Nothing running → say so, resolve the key per ticket.md, carry on with Jira and Notion.
2. Gather, in parallel:
   • Jira: the fetch (status, assignee) and getTransitionsForJiraIssue.
   • Code, from the working directory: git status --porcelain (uncommitted), git log @{upstream}..HEAD --oneline (unpushed; no upstream → say so), git log --since="<timer_started_at>" --oneline (this session's commits), and gh pr list --head "$(git branch --show-current)" --state all --json number,url,isDraft,reviewDecision,mergedAt,baseRefName,reviewRequests,author for the branch's PR. Map to a Code state rung with the table in sources.md; a merged PR needs the compare in that ladder before it counts as staging or production.
   • Notion: the row, as in start.

3. Propose the Jira status from the code state. The user's words in the argument win over the table ("sent for review", "finished"; work-log's word → status map applies):

   Code state	Jira target (transition name or target status contains)	Work row
   No branch, Branch, PR draft	stays in progress, no transition	Doing; Next step = You: <what is left>
   PR awaiting review / changes requested / approved	review	Waiting; Waiting on = the requested reviewer (login when that is all there is); Next step = <Reviewer>: review <repo>#<n>
   On staging	test or qa	Waiting; Waiting on = the tester, asked when unknown
   In production	live, deploy or done; several fit → ask	Doing while the deploy is the user's; Done once the ticket closes
   The user says finished	done or closed	Done

   Current status already matches → no transition, say so. Exactly one transition fits → propose it. None or several → ask with the full transition list.

   Review session: the table does not apply. The status stays where it is, whatever the code state: the implementer merges, stages and deploys, and moves the ticket as they go. The assignee goes back to the implementer, who is the PR author: gh api users/<login> -q .name, then lookupJiraAccountId on that name; no single match → the ticket's reporter; still unclear → ask. Work row: Done when the user approved, because their part is finished; Waiting when they requested changes, Waiting on = the implementer, Next step = <Implementer>: address the review on <repo>#<n>.

4. Draft the Actions entry: one line under 20 words in the user's voice, from the session's commits and the conversation: Fixed the open-tracking double count; PR up for Sam. Type Coded when commits exist, Investigated when none, Reviewed when the session reviewed; the user can change it. Source You, Work = the row, Date empty (the automation stamps it). Notes = one line on where it stands. Since = today only when Status or the owner changed.
5. Confirm. One block: hours stopped, Jira <current> → <target> and, on a review, assignee <user> → <Implementer>, each Notion field old → new, the Action line with its Type, and the git lines (3 uncommitted files, 2 unpushed commits) as warnings only; nothing here commits or pushes. The user says yes or edits.
6. Write: Jira, then Notion (update_properties, notion-create-pages on Actions; 429 → wait retry_after, retry). Report one line per write and end with the row URL.

Done when: no timer runs on the key, the Jira status and the Work row agree on whose move it is, an Actions entry exists for the session, and any uncommitted or unpushed work has been named.

Common mistakes

• Asking before stopping the timer, so the Q&A gets billed.
• Treating a switched-away timer at start as a stop and moving that ticket to Waiting.
• Proposing a Jira status from its name rather than the code state; "whose move" decides.
• Setting Since on a Notes-only change, or writing Last synced.
• Re-asking the whole block when the only open item is the project.
• Taking a review ticket to In Progress when the board has a review status.
• Moving a reviewed ticket's status at stop. The implementer owns merge, staging and deploy; only the assignee changes.