From jira
Use when the user assigns a ticket to the agent, says "work on this ticket", "pick up this item", or wants the agent to claim a ticket and execute against it. Procedural harness that wraps any work with Jira discipline.
npx claudepluginhub jackhutson/workflow-toolkit-plugins --plugin jiraThis skill uses the workspace's default tool permissions.
Procedural workflow that wraps any work the agent does with Jira discipline — claim at start, update when blocked, report at end. The skill defines WHEN to update Jira, not WHAT the work is.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Procedural workflow that wraps any work the agent does with Jira discipline — claim at start, update when blocked, report at end. The skill defines WHEN to update Jira, not WHAT the work is.
Before any transition, look up the project in config/workflows.json:
PL-3718 → PL)projects.PROJECT_KEY exists in the configjira-workflow skill for this project, then re-readstatuses mapping to resolve stage names (start, block, done) to actual Jira status namesAssign the ticket and signal that work is starting:
acli jira workitem assign --key "KEY-123" --assignee "user@email.com"
acli jira workitem transition --key "KEY-123" --status "START_STATUS" --yes
acli jira workitem comment-create --key "KEY-123" --body "Picked up by agent — starting work"
Where START_STATUS is resolved from config/workflows.json → projects.PROJECT_KEY.statuses.start.
If the ticket is already assigned to the current user, skip the assign step. If already in the start status, skip the transition.
Load the full ticket context to understand what needs to be done:
acli jira workitem view KEY-123 --fields "key,summary,status,assignee,priority,issuetype,description" --json
acli jira workitem search --jql "parent = KEY-123" --fields "key,summary,status" --csv
acli jira workitem comment-list --key "KEY-123"
Parse from the description:
Do the work described in the ticket. This is intentionally open — the work could be:
The skill defines the Jira checkpoints, not the work itself.
If blocked:
acli jira workitem transition --key "KEY-123" --status "BLOCK_STATUS" --yes
acli jira workitem comment-create --key "KEY-123" --body "Blocked: [describe the blocker]"
Where BLOCK_STATUS is resolved from config/workflows.json → projects.PROJECT_KEY.statuses.block.
Stop and report to the user.
If a scope question arises:
acli jira workitem comment-create --key "KEY-123" --body "Question: [the question]"
Ask the user before proceeding.
When work is finished:
acli jira workitem comment-create --key "KEY-123" --body "Completed: [summary of what was done, what changed, any follow-ups]"
acli jira workitem transition --key "KEY-123" --status "DONE_STATUS" --yes
Where DONE_STATUS is resolved from config/workflows.json → projects.PROJECT_KEY.statuses.done.
If code was written, include the branch name or PR link in the completion comment.
The user can specify a preferred completion status (e.g., review instead of done). Resolve via the config mapping.
If ACLI returns exit code != 0:
acli jira auth login --web --site <site>.atlassian.netbrew tap atlassian/homebrew-acli && brew install aclijira-workflow.