/stop-work — Stop Tracking and Log Time

You are stopping work on the current Jira issue, building a worklog, and posting it to Jira.

Path Resolution

PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(ls -d ~/.claude/plugins/cache/moonsite-claude-extensions/jira-autopilot/*/ 2>/dev/null | sort -V | tail -1)}"
CLI="${PLUGIN_ROOT}hooks-handlers/jira_core.py"

Resolve PROJECT_ROOT by walking up to find .claude/jira-autopilot.json (handles git worktrees):

_dir="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"
PROJECT_ROOT=""
while [ "$_dir" != "/" ]; do
  [ -f "$_dir/.claude/jira-autopilot.json" ] && PROJECT_ROOT="$_dir" && break
  _dir="$(dirname "$_dir")"
done
[ -z "$PROJECT_ROOT" ] && _mr="$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null | sed 's|/\.git$||')" && [ -f "$_mr/.claude/jira-autopilot.json" ] && PROJECT_ROOT="$_mr"
[ -z "$PROJECT_ROOT" ] && PROJECT_ROOT="${CLAUDE_PROJECT_DIR:-$(pwd)}"

---

Step 1: Read Session and Config

python3 "$CLI" get-session "$PROJECT_ROOT"

Read the config:

cat "$PROJECT_ROOT/.claude/jira-autopilot.json"

If there is no active task (currentIssue is null or empty):

• Inform the user: "No active task being tracked. Run /start-work to begin tracking."
• If there are pending worklogs or unattributed work, suggest running /approve-work.
• Exit.

Get the current issue key and autonomy level.

Step 2: Build Worklog

python3 "$CLI" build-worklog "$PROJECT_ROOT" "ISSUE_KEY"

Returns:

{
  "issueKey": "KEY-42",
  "seconds": 1800,
  "summary": "Edited auth.ts, login.tsx",
  "rawFacts": {
    "files": ["src/auth.ts", "src/login.tsx"],
    "commands": ["npm test"],
    "activityCount": 12
  },
  "logLanguage": "English"
}

If no work was tracked (seconds == 0 and no activities), inform the user and ask if they still want to stop tracking the issue.

Step 3: Enrich Summary (CRITICAL — MANDATORY)

STOP. READ THIS BEFORE PROCEEDING.

You MUST write a human-readable worklog description. This is NOT optional. If you skip this step or post raw technical output, the worklog is useless to the user.

NEVER post any of these to Jira:

• Raw activity types like "Activity: Jira, Created"
• File paths (full or partial)
• Tool names (Edit, Bash, Write, MCP tools)
• Anything that looks like code or logs

Read logLanguage from the project config. ALL worklog text MUST be in this language (e.g. if "Hebrew" → write in Hebrew, not English).

Write the worklog description yourself based on the rawFacts:

• 2-4 sentences describing what was accomplished in human terms
• Use basenames only (e.g. "budgetsTable.component.tsx"), never full paths
• Describe the purpose of changes, not just list files (e.g. "עדכון טבלת תקציבים — הוספת עמודות סטטוס וסינון לפי תאריך" instead of "Edited: budgetsTable.component.tsx, filters.ts")
• No raw commands, hashes, tool names, or internal details
• Write in the configured logLanguage

SELF-CHECK before posting: Does your description contain any English technical terms like "Activity:", "Created", "Edited", "Tool", "Bash"? If yes, REWRITE it in proper logLanguage.

Bad example (NEVER do this):

Work session: Files: /Users/boris/Source/project/src/components/table.tsx, /Users/boris/Source/project/src/utils/api.ts Tools: Edit, Bash, Write

Good example (Hebrew):

עדכון רכיב הטבלה — הוספת עמודות חדשות, תיקון מיון ושיפור ביצועים. עדכון שכבת ה-API עם endpoints חדשים.

Good example (English):

Updated table component — added new columns, fixed sorting, improved performance. Updated API layer with new endpoints.

Step 4: Calculate Display Time

Read timeRounding and accuracy from config.

Time rounding rules:

• High accuracy (8-10): granularity = max(timeRounding / 15, 1) minutes
• Low accuracy (1-3): granularity = timeRounding * 2
• Medium (4-7): granularity = timeRounding

Always round UP. Minimum one rounding increment (never zero).

Show both actual and rounded time:

Actual time: 27 minutes
Rounded time: 30 minutes (rounded up to 15-min increments)

If the time exceeds 4 hours (14400 seconds), cap it and inform the user:

Time capped at 4 hours (actual: 5h 12m). This is the maximum for a single worklog.

Step 5: Approval Flow

Autonomy C (Cautious) — 5-Option Approval

Present the worklog summary and time to the user, then offer 5 options:

Worklog for KEY-42: {summary}
Time: {rounded_time}
Files: {file_list}

Options:
1. Approve — post this worklog to Jira
2. Approve + go silent — approve this and auto-approve future worklogs for this issue
3. Edit summary — modify the worklog description before posting
4. Log to different issue — redirect this worklog to another issue
5. Reject — keep for later (deferred) or drop entirely

Handle each option:

1. Approve: proceed to Step 6.
2. Approve + silent: set autoApproveWorklogs: true for this issue in session, then proceed to Step 6.
3. Edit summary: let the user provide a new summary, then re-present for approval.
4. Log to different issue: ask which issue key to use, re-attribute the worklog, then re-present.
5. Reject: ask "Keep for later (can approve via /approve-work) or drop entirely?"
   • Keep: save worklog with status: "deferred".
   • Drop: save worklog with status: "dropped".

Autonomy B (Balanced)

Show the worklog summary and time, then auto-approve after a brief display:

Posting worklog for KEY-42: {summary} ({rounded_time})

Autonomy A (Autonomous)

Silent post with one-line confirmation:

Logged {rounded_time} to KEY-42.

Step 6: Post Worklog to Jira

The SUMMARY_TEXT must be the enriched human-readable description from Step 3, NOT raw file paths or tool names.

echo '{"issueKey":"ISSUE_KEY","seconds":SECONDS,"comment":"SUMMARY_TEXT"}' | python3 "$CLI" add-worklog "$PROJECT_ROOT"

If posting fails:

• Mark the worklog as status: "failed".
• Inform the user: "Failed to post worklog. It has been saved and can be retried via /approve-work."

If posting succeeds:

• Mark the worklog as status: "posted".

Step 7: Post Work Summary Comment

If there were work chunks for this issue, post a summary comment to the Jira issue:

python3 "$CLI" add-comment "$PROJECT_ROOT" "ISSUE_KEY" "COMMENT_TEXT"

The comment should summarize what was done (files changed, key actions) in the configured language.

Step 8: Update Session State

python3 "$CLI" stop-tracking "$PROJECT_ROOT" "ISSUE_KEY"

This should:

• Remove the issue from activeIssues.
• Set currentIssue to null (or the next active issue if multiple are being tracked).
• Clear processed work chunks for this issue.

Step 9: Display Final Summary

Stopped tracking KEY-42: {summary}
Time logged: {rounded_time}
Worklog: {status}

Step 10: Branch Cleanup

Check if on a feature branch:

CURRENT_BRANCH=$(git branch --show-current 2>/dev/null)

If the branch contains the issue key:

Autonomy C:

Offer 3 options:

1. Open PR — push branch and create a pull request.
2. Keep working — stay on this branch.
3. Switch to main — git checkout main (or master/develop).

Autonomy B/A:

If there are unpushed commits, auto-suggest opening a PR:

You have unpushed commits on {branch}. Consider opening a PR.

---

Error Handling

• If no config exists: tell the user to run /jira-setup first.
• If no session exists: tell the user no work has been tracked.
• If Jira API fails: save the worklog as "failed" and inform the user it can be retried.
• If git operations fail: continue without branch cleanup, inform the user.