Skip to content

[NE-2195] Add initial add-enhancement command #1870

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Nov 4, 2025
Merged

[NE-2195] Add initial add-enhancement command #1870

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3670aa0
Add initial add-enhancement command
rikatz Oct 21, 2025
e005ec2
Refine enhancement command requirements
rikatz Oct 28, 2025
69ca07c
Fix the add-enhancement based on review
rikatz Oct 28, 2025
cda54c9
Refine add-enhancement command
rikatz Nov 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 19 additions & 8 deletions .claude/commands/add-enhancement.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,8 @@ You are tasked with creating a new OpenShift Enhancement Proposal based on the t

Act as an experienced software architect to create a comprehensive enhancement proposal. Follow these steps:
Copy link
Contributor

@Miciah Miciah Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I wonder whether this "Act as an experienced software architect" phrase contributes to the confidently wrong nature of the output. Maybe, "Act as a competent, experienced software architect with impostor syndrome"? (Ha ha, only serious.)

Copy link
Member Author

@rikatz rikatz Nov 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so, my worry here is that whatever we add as a context will be the used context, so adding something like impostor syndrome will just add wrong things as a question instead of as a conclusion :D and I know exactly how it is!

Copy link
Contributor

@Miciah Miciah Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. It wasn't an entirely serious suggestion, coaxing an LLM not to be overconfidently wrong is probably requires more finesse than that, and it makes sense to prioritize addressing the problem from the other side (that is, cultivating a healthy skepticism of LLM output).


**Important**: Reference the guidance in `dev-guide/feature-zero-to-hero.md`, particularly the section "Writing an OpenShift Enhancement", when creating enhancement proposals. This guide provides essential context on the OpenShift Enhancement Proposal process, feature gates, API design conventions, testing requirements, and promotion criteria.

1. **Parse the Description**: Extract the following from the description:
- **What**: What is this enhancement about
- **Why**: Why this change is required (motivation)
Expand All @@ -33,8 +35,9 @@ Act as an experienced software architect to create a comprehensive enhancement p
- Specific user stories or motivations if not clear from the description
- Explicit Goals or Non-Goals the user wants included
- Any specific technical constraints or requirements
- Topology considerations (Hypershift, SNO, MicroShift relevance)
- Whether this proposal adds/changes CRDs, admission and conversion webhooks, aggregated API servers, or finalizers (needed for API Extensions section)
- Topology considerations (Hypershift, SNO, MicroShift, OKE relevance)
- Whether this proposal adds/changes CRDs, admission and conversion webhooks, ValidatingAdmissionPlugin, MutatingAdmissionPlugin, aggregated API servers, or finalizers (needed for API Extensions section)
- Feature gate information: According to dev-guide/feature-zero-to-hero.md, ALL new OpenShift features must start disabled by default using feature gates. Ask about the proposed feature gate name and initial feature set (DevPreviewNoUpgrade or TechPreviewNoUpgrade).
- Ask clarifying questions about telemetry, security, upgrade and downgrade process, rollbacks, dependencies, in case it is not possible to assert these fields.

3. **Generate the Enhancement File**:
Expand All @@ -45,14 +48,18 @@ Act as an experienced software architect to create a comprehensive enhancement p
- **Motivation**: Explain why this change is required based on the description
- **User Stories**: Generate 2-4 user stories based on the "who" information using the format:
> "As a _role_, I want to _take some action_ so that I can _accomplish a goal_."
- **Goals**: List specific, measurable goals (3-5 items)
Include a story on how the proposal will be operationalized: life-cycled, monitored and remediated at scale.
- **Goals**: List specific, measurable goals (3-5 items). Goals should describe what users want from their perspective, not implementation details.
- **Non-Goals**: List what is explicitly out of scope (2-3 items)
- **Proposal**: High-level description of the proposed solution
- **Workflow Description**: Detailed workflow with actors and steps
- **Mermaid Diagram**: Add a sequence diagram when applicable to visualize the workflow
- **API Extensions**: Only fill this section if the user confirms the proposal adds/changes CRDs, admission and conversion webhooks, aggregated API servers, or finalizers. Otherwise, add a TODO comment asking the user to complete this section if applicable.
- **Implementation Details/Notes/Constraints**: Provide a high-level overview of the code changes required. Follow the guidance from the template: "While it is useful to go into the details of the code changes required, it is not necessary to show how the code will be rewritten in the enhancement." Keep it as an overview; the developer should fill in the specific implementation details.
- **Metadata**: Fill in creation-date with today's date, tracking-link with the provided JIRA ticket URL, set other fields to TBD
- **Mermaid Diagram**: Add a sequence diagram when the workflow involves multiple actors or complex interactions between components (e.g., user -> API server -> controller -> operator). Simple single-actor workflows may not need a diagram.
Copy link
Contributor

@Miciah Miciah Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the model going to interpret that example as you expect it to? I'm curious because the example represents multiple actors but not complex interactions, and it is ambiguous whether it is an example of "multiple actors or complex interactions between components" or an example of "a sequence diagram". I'm also curious how the model acts on instructions such as "may not need".

Copy link
Member Author

@rikatz rikatz Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is mostly like "if it decides that are multiple components", but IMO we can always just ask the model later "btw, generate a mermaid diagram for me" and it does a really decent job :)

- **API Extensions**: Only fill this section if the user confirms the proposal adds/changes CRDs, admission and conversion webhooks, ValidatingAdmissionPlugin, MutatingAdmissionPlugin, aggregated API servers, or finalizers. Per the template, name the API extensions and describe if this enhancement modifies the behaviour of existing resources. Otherwise, add a TODO comment asking the user to complete this section if applicable.
- **Topology Considerations**: Include subsections for Hypershift/Hosted Control Planes, Standalone Clusters, Single-node Deployments or MicroShift, and OKE (OpenShift Kubernetes Engine). Address how the proposal affects each topology.
- **Implementation Details/Notes/Constraints**: Provide a high-level overview of the code changes required. Follow the guidance from the template: "While it is useful to go into the details of the code changes required, it is not necessary to show how the code will be rewritten in the enhancement." Keep it as an overview; the developer should fill in the specific implementation details. Include a reminder about creating a feature gate: Per dev-guide/feature-zero-to-hero.md, all new features must be gated behind a feature gate in https://github.com/openshift/api/blob/master/features/features.go with the appropriate feature set (DevPreviewNoUpgrade or TechPreviewNoUpgrade initially).
- **Test Plan**: Add a TODO comment with guidance on required test labels per dev-guide/feature-zero-to-hero.md: Tests must include `[OCPFeatureGate:FeatureName]` label for the feature gate, `[Jira:"Component Name"]` for the component, and appropriate test type labels like `[Suite:...]`, `[Serial]`, `[Slow]`, or `[Disruptive]` as needed. Reference dev-guide/test-conventions.md for details.
- **Graduation Criteria**: Add a TODO comment referencing the specific promotion requirements from dev-guide/feature-zero-to-hero.md: minimum 5 tests, 7 runs per week, 14 runs per supported platform, 95% pass rate, and tests running on all supported platforms (AWS, Azure, GCP, vSphere, Baremetal with various network stacks).
- **Metadata**: Fill in creation-date with today's date, tracking-link with the provided JIRA ticket URL, set other fields to TBD. For api-approvers: use "None" if there are no API changes (no new/modified CRDs, webhooks, aggregated API servers, or finalizers); otherwise use "TBD" as a placeholder (the enhancement author will request an API reviewer from the #forum-api-review Slack channel later).

4. **Handle Unfilled Sections**: For sections that cannot be filled based on the input:
- Add a clear comment like `<!-- TODO: This section needs to be filled in -->`
Expand All @@ -63,7 +70,11 @@ Act as an experienced software architect to create a comprehensive enhancement p
- Focus on the essential information
- Use bullet points and structured formatting
- Avoid unnecessary verbosity
- **Line Length**: Keep lines in the generated enhancement at a maximum of 80 characters. It is acceptable to exceed by 10-15 characters when necessary (e.g., for URLs or code examples), but not more than that.
- **Line Length**: Keep lines in the generated enhancement at a maximum of 80 characters, but prioritize validity over line length limits. Only break lines at 80 characters if doing so will NOT create:
- Invalid or broken URLs (URLs themselves should never be split, but the line CAN and SHOULD be broken before or after the URL)
- Invalid markdown syntax (e.g., breaking markdown links, code blocks, or formatting)
- Invalid code examples (e.g., breaking code in the middle of statements)
If breaking at 80 characters would split a URL, code, or markdown syntax, find the nearest valid break point such as: after a sentence, before a URL starts, after a URL ends, or at a natural paragraph break. For regular prose, it is acceptable to exceed 80 characters by 10-15 characters to avoid breaking words mid-word. Only allow lines >95 characters when the line contains a single unbreakable element (like a standalone URL with no surrounding text, or a single line of code).

6. **Validate**:
- Ensure the area directory exists under `enhancements/`
Expand Down