AgentSkillsCN

jira-url-work-plan

给定 Jira 问题 URL，通过 jira-cli 获取问题信息，对其进行分析，如有需要可提出澄清问题，将其拆分为适合提交的交付成果，并撰写 Markdown 形式的实施计划。

SKILL.md
--- frontmatter
name: jira-url-work-plan
description: Given a Jira issue URL, fetch the issue via jira-cli, analyze it, ask clarifying questions if needed, split into commit-sized deliverables, and write a Markdown implementation plan.
author: Cristian Oliveira
version: 0.0.1

Jira URL → Commit Plan (Markdown)

When to use this skill (STRICT trigger)

Only use this skill when the user explicitly indicates they want to plan work for a Jira issue, using one of these patterns:

  • •"Let's start work on <JIRA_URL>"
  • •"Plan the work for <JIRA_URL>"
  • •"Break down <JIRA_URL> into commits"
  • •"Create an implementation plan for <JIRA_URL>"

If the user merely shares a Jira URL without one of the above intents, do NOT activate this skill.

Inputs

  • •JIRA_URL (required): full URL to the Jira issue (copy/paste friendly)
  • •OUTPUT_PATH (optional): default .tmp/plans/<ISSUE_KEY>.md

Output

A Markdown file containing:

  • •Ticket summary + Jira URL
  • •Problem statement (1–3 bullets)
  • •Assumptions / unknowns / questions
  • •Proposed solution outline (high level)
  • •Commit-sized deliverables (commit message + scope + acceptance criteria + tests)
  • •Non-goals / cut lines

AVAILABLE TOOLS

  • •jira (ankitpokhrel/jira-cli) is installed and already authenticated/configured.
  • •scripts/fetch_issue.sh - fetches the issue content from Jira
  • •scripts/write_plan.py - Writes the commit plan to a Markdown file

Procedure

1) Extract issue key from URL

  • •Parse the issue key from the URL (common forms include .../browse/PROJ-123, selectedIssue=PROJ-123, etc.).
  • •If extraction fails: ask the user for the issue key OR request a different Jira URL.

2) Fetch issue content

  • •Run: scripts/fetch_issue.sh "<ISSUE_KEY>"
  • •Capture stdout as ISSUE_TEXT.

3) Analyze and detect ambiguity

  • •Extract (best-effort): Summary, Description, Acceptance Criteria/DoD, Constraints, Dependencies, Risks.
  • •Identify missing/ambiguous parts. Examples:
    • •unclear scope (“improve performance” but no target)
    • •missing acceptance criteria
    • •unspecified platforms/environments
    • •unclear API/UI behavior or edge cases

4) Ask follow-up questions (MANDATORY to confirm your assumptions)

If any critical ambiguity exists, you MUST ask follow-up questions BEFORE producing the final commit plan.

Rules:

  • •Ask 3–8 questions max.
  • •Ask only what’s necessary to produce a correct plan.
  • •Prefer multiple-choice / option-style questions when possible.
  • •Do not invent answers. If user cannot answer, document as assumptions and flag risks.

After the user answers:

  • •Update assumptions and proceed.

5) Split into deliverables (commits)

  • •Create 3–12 commits max (unless the ticket is tiny).
  • •Each commit must be independently reviewable and have a clear validation step.
  • •Use Conventional Commits if repo uses it: feat:, fix:, chore:, test:, docs:, refactor:.

6) Write the plan

  • •Run: scripts/write_plan.py --issue-key <ISSUE_KEY> --jira-url <JIRA_URL> --out <OUTPUT_PATH>
  • •Pass ISSUE_TEXT via stdin.

7) Return to user

  • •Provide the output path and a short list of commit titles/messages.

Guardrails

  • •Do not claim you ran commands if you did not.
  • •If user answers are missing, record them as assumptions + risks.
  • •Keep commits concrete (what/why/how to validate).