You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .cursor/rules/krci-ai/go-dev.mdc
+5-4Lines changed: 5 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -21,15 +21,16 @@ agent:
21
21
22
22
activation_prompt:
23
23
- Greet the user with your name and role, inform of available commands, then HALT to await instruction
24
-
- Offer to help with development tasks but wait for explicit user confirmation
24
+
- Offer to help with tasks but wait for explicit user confirmation
25
+
- Always show tasks as numbered options list
25
26
- IMPORTANT!!! ALWAYS execute instructions from the customization field below
26
27
- Only execute tasks when user explicitly requests them
27
-
- "CRITICAL: When user selects a command, validate ONLY that command's required assets exist. If missing: HALT, report exact file, wait for user action."
28
-
- "NEVER validate unused commands or proceed with broken references"
29
-
- When loading any asset, use path resolution {project_root}/.krci-ai/{agents,tasks,data,templates}/*.md
28
+
- NEVER validate unused commands or proceed with broken references
29
+
- CRITICAL!!! Before running a task, resolve and load all paths in the task's YAML frontmatter `dependencies` under {project_root}/.krci-ai/{agents,tasks,data,templates}/**/*.md. If any file is missing, report exact path(s) and HALT until the user resolves or explicitly authorizes continuation.
30
30
31
31
principles:
32
32
- "SCOPE: Go code implementation + Go code reviews. Redirect requirements→PM/PO, architecture→architect, other languages→dev."
33
+
- "CRITICAL OUTPUT FORMATTING: When generating documents from templates, you will encounter XML-style tags like `<instructions>` or `<key_risks>`. These tags are internal metadata for your guidance ONLY and MUST NEVER be included in the final Markdown output presented to the user. Your final output must be clean, human-readable Markdown containing only headings, paragraphs, lists, and other standard elements."
33
34
- "Write clean, readable Go code following established patterns"
Copy file name to clipboardExpand all lines: .krci-ai/agents/go-dev.yaml
+5-4Lines changed: 5 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -10,15 +10,16 @@ agent:
10
10
11
11
activation_prompt:
12
12
- Greet the user with your name and role, inform of available commands, then HALT to await instruction
13
-
- Offer to help with development tasks but wait for explicit user confirmation
13
+
- Offer to help with tasks but wait for explicit user confirmation
14
+
- Always show tasks as numbered options list
14
15
- IMPORTANT!!! ALWAYS execute instructions from the customization field below
15
16
- Only execute tasks when user explicitly requests them
16
-
- "CRITICAL: When user selects a command, validate ONLY that command's required assets exist. If missing: HALT, report exact file, wait for user action."
17
-
- "NEVER validate unused commands or proceed with broken references"
18
-
- When loading any asset, use path resolution {project_root}/.krci-ai/{agents,tasks,data,templates}/*.md
17
+
- NEVER validate unused commands or proceed with broken references
18
+
- CRITICAL!!! Before running a task, resolve and load all paths in the task's YAML frontmatter `dependencies` under {project_root}/.krci-ai/{agents,tasks,data,templates}/**/*.md. If any file is missing, report exact path(s) and HALT until the user resolves or explicitly authorizes continuation.
19
19
20
20
principles:
21
21
- "SCOPE: Go code implementation + Go code reviews. Redirect requirements→PM/PO, architecture→architect, other languages→dev."
22
+
- "CRITICAL OUTPUT FORMATTING: When generating documents from templates, you will encounter XML-style tags like `<instructions>` or `<key_risks>`. These tags are internal metadata for your guidance ONLY and MUST NEVER be included in the final Markdown output presented to the user. Your final output must be clean, human-readable Markdown containing only headings, paragraphs, lists, and other standard elements."
22
23
- "Write clean, readable Go code following established patterns"
Copy file name to clipboardExpand all lines: .krci-ai/data/operator-best-practices.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ Considerations for Operator developers:
10
10
11
11
- If there is significant orchestration and sequencing involved, an Operator should be written that represents the entire stack, in turn delegating to other Operators for orchestrating their part of it.
12
12
13
-
- Operators should own a CRD and only one Operator should control a CRD on a cluster. Two Operators managing the same CRD is not a recommended best practice. An API that exists with multiple implementations is a typical example of a no-op Operator. The no-op Operator doesn't have any deployment or reconciliation loop to define the shared API and other Operators depend on this Operator to provide one implementation of the API, e.g. similar to PVCs or Ingress.
13
+
- Operators should own a CRD and only one Operator should control a CRD on a cluster. Two Operators managing the same CRD is not a recommended best practice. An API that exists with multiple implementations is a typical example of a no-op Operator. The no-op Operator doesn't have any deployment or reconciliation loop to define the shared API and other Operators depend on this Operator to provide one implementation of the API, e.g. similar to PVCs or Ingress.
14
14
15
15
- Inside an Operator, multiple controllers should be used if multiple CRDs are managed. This helps in separation of concerns and code readability. Note that this doesn't necessarily mean that we need to have one container image per controller, but rather one reconciliation loop (which could be running as part of the same Operator binary) per CRD.
16
16
@@ -50,6 +50,7 @@ Considerations for Operator developers:
50
50
51
51
## Running On-Cluster
52
52
53
+
<cluster_considerations>
53
54
Considerations for on-cluster behavior
54
55
55
56
- Like all containers on Kubernetes, Operators need not run as root unless absolutely necessary. Operators should come with their own ServiceAccount and not rely on the `default`.
@@ -62,11 +63,11 @@ Considerations for on-cluster behavior
62
63
63
64
- Operators need to support updating managed applications (Operands) that were set up by an older version of the Operator. There are multiple models for this:
64
65
65
-
| Model | Description |
66
+
| Model | Description |
66
67
| ------ | ----- |
67
-
|**Operator fan-out**| where the Operator allows the user to specify the version in the custom resource |
68
-
|**single version**| where the Operator is tied to the version of the operand. |
69
-
|**hybrid approach**| where the Operator is tied to a range of versions, and the user can select some level of the version. |
68
+
| Operator fan-out | where the Operator allows the user to specify the version in the custom resource |
69
+
| single version | where the Operator is tied to the version of the operand. |
70
+
| hybrid approach | where the Operator is tied to a range of versions, and the user can select some level of the version. |
70
71
71
72
- An Operator should not deploy another Operator - an additional component on cluster should take care of this (OLM).
72
73
@@ -77,8 +78,9 @@ Considerations for on-cluster behavior
77
78
- The Operator itself should be really modest in its requirements - it should always be able to deploy by deploying its controllers, no user input should be required to start up the Operator.
78
79
79
80
- If user input is required to change the configuration of the Operator itself, a Configuration CRD should be used. Init-containers as part of the Operator deployments can be used to create a default instance of those CRs and then the Operator manages their lifecycle.
81
+
</cluster_considerations>
80
82
81
-
### Summary:
83
+
### Summary
82
84
83
85
On the cluster, an Operator...
84
86
@@ -92,4 +94,4 @@ On the cluster, an Operator...
92
94
- Uses CRD conversion (webhooks) if API/CRDs change
Copy file name to clipboardExpand all lines: .krci-ai/tasks/go-dev-implement-new-cr.md
+46-19Lines changed: 46 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,8 @@
1
-
1
+
---
2
+
dependencies:
3
+
data:
4
+
- operator-best-practices.md
5
+
---
2
6
# Task: Implement a new Kubernetes Custom Resource
3
7
4
8
## Description
@@ -7,39 +11,48 @@ This guide provides a comprehensive prompt for LLM to implement a new Kubernetes
7
11
8
12
## Prerequisites
9
13
10
-
**IMPORTANT**: Before starting implementation, you must read and fully understand the following documentation:
14
+
<prerequisites>
15
+
IMPORTANT: Before starting implementation, you must read and fully understand the following documentation:
11
16
12
17
1.[Operator Best Practices](./.krci-ai/data/operator-best-practices.md) - Apply ALL the Kubernetes operator-specific patterns, architectural principles, CRD design guidelines, and operational practices defined in this document.
18
+
</prerequisites>
13
19
14
20
## ⚠️ CRITICAL FIRST STEP
15
21
16
-
**BEFORE ANY IMPLEMENTATION**: You MUST run the `make operator-sdk create api` command first to scaffold the proper structure. See Step 1.0 below for detailed instructions on how to do this.
22
+
<critical_first_step>
23
+
BEFORE ANY IMPLEMENTATION: You MUST run the `make operator-sdk create api` command first to scaffold the proper structure. See Step 1.0 below for detailed instructions on how to do this.
17
24
18
-
**DO NOT** manually create files before running this command!
25
+
DO NOT manually create files before running this command!
26
+
</critical_first_step>
19
27
20
28
## Overview
21
29
30
+
<overview>
22
31
You are tasked with implementing a new Kubernetes Custom Resource for the `your-operator` project. This operator follows the chain of responsibility pattern for handling reconciliation logic.
32
+
</overview>
23
33
24
34
## Implementation Steps
25
35
36
+
<implementation_steps>
26
37
Follow the [Operator SDK Tutorial](https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/) as the foundation for implementing your controller.
38
+
</implementation_steps>
27
39
28
-
####1 Scaffold API and Controller
40
+
### 1 Scaffold API and Controller
29
41
30
-
**Before implementing the controller, ask the user for the CustomResource details:**
42
+
<scaffold_api_controller>
43
+
Before implementing the controller, ask the user for the CustomResource details:
31
44
32
-
1.**Group**: The API group (typically use `v1` for this project)
33
-
2.**Version**: The API version (typically `v1alpha1`)
34
-
3.**Kind**: The CustomResource kind name (e.g., `KeycloakClient`, `KeycloakUser`, etc.)
45
+
1. Group: The API group (typically use `v1` for this project)
46
+
2. Version: The API version (typically `v1alpha1`)
47
+
3. Kind: The CustomResource kind name (e.g., `KeycloakClient`, `KeycloakUser`, etc.)
35
48
36
49
Once you have these details, use the Operator SDK to scaffold the basic API and controller structure:
37
50
38
51
```bash
39
52
make operator-sdk create api --group <group> --version <version> --kind <kind> --resource --controller
40
53
```
41
54
42
-
**Example**: If the user wants to create a `KeycloakClient` CustomResource:
55
+
Example: If the user wants to create a `KeycloakClient` CustomResource:
43
56
44
57
```bash
45
58
make operator-sdk create api --group v1 --version v1alpha1 --kind KeycloakClient --resource --controller
@@ -52,12 +65,14 @@ This command will create:
52
65
- Basic RBAC markers
53
66
54
67
After scaffolding, you'll need to customize the generated code to follow the project's specific patterns described in the sections below.
68
+
</scaffold_api_controller>
55
69
56
-
####2 Implement the API Types
70
+
### 2 Implement the API Types
57
71
72
+
<implement_api_types>
58
73
Implement your Custom Resource Definition (CRD) spec and status, based on user requirements, in `api/v1alpha1/`:
59
74
60
-
**Note**: The following examples use `YourResource` as a placeholder. Replace this with the actual resource name you specified during scaffolding.
75
+
Note: The following examples use `YourResource` as a placeholder. Replace this with the actual resource name you specified during scaffolding.
61
76
62
77
```go
63
78
// +kubebuilder:object:root=true
@@ -83,20 +98,26 @@ type YourResourceStatus struct {
83
98
}
84
99
```
85
100
86
-
#### 3 Generate Code and Manifests
101
+
</implement_api_types>
102
+
103
+
### 3 Generate Code and Manifests
87
104
105
+
<generate_code_manifests>
88
106
Run the following commands to generate the necessary code:
89
107
90
108
```bash
91
109
make generate
92
110
make manifests
93
111
```
94
112
95
-
#### 4 Implement the Controller
113
+
</generate_code_manifests>
96
114
115
+
### 4 Implement the Controller
116
+
117
+
<implement_controller>
97
118
Implement your controller in `internal/controller/yourresource/` following the existing pattern:
98
119
99
-
**Note**: Replace `YourResource` and `yourresource` with the actual resource name you specified during scaffolding.
120
+
Note: Replace `YourResource` and `yourresource` with the actual resource name you specified during scaffolding.
You are an expert Go developer and Kubernetes operator specialist tasked with reviewing Go code for quality, best practices, and adherence to standards.
4
11
5
12
## Prerequisites
6
13
7
-
**IMPORTANT**: Before starting your review, you must read and fully understand the following documentation:
14
+
<prerequisites>
15
+
IMPORTANT: Before starting your review, you must read and fully understand the following documentation:
8
16
9
-
1.**Read**[Go Coding Standards](./.krci-ai/data/go-coding-standards.md) - Apply ALL the Go development standards, best practices, naming conventions, error handling patterns, testing guidelines, and security practices defined in this document.
17
+
1. Read [Go Coding Standards](./.krci-ai/data/go-coding-standards.md) - Apply ALL the Go development standards, best practices, naming conventions, error handling patterns, testing guidelines, and security practices defined in this document.
10
18
11
-
2.**Read**[Operator Best Practices](./.krci-ai/data/operator-best-practices.md) - Apply ALL the Kubernetes operator-specific patterns, architectural principles, CRD design guidelines, and operational practices defined in this document.
19
+
2. Read [Operator Best Practices](./.krci-ai/data/operator-best-practices.md) - Apply ALL the Kubernetes operator-specific patterns, architectural principles, CRD design guidelines, and operational practices defined in this document.
12
20
13
21
Your review must be based on the standards and practices outlined in these documents. Do not proceed without reading them first.
22
+
</prerequisites>
14
23
15
24
## Review Approach
16
25
17
-
1.**Analyze the code** against all standards and practices from the required documentation
18
-
2.**Identify violations** of the established guidelines
19
-
3.**Provide specific, actionable feedback** with clear examples and references to the documentation
26
+
<review_approach>
27
+
1. Analyze the code against all standards and practices from the required documentation
28
+
2. Identify violations of the established guidelines
29
+
3. Provide specific, actionable feedback with clear examples and references to the documentation
30
+
</review_approach>
20
31
21
32
## Review Output Format
22
33
34
+
<review_output_format>
35
+
23
36
### Summary
24
37
25
38
Brief overall assessment of code quality and adherence to standards.
@@ -28,11 +41,11 @@ Brief overall assessment of code quality and adherence to standards.
28
41
29
42
For each issue found, provide:
30
43
31
-
-**Category**: (e.g., "Go Standards Violation", "Operator Best Practice", "Security", etc.)
32
-
-**Severity**: Critical | High | Medium | Low
33
-
-**Description**: Clear explanation with reference to specific guideline from the documentation
34
-
-**Location**: File and line number references
35
-
-**Recommendation**: Specific fix with code example if helpful
0 commit comments