zhongwei/gh-openshift-eng-ai-helpers-plugins-jira
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:46:00 +08:00
commit 2109c2330b
22 changed files with 9156 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

744
skills/create-feature-request/SKILL.md Normal file
View File

@@ -0,0 +1,744 @@
---
name: Create Jira Feature Request
description: Implementation guide for creating Feature Requests in the RFE project
---
# Create Jira Feature Request
This skill provides implementation guidance for creating Feature Requests in the RFE Jira project, which captures customer-driven enhancement requests.
## When to Use This Skill
This skill is automatically invoked by the `/jira:create feature-request RFE` command to guide the feature request creation process.
## Prerequisites
- MCP Jira server configured and accessible
- User has permissions to create issues in the RFE project
- Understanding of the customer need and business justification
- Knowledge of affected components/teams
## What is a Feature Request?
A Feature Request (RFE) is:
- A **customer-driven request** for new functionality or enhancement
- Submitted to the **RFE project** in Jira
- Captures **business requirements** and customer justification
- Links specific **components and teams** that need to implement the request
- Focuses on **what** is needed rather than **how** to implement it
### Feature Request vs Feature vs Story
| Type | Purpose | Project | Example |
|------|---------|---------|---------|
| **Feature Request (RFE)** | Customer request for capability | RFE | "Support for Foo in ProductA managed control planes" |
| Feature | Strategic product objective | CNTRLPLANE, etc. | "Advanced hosted control plane security" |
| Story | Single user-facing functionality | Any | "User can upload custom SSL certificate via console" |
### Feature Request Characteristics
Feature Requests should:
- Clearly state the **customer need** or problem
- Provide **business justification** for the request
- Identify **affected components** and teams
- Be **customer-focused** (what they need, not how to build it)
- Include enough detail for engineering teams to **understand and estimate**
## Feature Request Description Best Practices
### Title
The title should be:
- **Clear and concise** (50-80 characters)
- **Customer-focused** (describes the capability needed)
- **Specific** (not vague or overly broad)
**Good examples:**
```
Support Foo for ProductA managed control planes
Enable pod autoscaling based on custom metrics
Multi-cluster backup and restore for ProductB
```
**Bad examples:**
```
Better security (too vague)
SSL stuff (not specific)
Make autoscaling work better (not clear)
```
### Nature and Description
Clearly describe:
- **What** is being requested (the capability or enhancement)
- **Current limitations** or gaps (what doesn't work today)
- **Desired behavior** (what should happen)
- **Use case** (how customers will use this)
**Good example:**
```
h2. Nature and Description of Request
Customers need the ability to use Foo for ProductA managed control plane endpoints, rather than relying on vendor-provided defaults.
h3. Current Limitation
Today, ProductA clusters use vendor-managed configuration for the API server endpoint. Customers cannot provide their own configuration, which creates issues for:
- Corporate security policies requiring organization-specific settings
- Integration with existing enterprise infrastructure
- Compliance requirements (SOC2, ISO 27001)
h3. Desired Behavior
Customers should be able to:
- Upload their own configuration during cluster creation
- Rotate configuration after cluster creation
- Validate configuration before cluster becomes active
- Receive alerts when configuration changes are needed
h3. Use Case
Enterprise customers with strict security policies need all infrastructure to use internally-managed configuration. This blocks ProductA adoption in regulated industries (finance, healthcare, government) where configuration management is a compliance requirement.
```
**Bad example:**
```
We need better SSL support.
```
### Business Requirements
Explain **why** the customer needs this:
- **Business impact** (what happens without this)
- **Customer segment** affected (who needs this)
- **Regulatory/compliance** drivers (if applicable)
- **Competitive** context (if relevant)
- **Priority** indicators (blocking deals, customer escalations)
**Good example:**
```
h2. Business Requirements
h3. Customer Impact
- **Primary segment**: Enterprise customers in regulated industries (finance, healthcare, government)
- **Affected customers**: 10+ customers have requested this capability
- **Deal blockers**: Multiple active deals blocked by this limitation
- **Escalations**: Several P1 customer escalations due to compliance failures
h3. Regulatory Requirements
- SOC2 Type II compliance requires organization-specific configuration
- ISO 27001 mandates lifecycle management
- Financial services regulations (PCI-DSS) require integration with enterprise infrastructure
- Government contracts require validated configuration chains
h3. Business Justification
Without this capability:
- Cannot close enterprise deals in regulated industries
- Risk losing existing customers to competitors during renewals
- Increasing support burden from compliance audit failures
- Limiting market expansion into high-value segments
h3. Competitive Context
Major competitors (CompetitorA, CompetitorB, CompetitorC) all support this capability for managed Kubernetes control planes. This is a gap that affects product competitive positioning.
```
**Bad example:**
```
Customers need this for security.
```
### Affected Packages and Components
Identify:
- **Teams** that need to implement this (use team names like "HyperShift", "ROSA SRE")
- **Operators** or controllers affected (e.g., "cluster-ingress-operator")
- **Components** in Jira (this will be set as the Component field)
- **Related services** (APIs, CLIs, consoles)
**Good example:**
```
h2. Affected Packages and Components
h3. Teams
- **HyperShift Team**: Control plane infrastructure, configuration management
- **ROSA SRE Team**: Operational validation, configuration rotation
- **OCM Team**: Console and API for configuration upload
- **Networking Team**: Networking and configuration distribution
h3. Technical Components
- **cluster-ingress-operator**: Configuration provisioning and installation
- **hypershift-operator**: Control plane configuration
- **openshift-console**: UI for configuration upload and management
- **rosa CLI**: CLI support for configuration operations
h3. Jira Component
Based on the primary team and technical area, this should be filed under:
**Component**: HyperShift / ProductA
h3. Related Services
- Product API (configuration upload endpoint)
- Configuration management service (validation, storage)
- Control plane API server (configuration installation)
```
**Note:** The "Jira Component" will be used to set the `components` field when creating the issue.
## Interactive Feature Request Collection Workflow
When creating a feature request, guide the user through these specific questions:
### 1. Proposed Title
**Prompt:** "What is the proposed title for this feature request? Make it clear, specific, and customer-focused (50-80 characters)."
**Validation:**
- Not too vague ("Better performance")
- Not too technical ("Implement TLS 1.3 in ingress controller")
- Customer-facing capability
**Example response:**
```
Support Foo for ProductA managed control planes
```
### 2. Nature and Description
**Prompt:** "What is the nature and description of the request? Describe:
- What capability is being requested
- Current limitations
- Desired behavior
- Use case"
**Probing questions if needed:**
- What doesn't work today that should?
- What would you like to be able to do?
- How would customers use this capability?
**Example response:**
```
Customers need to use Foo for ProductA API endpoints instead of vendor-provided defaults.
Current limitation: ProductA only supports vendor-managed configuration, blocking customers with corporate requirements.
Desired behavior: Customers can upload, validate, and rotate custom configuration for the control plane API.
Use case: Enterprise customers in regulated industries (finance, healthcare) need organization-specific configuration for compliance.
```
### 3. Business Requirements
**Prompt:** "Why does the customer need this? List the business requirements, including:
- Customer impact and affected segment
- Regulatory/compliance drivers
- Business justification
- What happens without this capability"
**Helpful questions:**
- Who is asking for this? (customer segment)
- Why is this blocking them? (compliance, policy, competitive)
- What is the business impact? (deals, escalations, churn risk)
- Are there regulatory requirements?
**Example response:**
```
Customer impact:
- 10+ enterprise customers have requested this
- Multiple active deals blocked
- Several P1 escalations from compliance failures
Regulatory requirements:
- SOC2, ISO 27001, PCI-DSS require organization-specific configuration
- Government contracts require validated configuration chains
Business justification:
- Cannot close deals in regulated industries (finance, healthcare, government)
- Competitive gap (CompetitorA, CompetitorB, CompetitorC all support this capability)
- Risk of customer churn during renewals
```
### 4. Affected Packages and Components
**Prompt:** "What packages, components, teams, or operators are affected? This helps route the request to the right teams.
Provide details like:
- Team names (e.g., 'HyperShift', 'Networking', 'OCM')
- Operators (e.g., 'cluster-ingress-operator')
- Technical areas (e.g., 'control plane', 'API server')
- Services (e.g., 'OCM console', 'rosa CLI')"
**Follow-up:** After collecting this information, help the user determine the appropriate **Jira Component** value.
**Component mapping guidance:**
- If **HyperShift**, **ProductA**, or **ProductB** mentioned → Component: "HyperShift"
- If **Networking**, **Ingress** mentioned → Component: "Networking"
- If **OCM**, **Console** mentioned → Component: "OCM"
- If **Multi-cluster**, **Observability** mentioned → Component: "Observability"
- If unclear, ask: "Based on the teams and technical areas mentioned, which component should this be filed under?"
**Example response:**
```
Teams affected:
- HyperShift Team (primary - control plane configuration management)
- ROSA SRE Team (configuration rotation, operations)
- OCM Team (console UI for configuration upload)
- Networking Team (networking configuration distribution)
Operators/components:
- cluster-ingress-operator
- hypershift-operator
- openshift-console
Suggested Jira Component: HyperShift
```
## Field Validation
Before submitting the feature request, validate:
### Required Fields
- ✅ Title is clear, specific, and customer-focused
- ✅ Nature and description explains what is requested
- ✅ Business requirements justify why this is needed
- ✅ Affected components and teams are identified
- ✅ Jira Component is set appropriately
- ✅ Project is set to "RFE"
- ✅ Issue type is "Feature Request"
### Content Quality
- ✅ Describes customer need (not implementation details)
- ✅ Business justification is clear
- ✅ Enough detail for engineering teams to understand
- ✅ No vague statements ("better performance", "more secure")
- ✅ Use case is explained
### Security
- ✅ No credentials, API keys, or secrets in any field
- ✅ No confidential customer information (use anonymized references if needed)
## MCP Tool Parameters
### Basic Feature Request Creation
```python
mcp__atlassian__jira_create_issue(
project_key="RFE",
summary="<title of feature request>",
issue_type="Feature Request",
description="""
<Brief overview of the request>
h2. Nature and Description of Request
<What is being requested - capability, current limitations, desired behavior, use case>
h2. Business Requirements
h3. Customer Impact
* <Customer segment affected>
* <Number of customers requesting>
* <Deals blocked or escalations>
h3. Regulatory/Compliance Requirements (if applicable)
* <Compliance driver 1>
* <Compliance driver 2>
h3. Business Justification
<Why this is important, what happens without it>
h3. Competitive Context (if applicable)
<How competitors handle this, gaps>
h2. Affected Packages and Components
h3. Teams
* <Team 1>: <Responsibility>
* <Team 2>: <Responsibility>
h3. Technical Components
* <Operator/component 1>
* <Operator/component 2>
h3. Related Services
* <Service 1>
* <Service 2>
""",
components="<component name>", # Based on affected teams/areas
additional_fields={
# NOTE: Custom field IDs need to be discovered for RFE project
# Placeholder examples below - replace with actual field IDs
# "customfield_12345": "<customer name>", # If RFE has customer field
# "customfield_67890": "<priority level>", # If RFE has priority field
"labels": ["ai-generated-jira"],
"security": {"name": "Red Hat Employee"}
}
)
```
### Example: Foo Feature Request
```python
mcp__atlassian__jira_create_issue(
project_key="RFE",
summary="Support Foo for ProductA managed control planes",
issue_type="Feature Request",
description="""
Enable customers to use Foo for ProductA managed control plane API server endpoints, replacing the current vendor-managed approach.
h2. Nature and Description of Request
Customers need the ability to use Foo for ProductA API endpoints rather than relying on vendor-provided defaults.
h3. Current Limitation
ProductA clusters currently use vendor-managed configuration for the API server endpoint. Customers cannot provide their own configuration, which creates issues for:
* Corporate security policies requiring organization-specific settings
* Integration with existing enterprise infrastructure
* Compliance requirements (SOC2, ISO 27001, PCI-DSS)
h3. Desired Behavior
Customers should be able to:
* Upload their own configuration during cluster creation
* Rotate custom configuration after cluster creation without cluster downtime
* Validate configuration before cluster becomes active
* Receive proactive alerts when configuration updates are needed (30 days, 7 days)
* View configuration details in product console
h3. Use Case
Enterprise customers with strict security policies need all infrastructure components to use internally-managed configuration. This capability is required for ProductA adoption in regulated industries (finance, healthcare, government) where configuration management is a compliance requirement and external configuration violates security policies.
h2. Business Requirements
h3. Customer Impact
* **Primary segment**: Enterprise customers in regulated industries (finance, healthcare, government, defense)
* **Affected customers**: 10+ enterprise customers have explicitly requested this capability
* **Deal blockers**: Multiple active enterprise deals are currently blocked by this limitation
* **Escalations**: Several Priority 1 customer escalations due to failed compliance audits
h3. Regulatory/Compliance Requirements
* SOC2 Type II compliance requires use of organization-specific configuration with documented lifecycle management
* ISO 27001 certification mandates configuration lifecycle management and infrastructure integration
* PCI-DSS (Payment Card Industry) requires configuration from approved infrastructure
* Government contracts (FedRAMP, DoD) require validated configuration chains
* Industry-specific regulations (HIPAA, GDPR) require organizational control of configuration
h3. Business Justification
Without this capability:
* Cannot close enterprise deals in regulated industries (blocking market expansion)
* Risk losing existing customers to competitors during renewal periods
* Increasing support burden from compliance audit failures and customer escalations
* Limiting addressable market to non-regulated segments
* Missing revenue opportunity in high-value enterprise segments
h3. Competitive Context
All major competitors support this capability for managed Kubernetes control planes:
* CompetitorA: Supports custom configuration via service manager
* CompetitorB: Allows bring-your-own configuration for API server
* CompetitorC: Supports custom configuration for control plane endpoints
This is a competitive gap affecting ProductA positioning in enterprise sales cycles.
h2. Affected Packages and Components
h3. Teams
* **HyperShift Team**: Primary owner - control plane infrastructure, configuration management, rotation logic
* **ROSA SRE Team**: Operational validation, configuration rotation procedures, monitoring and alerting
* **OCM Team**: Console UI for configuration upload, validation, and lifecycle management
* **Networking Team**: Networking configuration, configuration distribution to load balancers
* **Security Team**: Configuration validation, security review, key management
h3. Technical Components
* **hypershift-operator**: Control plane configuration and installation
* **cluster-ingress-operator**: Configuration provisioning for API server
* **openshift-console**: UI components for configuration upload and management
* **rosa CLI**: CLI commands for configuration operations (upload, rotate, view)
* **control-plane-operator**: API server configuration mounting
h3. Related Services
* OCM API: New endpoints for configuration upload, validation, and management
* Configuration storage service: Secure storage for sensitive data (encryption at rest)
* Control plane API server: Configuration installation and serving
* Monitoring and alerting: Configuration monitoring and proactive alerts
h2. Jira Component
**Component**: HyperShift
(Primary team is HyperShift, primary technical area is control plane infrastructure)
""",
components="HyperShift",
additional_fields={
# TODO: Discover actual custom field IDs for RFE project
# These are placeholders - need to query Jira API to get correct field IDs
# Common RFE fields might include:
# - Customer name (customfield_XXXXX)
# - Request priority (customfield_XXXXX)
# - Target release (customfield_XXXXX)
"labels": ["ai-generated-jira", "security", "compliance", "product-a"],
"security": {"name": "Red Hat Employee"}
}
)
```
## Jira Description Formatting
Use Jira's native formatting (Wiki markup):
### Feature Request Template Format
```
<Brief overview>
h2. Nature and Description of Request
<What is being requested>
h3. Current Limitation
<What doesn't work today>
h3. Desired Behavior
<What should work>
h3. Use Case
<How customers will use this>
h2. Business Requirements
h3. Customer Impact
* <Affected segment>
* <Number of requests>
* <Deal impacts>
h3. Regulatory/Compliance Requirements
* <Requirement 1>
* <Requirement 2>
h3. Business Justification
<Why this matters, impact of not having it>
h3. Competitive Context (optional)
<Competitor capabilities, market gaps>
h2. Affected Packages and Components
h3. Teams
* <Team>: <Responsibility>
h3. Technical Components
* <Component/operator>
h3. Related Services
* <Service>
h2. Jira Component
**Component**: <component name>
```
## Error Handling
### Missing Business Justification
**Scenario:** User provides feature request without clear business justification.
**Action:**
1. Explain importance of business requirements
2. Ask probing questions about customer impact
3. Help articulate business case
**Example:**
```
For a Feature Request to be prioritized, we need to understand the business impact.
Can you provide:
1. Who is requesting this? (customer segment, specific customers)
2. Why is it blocking them? (compliance, policy, competitive)
3. What is the business impact? (deals blocked, escalations, churn risk)
4. Are there regulatory requirements driving this?
This helps product management and engineering teams understand priority and urgency.
```
### Vague Description
**Scenario:** Description lacks specifics about what is needed.
**Action:**
1. Identify vague areas
2. Ask clarifying questions
3. Help user be more specific
**Example:**
```
The description "better security" is too vague. Let's be more specific:
1. What security capability is needed? (authentication, encryption, access control)
2. What doesn't work today? (specific limitation or gap)
3. What should work? (desired behavior)
4. How would customers use this? (use case)
For example: "Support custom SSL certificates" is specific and actionable.
```
### Missing Component Information
**Scenario:** User doesn't know which teams or components are affected.
**Action:**
1. Ask about technical area or keywords
2. Provide component mapping guidance
3. Suggest likely component based on description
**Example:**
```
To route this Feature Request correctly, we need to identify the component.
Based on your description mentioning "ProductA control plane" and "configuration", this likely affects:
- **HyperShift Team** (control plane infrastructure)
- **Networking Team** (networking and configuration)
I recommend setting the Jira Component to: **HyperShift**
Does this seem correct based on your understanding?
```
### Security Validation Failure
**Scenario:** Sensitive data detected in feature request content.
**Action:**
1. STOP submission
2. Inform user what type of data was detected
3. Ask for sanitization
**Example:**
```
I detected potentially confidential information (customer names, specific revenue figures).
If this is a public Jira project, please anonymize:
- Use "Enterprise Customer A" instead of actual customer names
- Use ranges ($1-5M) instead of exact revenue figures
- Remove any confidential business information
Would you like to revise the content?
```
### MCP Tool Error
**Scenario:** MCP tool returns an error when creating the feature request.
**Action:**
1. Parse error message
2. Provide user-friendly explanation
3. Suggest corrective action
**Common errors:**
- **"Issue type 'Feature Request' not available"** → Verify RFE project configuration, may need to use "Story" or "Enhancement" instead
- **"Component 'X' does not exist"** → List valid components for RFE project
- **"Field 'customfield_xyz' does not exist"** → Remove custom field, update placeholder in skill
## Examples
### Example 1: Enterprise Customer Request
**Input:**
```bash
/jira:create feature-request RFE "Support Foo for ProductA"
```
**Interactive prompts collect:**
- Title: "Support Foo for ProductA managed control planes"
- Nature: Current limitation with vendor defaults, need for custom configuration, use case for regulated industries
- Business requirements: 10+ customers, multiple blocked deals, compliance drivers
- Components: HyperShift team, cluster-ingress-operator, hypershift-operator
**Result:**
- Complete Feature Request with business justification
- Component: HyperShift
- Routed to appropriate teams for review
### Example 2: Compliance-Driven Request
**Input:**
```bash
/jira:create feature-request RFE "Multi-cluster backup and restore for ProductB"
```
**Auto-detected:**
- Component: HyperShift (ProductB keyword)
- Compliance: GDPR data residency, disaster recovery requirements
**Result:**
- Feature Request with regulatory justification
- Clear business impact (compliance blocking deals)
## Best Practices Summary
1. **Customer-focused:** Describe what customers need, not how to implement it
2. **Business justification:** Always include customer impact, deals, escalations, compliance drivers
3. **Specific and actionable:** Avoid vague descriptions like "better performance" or "more secure"
4. **Component routing:** Identify affected teams and set appropriate Jira component
5. **Regulatory context:** Include compliance requirements if applicable (SOC2, ISO, PCI, HIPAA, etc.)
6. **Competitive awareness:** Note if competitors have this capability
7. **No implementation details:** Focus on "what" is needed, not "how" to build it
## Anti-Patterns to Avoid
❌ **Vague title**
```
"Better security"
```
✅ Use specific capability: "Support Foo for ProductA managed control planes"
❌ **No business justification**
```
"Customers want this"
```
✅ Provide specifics: "10+ customers requested, multiple blocked deals, SOC2 compliance requirement"
❌ **Technical implementation details**
```
"Implement TLS 1.3 in ingress-operator using new controller"
```
✅ Focus on customer need: "Support Foo with modern security standards"
❌ **No component information**
```
"Someone should look at this"
```
✅ Identify teams: "HyperShift team (control plane), Networking team (ingress)"
## Workflow Summary
1. ✅ Parse command arguments (project=RFE, summary)
2. 💬 Interactively collect: Proposed title
3. 💬 Interactively collect: Nature and description of request
4. 💬 Interactively collect: Business requirements (why customer needs this)
5. 💬 Interactively collect: Affected packages and components
6. 🔍 Determine appropriate Jira Component from team/operator information
7. 🔒 Scan for sensitive data (credentials, confidential customer info)
8. ✅ Validate feature request quality and completeness
9. 📝 Format description with Jira Wiki markup
10. ✅ Create Feature Request via MCP tool
11. 📤 Return issue key and URL
## See Also
- `/jira:create` - Main command that invokes this skill
- `create-feature` skill - For strategic product features
- `create-epic` skill - For implementation epics
- RFE project documentation (if available)
## Notes
### Custom Field Discovery
This skill uses placeholder comments for custom fields because the actual field IDs for the RFE project need to be discovered. To find the correct field IDs:
1. **Query Jira API for RFE project metadata:**
```bash
curl -X GET "https://issues.redhat.com/rest/api/2/issue/createmeta?projectKeys=RFE&expand=projects.issuetypes.fields"
```
2. **Look for custom fields** like:
- Customer name
- Request priority
- Target release/version
- Business impact
3. **Update `additional_fields` dictionary** with actual field IDs
**TODO:** Once field IDs are discovered, update the MCP tool examples with real field mappings.