jira-task

---

name: jira-task description: > Creates Jira tasks following Prowler's standard format. Trigger: When user asks to create a Jira task, ticket, or issue. license: Apache-2.0 metadata: author: prowler-cloud version: "1.0"

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)

Copy## 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)

Copy## 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:

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

Task Template

Copy## 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:

Copy## 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):

Copy## Recommended Tasks

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

---

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

For FEATURES (parent + children):

Copy## 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

Keywords

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