Implementation guide for creating Feature Requests in the RFE project
Inherits all available tools
Additional assets for this skill
This skill inherits all available tools. When active, it can use any tool Claude has access to.
This skill provides implementation guidance for creating Feature Requests in the RFE Jira project, which captures customer-driven enhancement requests.
This skill is automatically invoked by the /jira:create feature-request RFE command to guide the feature request creation process.
A Feature Request (RFE) is:
| 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 Requests should:
The title should be:
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)
Clearly describe:
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.
Explain why the customer needs this:
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.
Identify:
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.
When creating a feature request, guide the user through these specific questions:
Prompt: "What is the proposed title for this feature request? Make it clear, specific, and customer-focused (50-80 characters)."
Validation:
Example response:
Support Foo for ProductA managed control planes
Prompt: "What is the nature and description of the request? Describe:
Probing questions if needed:
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.
Prompt: "Why does the customer need this? List the business requirements, including:
Helpful questions:
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
Prompt: "What packages, components, teams, or operators are affected? This helps route the request to the right teams.
Provide details like:
Follow-up: After collecting this information, help the user determine the appropriate Jira Component value.
Component mapping guidance:
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
Before submitting the feature request, validate:
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"}
}
)
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"}
}
)
Use Jira's native formatting (Wiki markup):
<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>
Scenario: User provides feature request without clear business justification.
Action:
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.
Scenario: Description lacks specifics about what is needed.
Action:
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.
Scenario: User doesn't know which teams or components are affected.
Action:
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?
Scenario: Sensitive data detected in feature request content.
Action:
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?
Scenario: MCP tool returns an error when creating the feature request.
Action:
Common errors:
Input:
/jira:create feature-request RFE "Support Foo for ProductA"
Interactive prompts collect:
Result:
Input:
/jira:create feature-request RFE "Multi-cluster backup and restore for ProductB"
Auto-detected:
Result:
❌ 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)"
/jira:create - Main command that invokes this skillcreate-feature skill - For strategic product featurescreate-epic skill - For implementation epicsThis 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:
Query Jira API for RFE project metadata:
curl -X GET "https://issues.redhat.com/rest/api/2/issue/createmeta?projectKeys=RFE&expand=projects.issuetypes.fields"
Look for custom fields like:
Update additional_fields dictionary with actual field IDs
TODO: Once field IDs are discovered, update the MCP tool examples with real field mappings.