sdapp-jira-log

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.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "sdapp-jira-log" with this command: npx skills add ytl-cement/coding-buddy/ytl-cement-coding-buddy-sdapp-jira-log

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

#KeySummaryTypePriority
1PROJ-123Fix login bugStoryHigh
2PROJ-124Update API docsTaskMedium

To Do

#KeySummaryTypePriority
3PROJ-456Add feature XTaskMedium
4PROJ-789Refactor auth moduleStoryLow

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:

#TicketSummaryHours
1PROJ-123Fix login bug2h
2PROJ-124Update API docs2h
3PROJ-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:

TicketSummaryHours
PROJ-123Fix login bug2h
PROJ-124Update API docs2h

Total: 4 hours logged across 2 tickets.

If any tickets failed, list them separately:

Failed to log:

  • PROJ-456 - Add feature X (Error: <reason>)

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

sdapp-commit

No summary provided by upstream source.

Repository SourceNeeds Review
General

unit-testing

No summary provided by upstream source.

Repository SourceNeeds Review
General

debugging

No summary provided by upstream source.

Repository SourceNeeds Review