argos-harness 0.1.0

package/assets/skills/jira-epic/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: jira-epic
+description: Creates Jira epics for large features following Prowler's standard format. Trigger: When the user asks to create an epic, a large feature, or a multi-task initiative.
+---
+
+## When to Use
+
+Use this skill when creating Jira epics for:
+- Large features spanning multiple components
+- New views/pages in the application
+- Major refactoring initiatives
+- Features requiring API + UI + SDK work
+
+## Epic Template
+
+```markdown
+# {Epic Title}
+
+**Figma:** {figma link if available}
+
+## Feature Overview
+
+{2-3 paragraph description of what this feature does and why it's needed}
+
+## Requirements
+
+### {Section 1: Major Functionality Area}
+
+#### {Subsection}
+- Requirement 1
+- Requirement 2
+- Requirement 3
+
+#### {Another Subsection}
+- Requirement 1
+- Requirement 2
+
+### {Section 2: Another Major Area}
+
+#### {Subsection}
+- Requirement 1
+- Requirement 2
+
+## Technical Considerations
+
+### Performance
+- {Performance requirement 1}
+- {Performance requirement 2}
+
+### Data Integration
+- {Data source}
+- {Integration points}
+
+### UI Components
+- {Component 1}
+- {Component 2}
+
+## Implementation Checklist
+
+- [ ] {Major deliverable 1}
+- [ ] {Major deliverable 2}
+- [ ] {Major deliverable 3}
+
+## Diagrams
+
+{Mermaid diagrams for architecture, flow, data model, etc.}
+```
+
+## Epic Title Conventions
+
+Format: `[EPIC] Feature Name`
+
+**Examples:**
+- `[EPIC] Findings View`
+- `[EPIC] Multi-tenant Support`
+- `[EPIC] Compliance Dashboard Redesign`
+- `[EPIC] GovCloud Support`
+
+## Required Sections
+
+### 1. Feature Overview
+Brief but complete description of:
+- What the feature does
+- Who uses it
+- Why it's needed
+
+### 2. Requirements
+Organized by functional area:
+- Group related requirements together
+- Use clear headers and subheaders
+- Be specific and testable
+
+### 3. Technical Considerations
+Always include:
+- **Performance**: Large dataset handling, pagination, caching
+- **Data Integration**: Data sources, APIs, relationships
+- **UI Components**: Reusable components, design system usage
+
+### 4. Implementation Checklist
+High-level deliverables that will become individual tasks:
+- Each checkbox = potential Jira task
+- Order by dependency (API before UI)
+- Include testing milestones
+
+## Diagrams
+
+Use Mermaid for:
+
+### Architecture Diagrams
+```mermaid
+graph TB
+    UI[UI Components] --> API[API Endpoints]
+    API --> SDK[Prowler SDK]
+    SDK --> Cloud[Cloud Providers]
+```
+
+### Data Flow Diagrams
+```mermaid
+sequenceDiagram
+    User->>UI: Apply filters
+    UI->>API: GET /findings?filters
+    API->>DB: Query findings
+    DB-->>API: Results
+    API-->>UI: JSON response
+    UI-->>User: Render table
+```
+
+### State Diagrams
+```mermaid
+stateDiagram-v2
+    [*] --> Pending
+    Pending --> InProgress: Start triage
+    InProgress --> Resolved: Mark resolved
+    InProgress --> Pending: Reset
+    Resolved --> [*]
+```
+
+### Entity Relationship Diagrams
+```mermaid
+erDiagram
+    FINDING ||--o{ RESOURCE : affects
+    FINDING }|--|| CHECK : "belongs to"
+    RESOURCE }|--|| ACCOUNT : "belongs to"
+    ACCOUNT }|--|| PROVIDER : "belongs to"
+```
+
+## Splitting Epic into Tasks
+
+After creating the epic, generate individual tasks using the `jira-task` skill:
+
+### Task Naming Pattern
+From epic `[EPIC] Findings View`, create:
+- `[FEATURE] Findings table with pagination (UI)`
+- `[FEATURE] Findings filters - provider and account (UI)`
+- `[FEATURE] Findings detail panel - Overview tab (UI)`
+- `[FEATURE] Findings detail panel - Resources tab (UI)`
+- `[FEATURE] Findings bulk actions - mute/suppress (API + UI)`
+- `[FEATURE] Findings search functionality (API + UI)`
+
+### Task Dependencies
+Always specify in each task:
+```markdown
+## Related Tasks
+- Epic: [EPIC] Findings View
+- Blocked by: [task if any]
+- Blocks: [task if any]
+```
+
+## Figma Integration
+
+When Figma links are provided:
+- Include main Figma link at top
+- Reference specific frames in relevant sections
+- Example: `https://www.figma.com/design/xxx?node-id=1830-44712&m=dev`
+
+## Output Format
+
+```markdown
+## Epic: [EPIC] {Title}
+
+{Full epic content following template}
+
+---
+
+## Suggested Tasks
+
+Based on this epic, create the following tasks:
+
+| # | Title | Component | Blocked By |
+|---|-------|-----------|------------|
+| 1 | [FEATURE] Task name | API | - |
+| 2 | [FEATURE] Task name | UI | Task 1 |
+| 3 | [FEATURE] Task name | UI | Task 2 |
+
+Would you like me to generate the full task descriptions?
+```
+
+## Checklist Before Submitting
+
+1. ✅ Title follows `[EPIC] Feature Name` format
+2. ✅ Feature Overview explains what/who/why
+3. ✅ Requirements are organized by functional area
+4. ✅ Technical Considerations cover performance, data, UI
+5. ✅ Implementation Checklist has high-level deliverables
+6. ✅ Diagrams included where helpful (Mermaid format)
+7. ✅ Figma links included if available
+8. ✅ Suggested tasks table provided at the end
+
+## Formatting Rules
+
+**CRITICAL:** All output MUST be in Markdown format, ready to paste into Jira.
+
+- Use `#` for epic title, `##` for main sections, `###` for subsections
+- Use `**bold**` for emphasis
+- Use `- [ ]` for checkboxes in Implementation Checklist
+- Use ``` for code blocks and Mermaid diagrams
+- Use `backticks` for file paths, commands, and code references
+- Use tables for Suggested Tasks section
+- Use `---` to separate epic from suggested tasks
+
+## Jira MCP Integration
+
+**CRITICAL:** When creating epics via MCP, use these exact parameters:
+
+### Required Fields
+
+```json
+{
+  "project_key": "PROWLER",
+  "summary": "[EPIC] Feature name",
+  "issue_type": "Epic",
+  "additional_fields": {
+    "customfield_10359": {"value": "UI"}
+  }
+}
+```
+
+### Team Field (REQUIRED)
+
+The `customfield_10359` (Team) field is **REQUIRED**. Options:
+- `"UI"` - Frontend epics
+- `"API"` - Backend epics
+- `"SDK"` - Prowler SDK epics
+
+### 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 epic, update the description with:
+
+```json
+{
+  "customfield_10363": "h2. Feature Overview\n\n{overview}\n\nh2. Requirements\n\n*{Section 1}*\n* {requirement 1}\n* {requirement 2}\n\n*{Section 2}*\n* {requirement 1}\n* {requirement 2}\n\nh2. Technical Considerations\n\n*Performance:*\n* {consideration 1}\n\n*Data Integration:*\n* {consideration 2}\n\nh2. Implementation Checklist\n\n* [ ] {deliverable 1}\n* [ ] {deliverable 2}\n* [ ] {deliverable 3}"
+}
+```
+
+### Linking Tasks to Epic
+
+When creating child tasks, use the epic key as parent:
+
+```json
+{
+  "additional_fields": {
+    "parent": "PROWLER-XXX"
+  }
+}
+```
+
+### Workflow Transitions
+
+```
+Backlog (10037) → To Do (14) → In Progress (11) → Done (21)
+                → Blocked (10)
+```
+
+### MCP Commands Sequence
+
+1. **Create epic:**
+```
+mcp__mcp-atlassian__jira_create_issue (issue_type: "Epic")
+```
+
+2. **Update Work Item Description:**
+```
+mcp__mcp-atlassian__jira_update_issue with customfield_10363
+```
+
+3. **Create child tasks:**
+```
+mcp__mcp-atlassian__jira_create_issue with parent: EPIC-KEY
+```
+
+4. **Assign and transition:**
+```
+mcp__mcp-atlassian__jira_update_issue (assignee)
+mcp__mcp-atlassian__jira_transition_issue (status)
+```
+
+## Keywords
+jira, epic, feature, initiative, prowler, large feature

package/assets/skills/jira-task/SKILL.md

@@ -0,0 +1,382 @@
+---
+name: jira-task
+description: Creates Jira tasks following Prowler's standard format. Trigger: When the user asks to create a Jira task, ticket, or issue.
+---
+
+## 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)
+
+```markdown
+## 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)
+
+```markdown
+## 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:
+```markdown
+## Related Tasks
+- Parent: [Parent task title/link] (for child tasks)
+- Blocked by: [API task title/link]
+- Blocks: [UI task title/link]
+```
+
+## Task Template
+
+```markdown
+## 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
+
+| Priority | Criteria |
+|----------|----------|
+| **Critical** | Production down, data loss, security vulnerability |
+| **High** | Blocks users, no workaround, affects paid features |
+| **Medium** | Has workaround, affects subset of users |
+| **Low** | Nice to have, cosmetic, internal tooling |
+
+## Affected Files Section
+
+Always include full paths when known:
+
+```markdown
+## 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):
+
+```markdown
+## Recommended Tasks
+
+### Task 1: [BUG] {Description} (API)
+{Full task content}
+
+---
+
+### Task 2: [BUG] {Description} (UI)
+{Full task content}
+```
+
+### For FEATURES (parent + children):
+
+```markdown
+## 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
+
+```json
+{
+  "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:
+
+```json
+{
+  "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
+
+| Epic | Key | Use For |
+|------|-----|---------|
+| UI - Bugs & Improvements | PROWLER-193 | UI bugs, enhancements |
+| API - Bugs / Improvements | PROWLER-XXX | API bugs, enhancements |
+| LightHouse AI | PROWLER-594 | AI features |
+| Technical Debt - UI | PROWLER-502 | Refactoring |
+
+### 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
+```
+
+2. **Update Work Item Description:**
+```
+mcp__mcp-atlassian__jira_update_issue with customfield_10363
+```
+
+3. **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