jira-task（Jira task 前端）

When to Use

Use this skill when creating Jira tasks for:

• Bug reports
• Feature requests
• Refactoring tasks
• Documentation tasks

Multi-Component Work: Split into Multiple Tasks

IMPORTANT: When work requires changes in multiple components (API, UI, SDK), create separate tasks for each component instead of one big task.

Why Split?

• Different developers can work in parallel
• Easier to review and test
• Better tracking of progress
• API needs to be done before UI (dependency)

Bug vs Feature: Different Structures

For BUGS: Create separate sibling tasks

Bugs are typically urgent fixes, so create independent tasks per component:

Task 1 - API:

• Title: [BUG] Add aws_region field to AWS provider secrets (API)
• Must be done first (UI depends on it)

Task 2 - UI:

• Title: [BUG] Add region selector to AWS provider connection form (UI)
• Blocked by API task

For FEATURES: Create parent + child tasks

Features need business context for stakeholders, so use a parent-child structure:

Parent Task (for PM/Stakeholders):

• Title: [FEATURE] AWS GovCloud support
• Contains: Feature overview, user story, acceptance criteria from USER perspective
• NO technical details
• Links to child tasks

Child Task 1 - API:

• Title: [FEATURE] AWS GovCloud support (API)
• Contains: Technical details, affected files, API-specific acceptance criteria
• Links to parent

Child Task 2 - UI:

• Title: [FEATURE] AWS GovCloud support (UI)
• Contains: Technical details, component paths, UI-specific acceptance criteria
• Links to parent, blocked by API task

Parent Task Template (Features Only)

## Description

{User-facing description of the feature - what problem does it solve?}

## User Story

As a {user type}, I want to {action} so that {benefit}.

## Acceptance Criteria (User Perspective)

- [ ] User can {do something}
- [ ] User sees {something}
- [ ] {Behavior from user's point of view}

## Out of Scope

- {What this feature does NOT include}

## Design

- Figma: {link if available}
- Screenshots/mockups if available

## Child Tasks

- [ ] `[FEATURE] {Feature name} (API)` - Backend implementation
- [ ] `[FEATURE] {Feature name} (UI)` - Frontend implementation

## Priority

{High/Medium/Low} ({business justification})

Child Task Template (Features Only)

## Description

Technical implementation of {feature name} for {component}.

## Parent Task

`[FEATURE] {Feature name}`

## Acceptance Criteria (Technical)

- [ ] {Technical requirement 1}
- [ ] {Technical requirement 2}

## Technical Notes

- Affected files:
  - `{file path 1}`
  - `{file path 2}`
- {Implementation hints}

## Testing

- [ ] {Test case 1}
- [ ] {Test case 2}

## Related Tasks

- Parent: `[FEATURE] {Feature name}`
- Blocked by: {if any}
- Blocks: {if any}

Linking Tasks

In each task description, add:

## Related Tasks
- Parent: [Parent task title/link] (for child tasks)
- Blocked by: [API task title/link]
- Blocks: [UI task title/link]

Task Template

## Description

{Brief explanation of the problem or feature request}

**Current State:**
- {What's happening now / What's broken}
- {Impact on users}

**Expected State:**
- {What should happen}
- {Desired behavior}

## Acceptance Criteria

- [ ] {Specific, testable requirement}
- [ ] {Another requirement}
- [ ] {Include both API and UI tasks if applicable}

## Technical Notes

- {Implementation hints}
- {Affected files with full paths}
- {Dependencies or related components}

## Testing

- [ ] {Test case 1}
- [ ] {Test case 2}
- [ ] {Include regression tests}

## Priority

{High/Medium/Low} ({justification})

Title Conventions

Format: [TYPE] Brief description (components)

Types:

• [BUG] - Something broken that worked before
• [FEATURE] - New functionality
• [ENHANCEMENT] - Improvement to existing feature
• [REFACTOR] - Code restructure without behavior change
• [DOCS] - Documentation only
• [CHORE] - Maintenance, dependencies, CI/CD

Components (when multiple affected):

• (API) - Backend only
• (UI) - Frontend only
• (SDK) - Prowler SDK only
• (API + UI) - Both backend and frontend
• (SDK + API) - SDK and backend
• (Full Stack) - All components

Examples:

• [BUG] AWS GovCloud accounts cannot connect - STS region hardcoded (API + UI)
• [FEATURE] Add dark mode toggle (UI)
• [REFACTOR] Migrate E2E tests to Page Object Model (UI)
• [ENHANCEMENT] Improve scan performance for large accounts (SDK)

Priority Guidelines

Affected Files Section

Always include full paths when known:

## Technical Notes

- Affected files:
  - `api/src/backend/api/v1/serializers.py`
  - `ui/components/providers/workflow/forms/aws-credentials-form.tsx`
  - `prowler/providers/aws/config.py`

Component-Specific Sections

API Tasks

Include:

• Serializer changes
• View/ViewSet changes
• Migration requirements
• API spec regeneration needs

UI Tasks

Include:

• Component paths
• Form validation changes
• State management impact
• Responsive design considerations

SDK Tasks

Include:

• Provider affected
• Service affected
• Check changes
• Config changes

Checklist Before Submitting

1. ✅ Title follows [TYPE] description (components) format
2. ✅ Description has Current/Expected State
3. ✅ Acceptance Criteria are specific and testable
4. ✅ Technical Notes include file paths
5. ✅ Testing section covers happy path + edge cases
6. ✅ Priority has justification
7. ✅ Multi-component work is split into separate tasks
8. ✅ Titles are recommended for all tasks

Output Format

For BUGS (sibling tasks):

## Recommended Tasks

### Task 1: [BUG] {Description} (API)
{Full task content}

---

### Task 2: [BUG] {Description} (UI)
{Full task content}

For FEATURES (parent + children):

## Recommended Tasks

### Parent Task: [FEATURE] {Feature name}
{User-facing content, no technical details}

---

### Child Task 1: [FEATURE] {Feature name} (API)
{Technical content for API team}

---

### Child Task 2: [FEATURE] {Feature name} (UI)
{Technical content for UI team}

Formatting Rules

CRITICAL: All output MUST be in Markdown format, ready to paste into Jira.

• Use ## for main sections (Description, Acceptance Criteria, etc.)
• Use **bold** for emphasis
• Use - [] for checkboxes
• Use ``` for code blocks with language hints
• Use backticks for file paths, commands, and code references
• Use tables where appropriate
• Use --- to separate multiple tasks

Jira MCP Integration

CRITICAL: When creating tasks via MCP, use these exact parameters:

Required Fields

{
  "project_key": "PROWLER",
  "summary": "[TYPE] Task title (component)",
  "issue_type": "Task",
  "additional_fields": {
    "parent": "PROWLER-XXX",
    "customfield_10359": {"value": "UI"}
  }
}

Team Field (REQUIRED)

The customfield_10359 (Team) field is REQUIRED. Options:

• "UI" - Frontend tasks
• "API" - Backend tasks
• "SDK" - Prowler SDK tasks

Work Item Description Field

IMPORTANT: The project uses customfield_10363 (Work Item Description) instead of the standard description field for display in the UI.

CRITICAL: Use Jira Wiki markup, NOT Markdown:

• h2. instead of ##
• *text* for bold instead of **text**
• * item for bullets (same)
• ** subitem for nested bullets

After creating the issue, update the description with:

{
  "customfield_10363": "h2. Description\n\n{content}\n\n*Current State:*\n* {problem 1}\n* {problem 2}\n\n*Expected State:*\n* {solution 1}\n* {solution 2}\n\nh2. Acceptance Criteria\n\n* {criteria 1}\n* {criteria 2}\n\nh2. Technical Notes\n\nPR: [{pr_url}]\n\nAffected files:\n* {file 1}\n* {file 2}\n\nh2. Testing\n\n* [ ] PR - Local environment\n** {test case 1}\n** {test case 2}\n* [ ] After merge in prowler - dev\n** {test case 3}"
}

Common Epics

Workflow Transitions

Backlog (10037) → To Do (14) → In Progress (11) → Done (21)
                → Blocked (10)

MCP Commands Sequence

1. Create issue:

mcp__mcp-atlassian__jira_create_issue

1. Update Work Item Description:

mcp__mcp-atlassian__jira_update_issue with customfield_10363

1. Assign and transition:

mcp__mcp-atlassian__jira_update_issue (assignee)
mcp__mcp-atlassian__jira_transition_issue (status)

Keywords

jira, task, ticket, issue, bug, feature, prowler