Jira Log Work

Log work hours to the user's active Jira tickets. The flow is strictly sequential — fetch tickets, let the user pick which ones, ask how many hours, confirm the plan, then log. Never log time without the user's explicit go-ahead.

Steps

Follow these steps exactly in order. Each step depends on the previous one. Do not skip or combine steps.

Step 1: Load Atlassian MCP tools

The Atlassian MCP tools are deferred — load their schemas before calling them.

ToolSearch(query: "select:mcp__atlassian__atlassianUserInfo,mcp__atlassian__searchJiraIssuesUsingJql,mcp__atlassian__getAccessibleAtlassianResources,mcp__atlassian__addWorklogToJiraIssue", max_results: 4)

Wait for this to complete. If addWorklogToJiraIssue is not found, try a broader search:

ToolSearch(query: "atlassian worklog", max_results: 5)

If no worklog tool is available at all, inform the user that their Atlassian MCP server does not support worklog functionality and stop.

Important: Read the returned tool schemas carefully — you will need the exact parameter names for addWorklogToJiraIssue in Step 7.

Step 2: Get user info and cloud ID

Make these two calls in the same message (parallel):

mcp__atlassian__atlassianUserInfo() — returns the user's account details
mcp__atlassian__getAccessibleAtlassianResources() — returns Atlassian sites with cloud IDs

Save the cloudId (the id field from the first accessible resource) for subsequent calls.

Step 3: Fetch tickets

Search for the user's active tickets:

mcp__atlassian__searchJiraIssuesUsingJql(
  cloudId: "<from step 2>",
  jql: "assignee = currentUser() AND status IN (\"To Do\", \"In Progress\") ORDER BY status ASC, priority DESC",
  fields: ["summary", "status", "issuetype", "priority", "project"],
  maxResults: 50
)

If zero tickets are returned, tell the user "No tickets found assigned to you in To Do or In Progress status" but do NOT stop — the user can still log time by entering ticket keys directly in Step 5.

Step 4: Display tickets in a formatted table

Present the tickets in a well-structured markdown table, grouped by status. Each ticket gets a sequential number so the user can reference them easily. Every ticket occupies its own row — never combine or collapse tickets.

Use this exact format:

Here are your active tickets:

### In Progress

| #  | Key        | Summary               | Type   | Priority |
|----|------------|----------------------|--------|----------|
| 1  | PROJ-123   | Fix login bug         | Story  | High     |
| 2  | PROJ-124   | Update API docs       | Task   | Medium   |

### To Do

| #  | Key        | Summary               | Type   | Priority |
|----|------------|----------------------|--------|----------|
| 3  | PROJ-456   | Add feature X         | Task   | Medium   |
| 4  | PROJ-789   | Refactor auth module  | Story  | Low      |

**Total: 4 tickets** (2 In Progress, 2 To Do)

Formatting rules:

One row per ticket — never skip or merge rows
Use a separate table per status group, each under its own ### heading
Include all five columns: #, Key, Summary, Type, Priority
Show a total count at the bottom with a breakdown by status
If a status group has zero tickets, omit that group entirely

Keep a mapping of these numbers to issue keys — you will need it later.

Also let the user know they can enter Jira ticket keys directly (e.g., PROJ-123) if they want to log time to a ticket not shown in the list.

Stop here and wait for the user. Do NOT ask about hours yet. The user must first tell you which tickets they want to log time against.

Step 5: Ask user to enter ticket numbers

Use AskUserQuestion to prompt the user to type in their ticket numbers:

Question: "Enter ticket numbers from the list above, Jira ticket keys (e.g. PROJ-123), or 'all'"
Header: "Ticket Numbers"

The user can type:

Individual numbers from the list: "1" or "3"
Multiple numbers separated by commas: "1,2,3"
A range: "1-3"
The word "all" to select every listed ticket
Jira ticket keys directly: "PROJ-123" or "PROJ-123, PROJ-456"
A mix of both: "1, 2, PROJ-789"

Validation:

For numeric entries, verify they match a ticket from the list. If not, tell the user which number was invalid and ask again.
For Jira ticket keys (anything matching a pattern like ABC-123), accept them as-is — the user may be logging time to tickets not assigned to them, so don't reject them based on the fetched list.

Wait for the response. Do not proceed until the user has entered valid input.

Step 6: Ask for hours to log

Now that you know which tickets the user selected, ask how many hours to log.

Use AskUserQuestion:

Question: "How many hours to log per ticket?"
Header: "Hours"
multiSelect: false
Options:
- "0.5 hours"
- "1 hour"
- "2 hours"
- "4 hours"
- "8 hours (full day)"
The user can also type a custom amount in "Other" (e.g., "1.5", "3h 30m", "45m")

Parse the user's response into a numeric hours value. Support formats like:

Plain numbers: "1.5" → 1.5 hours
Hours shorthand: "3h" → 3 hours
Hours and minutes: "3h 30m" → 3.5 hours
Minutes only: "45m" → 0.75 hours

Wait for the response. Do not proceed until the user has entered hours.

Step 7: Confirm before logging

This is critical — never log work without explicit confirmation. Present a summary table of exactly what will be logged and ask the user to approve:

Here's what I'll log:

| # | Ticket | Summary | Hours |
|---|--------|---------|-------|
| 1 | PROJ-123 | Fix login bug | 2h |
| 2 | PROJ-124 | Update API docs | 2h |
| 3 | PROJ-789 | (manually entered) | 2h |

**Total: 6 hours** across 3 tickets.

For tickets entered by key (not selected from the list), show "(manually entered)" as the summary since we don't have the ticket details. Optionally, you can fetch the ticket summary first using searchJiraIssuesUsingJql with key = "PROJ-789" to display a proper summary — but this is not required.

Use AskUserQuestion:

Question: "Confirm logging the above hours?"
Header: "Confirm"
multiSelect: false
Options:
- "Yes, log it"
- "No, cancel"

If the user selects "No, cancel", say "Cancelled — no work was logged." and stop. Do not loop back to re-ask. The user can re-invoke the skill if they want to try again.

Only proceed to Step 8 if the user explicitly confirms.

Step 8: Log work to each selected ticket

For each confirmed ticket, call the worklog tool using the parameter names from the schema loaded in Step 1. The typical parameters are:

cloudId — from Step 2
issueIdOrKey — the ticket key (e.g., "PROJ-123")
timeSpentSeconds — hours converted to seconds (hours × 3600)

If the tool also accepts a comment parameter, include a brief note like "Logged via Claude Code".

Run worklog calls in parallel where possible (batch them in one message) to speed things up.

If any call fails, note the failure but continue with the remaining tickets.

Step 9: Display results

Show a summary of what was logged:

Work logged successfully:

| Ticket | Summary | Hours |
|--------|---------|-------|
| PROJ-123 | Fix login bug | 2h |
| PROJ-124 | Update API docs | 2h |

**Total: 4 hours** logged across 2 tickets.

If any tickets failed, list them separately:

Failed to log:
- PROJ-456 - Add feature X (Error: <reason>)

sdapp-jira-log