Initial commit

2025-11-30 08:35:24 +08:00
commit cdb1a82fcc
21 changed files with 771 additions and 0 deletions
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -0,0 +1,11 @@
+{
+  "name": "understanding-konflux-resources",
+  "description": "Quick reference for Konflux CI/CD Custom Resources (RP, RPA, ITS) - helps users understand Applications, Components, Snapshots, IntegrationTestScenarios, ReleasePlans, namespace placement, common abbreviations, and confusions",
+  "version": "1.0.1",
+  "author": {
+    "name": "Konflux CI Team"
+  },
+  "skills": [
+    "./"
+  ]
+}
--- a/README.md
+++ b/README.md
@@ -0,0 +1,3 @@
+# understanding-konflux-resources
+
+Quick reference for Konflux CI/CD Custom Resources (RP, RPA, ITS) - helps users understand Applications, Components, Snapshots, IntegrationTestScenarios, ReleasePlans, namespace placement, common abbreviations, and confusions
--- a/SKILL.md
+++ b/SKILL.md
@@ -0,0 +1,261 @@
+---
+name: understanding-konflux-resources
+description: Use when user asks about Konflux resources, Custom Resources, Applications, Components, Snapshots, IntegrationTestScenarios, ReleasePlans, ReleasePlanAdmissions, or namespace placement. Provides quick reference for what Konflux resources are, who creates them, and where they belong (tenant vs managed namespace).
+---
+
+# Understanding Konflux Resources
+
+## Overview
+
+Konflux uses Kubernetes Custom Resources (CRs) to manage CI/CD workflows. Understanding which resource to use, who creates it, and where it belongs prevents common configuration errors.
+
+**Core principle:** Some resources YOU create, others Konflux creates automatically. Knowing the difference prevents manual work that's already automated.
+
+**NAMING CONVENTION - CRITICAL:**
+Always write resource names WITHOUT spaces: ReleasePlan, ReleasePlanAdmission, IntegrationTestScenario
+NEVER use spaces: ~~"Release Plan"~~, ~~"Release Plan Admission"~~, ~~"Integration Test Scenario"~~
+
+**⚠️ COMMON HALLUCINATION - MUST CORRECT:**
+ReleasePlanAdmission (RPA) is **NOT** automatically created by Konflux.
+ReleasePlanAdmission (RPA) is **NOT** auto-generated by the release service.
+ReleasePlanAdmission (RPA) **IS** manually created by a Platform Engineer in the managed namespace.
+
+**WHO CREATES WHAT - Critical Facts:**
+- **ReleasePlanAdmission (RPA)**: Platform Engineer creates in managed namespace (NOT you, NOT auto-created)
+- **Snapshot**: Auto-created by Integration Service (NOT you)
+- **ReleasePlan (RP)**: You create in tenant namespace
+- **IntegrationTestScenario (ITS)**: You create in tenant namespace
+
+**NAMESPACE PLACEMENT - Critical for RP/RPA:**
+- **ReleasePlan (RP)**: Goes in tenant namespace (your workspace)
+- **ReleasePlanAdmission (RPA)**: Goes in managed namespace (platform team controlled)
+- They work together across different namespaces - RPA references RP
+
+**Common abbreviations:** RP (ReleasePlan), RPA (ReleasePlanAdmission), ITS (IntegrationTestScenario), App (Application), Comp (Component)
+
+**CRITICAL:** Konflux has specific resource names. Do NOT invent resource names like "ApplicationSource", "DevBuildTemplate", "BuildConfig", etc. Use ONLY the resources listed in the table below.
+
+## When to Use
+
+Use this skill when:
+- Choosing which Konflux resource to create
+- Understanding Application vs Component
+- Confused about Snapshots (when do I create one?)
+- Deciding namespace placement (tenant vs managed)
+- Mapping CI/CD workflow to Konflux resources
+- Getting "resource not found" or "wrong namespace" errors
+
+## Quick Reference: Konflux Custom Resources
+
+| Resource | Abbrev | Purpose | Who Creates | Namespace | Key Point |
+|----------|--------|---------|-------------|-----------|-----------|
+| **Application** | App | Groups related Components that deploy together (NO git URL, NO builds) | User | Tenant | Just a label for grouping |
+| **Component** | Comp | Defines how to build artifact from git repo/branch (HAS git URL) | User | Tenant | This is what builds your code |
+| **Snapshot** | - | Immutable set of component artifact references | **Konflux** (Integration Service) | Tenant | AUTO-CREATED after builds |
+| **IntegrationTestScenario** | ITS | Defines test to run against snapshot | User | Tenant | Tests run after build |
+| **ReleasePlan** | RP | Maps Application to release action | User | **Tenant** | Created by app owner |
+| **ReleasePlanAdmission** | RPA | Defines release pipeline + credentials | Platform Engineer | **Managed** | Contains secrets |
+| **Release** | - | Request to release specific snapshot | User | Tenant | References snapshot + plan |
+
+## Common Confusions - Read This First
+
+### ❌ WRONG: "I need to create a Snapshot after committing code"
+✅ CORRECT: Snapshots are AUTO-CREATED by Integration Service after successful builds. You never manually create them.
+
+### ❌ WRONG: "Put ReleasePlan in managed namespace for security"
+✅ CORRECT: ReleasePlan goes in YOUR tenant namespace. ReleasePlanAdmission (with credentials) goes in managed namespace.
+
+### ❌ WRONG: "RPA is auto-created by Konflux" OR "RPA is automatically generated by the release service"
+✅ CORRECT: Platform Engineer manually creates RPA in managed namespace. RPA is NOT auto-created, NOT auto-generated. It's a manual step by platform team.
+
+### ❌ WRONG: "I have 5 repos, so I need 5 Applications"
+✅ CORRECT: If they deploy together, create 1 Application with 5 Components (one Component per repo).
+
+### ❌ WRONG: "Use Application to build from my git repo"
+✅ CORRECT: Use Component to build from git repo. Application just groups Components together.
+
+### ❌ WRONG: "Use Component for my entire microservices system"
+✅ CORRECT: Application = the system, Component = each microservice that builds separately.
+
+### ❌ WRONG: Application contains git URL and builds code
+✅ CORRECT: Component contains git URL and builds code. Application is just a logical grouping label.
+
+## Decision Tree: Which Resource Do I Need?
+
+```
+Q: "I need to build my app from a git repository"
+A: Create a COMPONENT resource
+   - Exact resource name: "Component"
+   - API: appstudio.redhat.com/v1alpha1
+   - One Component per repo/branch you want to build
+
+Q: "I have multiple repos that deploy together"
+A: Create 1 APPLICATION + multiple COMPONENTs
+   - Application resource groups them
+   - One Component per repo
+
+Q: "I want to run tests after builds"
+A: Create INTEGRATIONTESTSCENARIO resource
+   - References a Tekton pipeline with your tests
+
+Q: "I want to release a built snapshot"
+A: Create RELEASE resource
+   - References existing Snapshot + ReleasePlan
+
+Q: "I'm setting up a release pipeline"
+A: Two resources needed:
+   - User creates: RELEASEPLAN in tenant namespace
+   - Platform Engineer creates: RELEASEPLANADMISSION in managed namespace
+
+Q: "I need a snapshot of my builds"
+A: DON'T CREATE MANUALLY
+   - Konflux auto-creates Snapshot resources after builds
+   - Just reference existing snapshots
+```
+
+## Namespace Rules
+
+**Tenant Namespace** (your workspace):
+- Application ✓
+- Component ✓
+- Snapshot ✓ (auto-created)
+- IntegrationTestScenario ✓
+- ReleasePlan ✓
+- Release ✓
+- Build/test PipelineRuns ✓
+
+**Managed Namespace** (restricted, controlled by platform team):
+- ReleasePlanAdmission ✓ (created by Platform Engineer, NOT you)
+- Release pipeline credentials ✓
+- Release PipelineRuns ✓
+
+**Why this separation?** Keeps release credentials isolated from dev teams while allowing devs to request releases.
+
+**CRITICAL for RP/RPA:** ReleasePlan and ReleasePlanAdmission are in DIFFERENT namespaces. RP (tenant) references application. RPA (managed) references RP and contains credentials. They work together across namespace boundaries.
+
+## Resource Lifecycle: What Happens When You Push Code
+
+**Initial Setup** (you do once):
+1. Create Application (groups your components)
+2. Create Component (points to git repo + branch)
+3. (Optional) Create IntegrationTestScenario (defines tests)
+
+**Every Code Push** (Konflux automates):
+1. Build Service triggers PipelineRun (builds your component)
+2. PipelineRun creates OCI artifact (container image)
+3. Integration Service creates NEW Snapshot (references built artifacts)
+4. Integration Service runs IntegrationTestScenarios (if configured)
+
+**When Ready to Release**:
+1. Create Release CR (references snapshot + release plan)
+2. Release Service executes release pipeline
+
+**You create:** Application, Component, IntegrationTestScenario, Release
+**Konflux creates:** Snapshot, PipelineRuns
+
+## Application vs Component
+
+Think hierarchy:
+
+```
+Application (e.g., "E-commerce Platform")
+├── Component: frontend-ui (built from repo A, main branch)
+├── Component: backend-api (built from repo B, main branch)
+├── Component: auth-service (built from repo C, main branch)
+└── Component: payment-processor (built from repo D, v2 branch)
+```
+
+**Application** = logical grouping, deploy together
+**Component** = buildable unit, one per git source
+
+## Real-World Examples
+
+### Example 1: Simple Web App
+```
+Scenario: One repo with frontend code
+
+Resources:
+- 1 Application: "my-web-app"
+- 1 Component: "my-web-app-frontend" (points to repo main branch)
+- Snapshots: Auto-created on every build
+```
+
+### Example 2: Microservices (5 repos)
+```
+Scenario: frontend, backend, auth, data, queue repos that deploy together
+
+Resources:
+- 1 Application: "payment-system"
+- 5 Components: (one per repo)
+  - payment-frontend
+  - payment-backend
+  - payment-auth
+  - payment-data
+  - payment-queue
+- Snapshots: Auto-created after each component builds
+```
+
+### Example 3: Security Scanning
+```
+Scenario: Run security scan after build
+
+Resources:
+- 1 IntegrationTestScenario: "security-scan"
+  - References Tekton pipeline that runs scanning tools
+  - Runs automatically on every new Snapshot
+```
+
+### Example 4: Release Setup
+```
+Scenario: Release to production
+
+In Tenant Namespace:
+- ReleasePlan: "prod-release-plan"
+  - Points to Application
+  - References target workspace
+
+In Managed Namespace (Platform Engineer creates):
+- ReleasePlanAdmission: "prod-admission"
+  - Contains production credentials
+  - Defines release pipeline
+
+To Release:
+- Create Release CR in tenant namespace
+  - References specific Snapshot (auto-created earlier)
+  - References ReleasePlan
+```
+
+## Common Mistakes
+
+| Mistake | Why It Fails | Fix |
+|---------|-------------|-----|
+| Creating Snapshot manually | They're auto-created | Just reference existing snapshots |
+| ReleasePlan in managed namespace | User can't create there | ReleasePlan in tenant, ReleasePlanAdmission in managed |
+| One Component for multiple repos | Can't build from multiple sources | One Component per repo |
+| Creating Application per service | Loses deployment grouping | One Application, multiple Components |
+| IntegrationTestScenario in managed namespace | Tests run in tenant namespace | Put in tenant namespace |
+
+## Troubleshooting
+
+**"Snapshot not found"**
+- Snapshots are auto-created after builds complete
+- Check PipelineRun succeeded first
+- List snapshots: `kubectl get snapshots -n <tenant-namespace>`
+
+**"ReleasePlan not found"**
+- Check you're in correct namespace (tenant, not managed)
+- Verify ReleasePlan name matches what Release CR references
+
+**"No builds triggering"**
+- Component must exist BEFORE pushing code
+- Check Component git URL and revision match your repo
+- Verify webhook is configured (if using webhooks)
+
+**"Integration tests not running"**
+- IntegrationTestScenario must exist before build completes
+- Check scenario references correct Application
+- Verify Tekton pipeline referenced by scenario exists
+
+## Keywords for Search
+
+Konflux resources, Custom Resource Definition, CRD, Application CR, Component CR, Snapshot lifecycle, IntegrationTestScenario, ReleasePlan, ReleasePlanAdmission, Release CR, tenant namespace, managed namespace, build pipeline, PipelineRun, Integration Service, Build Service, Release Service, Tekton pipeline, OCI artifact, container image, git repository, webhook, automatic build, snapshot creation, integration testing, release workflow, RP, RPA, ITS, App, Comp, shortname, abbreviation, acronym, ReleasePlan abbreviation, IntegrationTestScenario abbreviation, ReleasePlanAdmission abbreviation
--- a/plugin.lock.json
+++ b/plugin.lock.json
@@ -0,0 +1,113 @@
+{
+  "$schema": "internal://schemas/plugin.lock.v1.json",
+  "pluginId": "gh:konflux-ci/skills:skills/understanding-konflux-resources",
+  "normalized": {
+    "repo": null,
+    "ref": "refs/tags/v20251128.0",
+    "commit": "9989a1828098fb06824a90d80fbca3fed3ad35af",
+    "treeHash": "c7308452b044b95db43a142ca6b63d74d3b4612edc023395bd773c6e6973bff9",
+    "generatedAt": "2025-11-28T10:19:54.347109Z",
+    "toolVersion": "publish_plugins.py@0.2.0"
+  },
+  "origin": {
+    "remote": "git@github.com:zhongweili/42plugin-data.git",
+    "branch": "master",
+    "commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
+    "repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
+  },
+  "manifest": {
+    "name": "understanding-konflux-resources",
+    "description": "Quick reference for Konflux CI/CD Custom Resources (RP, RPA, ITS) - helps users understand Applications, Components, Snapshots, IntegrationTestScenarios, ReleasePlans, namespace placement, common abbreviations, and confusions",
+    "version": "1.0.1"
+  },
+  "content": {
+    "files": [
+      {
+        "path": "README.md",
+        "sha256": "7457a4be40c0c901491270a5ecd87702d59c661fd489bcc7fe9a0a1bd3d8fba8"
+      },
+      {
+        "path": "SKILL.md",
+        "sha256": "af65a3db5dd3b4c39bb1e591826fa7c4209eeb0c232d669b6c87e299717d83a2"
+      },
+      {
+        "path": "tests/README.md",
+        "sha256": "eeca7147ec07a8b9400f9bf747c956a7a0b7136426915170b2c1e44e5a1b597e"
+      },
+      {
+        "path": "tests/scenarios.yaml",
+        "sha256": "fd221aeb719412c23ba9f74665a1a59e4d1f79357bce8e53ce69638f8708a1e1"
+      },
+      {
+        "path": "tests/results/rp-namespace-placement.1.txt",
+        "sha256": "9b18db505326cbd59540f03f936b36f02735ba5e6453e1a095a471019cad1ed2"
+      },
+      {
+        "path": "tests/results/its-lowercase.3.txt",
+        "sha256": "ab98b3ceb28923266a6cb3f8cbaffa9821f5af888c03eee80f99b0c02f6c17e7"
+      },
+      {
+        "path": "tests/results/its-lowercase.2.txt",
+        "sha256": "6b4e4d5a9b6ec49da0a655121691d888a3426eb29937364ef300978ebf563577"
+      },
+      {
+        "path": "tests/results/rp-namespace-placement.2.txt",
+        "sha256": "043f7ca393448de543c60a658c66d76e4c31deef5a02164c500f8cce4e0b1770"
+      },
+      {
+        "path": "tests/results/its-lowercase.1.txt",
+        "sha256": "361cdb5ae0565a02315e2406607070d856bb8bb3cfae7ffed4c522561526acab"
+      },
+      {
+        "path": "tests/results/rp-namespace-placement.3.txt",
+        "sha256": "06fedf19ee7b27694cced50fba5911d7a08e36b1950a664fac396b83fd2eba3b"
+      },
+      {
+        "path": "tests/results/rpa-creation-responsibility.3.txt",
+        "sha256": "a5fc6cd4d66873da4b1f990cb90bf2ca234cb2c60dc7359cc33ead8ed71efb4d"
+      },
+      {
+        "path": "tests/results/rpa-creation-responsibility.2.txt",
+        "sha256": "541826f5f0977ba5bfd3b942f6b35b65e158ebfaec9821bd813f8582146b6047"
+      },
+      {
+        "path": "tests/results/rpa-creation-responsibility.1.txt",
+        "sha256": "ba7d1d1b9844d2e6299c289c6ce39e928eca4cc1b34a1ce9b98873cd03c58983"
+      },
+      {
+        "path": "tests/results/rp-rpa-relationship.1.txt",
+        "sha256": "64510bafb9b6fce9fa8d554a2219f10345afe94915f0c8e1ed60d37bc0cb14bf"
+      },
+      {
+        "path": "tests/results/its-not-running.1.txt",
+        "sha256": "23521978bda26c52349295f6f9171f62f1c10603e55a762502cf9bd1b575845c"
+      },
+      {
+        "path": "tests/results/its-not-running.3.txt",
+        "sha256": "27bb8951183a3714bf10707c16ee62f8f3924537f355cbd4660a7db86d1b12b3"
+      },
+      {
+        "path": "tests/results/rp-rpa-relationship.2.txt",
+        "sha256": "841812231c1dff7475b421790a1196dc1d096a95198f8fcc25c3cbf8fb91dd36"
+      },
+      {
+        "path": "tests/results/rp-rpa-relationship.3.txt",
+        "sha256": "65a0e055f25377932c4ba15a93ce1cb0e696333f5ce08099a76ff3df07c0c636"
+      },
+      {
+        "path": "tests/results/its-not-running.2.txt",
+        "sha256": "dacc6a8238197141b3dfb43f34c46060d9fa32d9c5b18cc7f075f29520902dd9"
+      },
+      {
+        "path": ".claude-plugin/plugin.json",
+        "sha256": "9e676c04fee1ef980d151e3dedc14118f5747fb04f76123c9142dc21e01fae04"
+      }
+    ],
+    "dirSha256": "c7308452b044b95db43a142ca6b63d74d3b4612edc023395bd773c6e6973bff9"
+  },
+  "security": {
+    "scannedAt": null,
+    "scannerVersion": null,
+    "flags": []
+  }
+}
--- a/tests/README.md
+++ b/tests/README.md
@@ -0,0 +1,30 @@
+# Tests for understanding-konflux-resources
+
+This directory contains test scenarios and generated results for validating the skill.
+
+## Structure
+
+- `scenarios.yaml` - Test scenario definitions with expectations
+- `results/` - Generated test results (one file per scenario sample)
+
+## Running Tests
+
+**Generate test results** (invokes Claude):
+```bash
+make generate SKILL=understanding-konflux-resources
+```
+
+**Run tests** (validates results):
+```bash
+make test SKILL=understanding-konflux-resources
+```
+
+## How It Works
+
+1. `scenarios.yaml` defines test prompts and expected outcomes
+2. `make generate` invokes Claude with the skill loaded, saves outputs to `results/`
+3. Each result file includes a digest of the skill content on the first line
+4. `make test` validates results match expectations and digest matches current skill
+5. If skill content changes, tests fail until `make generate` is run again
+
+See root `Makefile` and `test/` directory for implementation details.
--- a/tests/results/its-lowercase.1.txt
+++ b/tests/results/its-lowercase.1.txt
@@ -0,0 +1,14 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+I've outlined several potential reasons why your integration tests might not be triggering after builds. To help diagnose this more precisely, I'll need some additional information from you:
+
+1. Can you confirm the specific trigger conditions for your integration tests?
+2. Have there been any recent changes to your Konflux pipeline configuration?
+3. Are you able to share the relevant configuration files (with sensitive information redacted)?
+4. What specific error messages or logs have you seen?
+
+Some quick things you can check:
+- Verify the pipeline configuration in your `.konflux.yaml` or similar files
+- Check the Konflux dashboard for any error messages or skipped test indications
+- Use `tkn pipeline list` and `tkn pipelinerun list` to see recent pipeline runs
+
+Would you like me to help you investigate further by walking you through some diagnostic steps?
--- a/tests/results/its-lowercase.2.txt
+++ b/tests/results/its-lowercase.2.txt
@@ -0,0 +1,21 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+To help diagnose the issue, I'll need some more information from you:
+
+1. Can you confirm the following details:
+   - Are you using the Konflux web interface or CLI?
+   - Have integration tests worked before, or is this a new setup?
+   - Do you see any error messages or logs indicating why tests aren't triggering?
+
+2. Please check and provide:
+   - The contents of your `.tekton` directory (if it exists)
+   - Your build configuration in the Konflux console
+   - Any recent build logs or pipeline run history
+
+Some common reasons why integration tests might not trigger:
+- Misconfigured pipeline definitions
+- Missing test stage in the build pipeline
+- Incorrect trigger conditions
+- Permissions or configuration issues
+- Tests marked as optional or skipped
+
+Could you provide more context about your specific Konflux setup and the integration test configuration? The more details you can share, the better I can help you diagnose and resolve the issue.
--- a/tests/results/its-lowercase.3.txt
+++ b/tests/results/its-lowercase.3.txt
@@ -0,0 +1,17 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the Konflux resources skill, here are some key things to check:
+
+1. IntegrationTestScenarios (ITS) should be in the tenant namespace.
+2. They are triggered automatically after a Snapshot is created.
+3. Common reasons for ITS not triggering include:
+   - No ITS resource created
+   - ITS not referencing the correct Application
+   - Builds not completing successfully
+   - Snapshot not being created
+
+Could you provide more details about:
+- Your ITS configuration (if you have one)
+- The Component and Application resources
+- The results of your recent builds
+
+This will help me diagnose why the Integration Test Scenario isn't triggering after builds.
--- a/tests/results/its-not-running.1.txt
+++ b/tests/results/its-not-running.1.txt
@@ -0,0 +1,10 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+To help diagnose the issue, could you provide me with the following information:
+1. The YAML for your IntegrationTestScenario resource
+2. The namespace where the ITS is created
+3. Confirm that you have both an Application and Component set up
+4. Share the output of `kubectl get snapshots -n <your-tenant-namespace>`
+
+This will help me identify why your ITS is not running after builds complete.
+
+Would you like me to walk you through creating or troubleshooting an IntegrationTestScenario?
--- a/tests/results/its-not-running.2.txt
+++ b/tests/results/its-not-running.2.txt
@@ -0,0 +1,17 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+To help you diagnose this, I have a few questions:
+
+1. Can you confirm which namespace your IntegrationTestScenario is created in?
+2. Does your IntegrationTestScenario reference your Application or Component?
+3. Have you verified that Snapshots are being created after your builds complete?
+
+Each of these points is critical for ensuring that your Integration Test Scenario runs automatically after builds. 
+
+A typical setup looks like:
+- Application "my-app" in tenant namespace
+- Component "my-component" in tenant namespace (points to git repo)
+- IntegrationTestScenario in tenant namespace (references "my-app" or "my-component")
+- Snapshots auto-created after successful builds
+- Konflux automatically runs the ITS against the new Snapshot
+
+Would you like to walk through checking these configuration points?
--- a/tests/results/its-not-running.3.txt
+++ b/tests/results/its-not-running.3.txt
@@ -0,0 +1,26 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the Konflux resources skill details, I can help diagnose why your Integration Test Scenario (ITS) is not running after builds complete. Let me ask a few clarifying questions and provide some potential solutions:
+
+1. Have you created an IntegrationTestScenario (ITS) resource in your tenant namespace? 
+   - The ITS must exist BEFORE builds complete
+   - It should reference the Application that contains your Components
+
+2. Confirm the following checklist:
+   - ✅ Application resource created
+   - ✅ Component(s) created with correct git repository configuration
+   - ❓ IntegrationTestScenario created
+   - ❓ Tekton pipeline referenced by ITS exists
+
+Common reasons why ITS might not run:
+- ITS is not created
+- ITS is in the wrong namespace (must be in tenant namespace)
+- Tekton pipeline referenced by ITS is missing
+- Snapshot not created (this is auto-created, so unlikely the issue)
+
+Could you share:
+1. The name of your Application
+2. The names of your Components
+3. The YAML for your IntegrationTestScenario (or confirm if you've created one)
+4. The namespace you're working in
+
+This will help me precisely diagnose why your Integration Test Scenario is not running after builds complete.
--- a/tests/results/rp-namespace-placement.1.txt
+++ b/tests/results/rp-namespace-placement.1.txt
@@ -0,0 +1,20 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the skill information, I can directly answer your question about ReleasePlan (RP) placement:
+
+**ReleasePlan (RP) should be created in the TENANT namespace.**
+
+Key points to remember:
+- ReleasePlan goes in YOUR tenant namespace (where your Application and Components are)
+- ReleasePlanAdmission (RPA) goes in the MANAGED namespace (created by Platform Engineers)
+
+The workflow is:
+1. You create the ReleasePlan in your tenant namespace
+2. Platform Engineers create a corresponding ReleasePlanAdmission in the managed namespace
+3. These two resources work together across different namespaces
+
+This separation ensures that:
+- You control the release plan for your application
+- Platform team controls the release credentials and pipeline configuration
+- Sensitive credentials remain in the managed namespace
+
+Would you like me to elaborate on how ReleasePlan and ReleasePlanAdmission interact in the Konflux workflow?
--- a/tests/results/rp-namespace-placement.2.txt
+++ b/tests/results/rp-namespace-placement.2.txt
@@ -0,0 +1,17 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the detailed skill information, I can directly answer your question about ReleasePlan (RP) placement in Konflux:
+
+**ReleasePlan (RP) goes in the TENANT namespace, NOT the managed namespace.**
+
+Key points:
+- You (the application owner) create the ReleasePlan in your tenant namespace
+- The ReleasePlan references your Application and describes the release action
+- Platform Engineers will create a corresponding ReleasePlanAdmission (RPA) in the managed namespace, which contains the actual release credentials and pipeline details
+
+So to summarize:
+- ✅ ReleasePlan: Created by you, goes in TENANT namespace
+- 🔒 ReleasePlanAdmission: Created by Platform Engineer, goes in MANAGED namespace
+
+The two resources work together across different namespaces, with the RPA referencing your tenant-namespace ReleasePlan and providing the necessary release pipeline configuration and credentials.
+
+Would you like me to elaborate on how these two resources interact in the release workflow?
--- a/tests/results/rp-namespace-placement.3.txt
+++ b/tests/results/rp-namespace-placement.3.txt
@@ -0,0 +1,19 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the skill output, let me directly answer your question about ReleasePlan (RP) namespace placement:
+
+You should create your ReleasePlan (RP) in the **tenant namespace**. 
+
+Key points:
+- ReleasePlan goes in YOUR tenant namespace (the workspace you control)
+- ReleasePlanAdmission (RPA) goes in the managed namespace (controlled by platform team)
+- The ReleasePlan references your Application
+- The ReleasePlanAdmission will reference your ReleasePlan and contain release credentials
+
+A common mistake is thinking the ReleasePlan should go in the managed namespace for security. This is incorrect. The tenant namespace is where you create the ReleasePlan, which defines the release action for your Application.
+
+Workflow:
+1. You create ReleasePlan in tenant namespace
+2. Platform Engineer creates corresponding ReleasePlanAdmission in managed namespace
+3. When ready to release, you create a Release CR that references the ReleasePlan and a Snapshot
+
+Would you like me to elaborate on any part of this explanation?
--- a/tests/results/rp-rpa-relationship.1.txt
+++ b/tests/results/rp-rpa-relationship.1.txt
@@ -0,0 +1,21 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the skill information, I can directly answer your question about how the ReleasePlanAdmission (RPA) references the ReleasePlan (RP) in Konflux:
+
+The ReleasePlan (RP) and ReleasePlanAdmission (RPA) are intentionally placed in DIFFERENT namespaces:
+- ReleasePlan (RP) is created in the TENANT namespace (your workspace)
+- ReleasePlanAdmission (RPA) is created in the MANAGED namespace (platform team's controlled namespace)
+
+Importantly, the RPA explicitly references the ReleasePlan across these namespace boundaries. This design allows:
+1. Developers to define release plans in their tenant namespace
+2. Platform engineers to manage release credentials and pipelines in a separate managed namespace
+3. A cross-namespace reference that maintains separation of concerns
+
+Key points:
+- They do NOT need to be in the same namespace
+- The RPA is manually created by a Platform Engineer
+- The RPA references the RP using its name and namespace
+- This allows secure management of release credentials while giving developers control over release plans
+
+So to directly answer your questions:
+- The RPA references the RP by its name and namespace
+- They are INTENTIONALLY in different namespaces as a security and access control mechanism
--- a/tests/results/rp-rpa-relationship.2.txt
+++ b/tests/results/rp-rpa-relationship.2.txt
@@ -0,0 +1,26 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the skill documentation, I can provide a detailed answer about how the ReleasePlanAdmission (RPA) references the ReleasePlan (RP):
+
+The ReleasePlan (RP) and ReleasePlanAdmission (RPA) are designed to work across different namespaces:
+- ReleasePlan (RP) is created in the tenant namespace by the application owner
+- ReleasePlanAdmission (RPA) is created in the managed namespace by the Platform Engineer
+
+Key points about their relationship:
+1. The RPA references the RP across namespace boundaries
+2. They do NOT need to be in the same namespace
+3. The RPA is manually created by the Platform Engineer to link the release plan with the necessary credentials and release pipeline configuration
+
+Specifically:
+- The RP is created in the tenant namespace and points to the Application
+- The RPA in the managed namespace contains production credentials and references the original ReleasePlan
+- This separation allows:
+  - Developers to define release plans in their own namespace
+  - Platform teams to manage release credentials securely in a separate namespace
+
+Example workflow:
+1. Developer creates a ReleasePlan in tenant namespace
+2. Platform Engineer creates a corresponding ReleasePlanAdmission in managed namespace
+3. The RPA links to the RP using a cross-namespace reference
+4. When a release is triggered, the system uses both resources to execute the release
+
+The key takeaway is that RPAs are NOT automatically created, and they intentionally exist in a different namespace from the ReleasePlan to maintain proper separation of concerns and security.
--- a/tests/results/rp-rpa-relationship.3.txt
+++ b/tests/results/rp-rpa-relationship.3.txt
@@ -0,0 +1,24 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the skill description, I can directly answer your question about how the ReleasePlanAdmission (RPA) references the ReleasePlan (RP):
+
+The ReleasePlan (RP) and ReleasePlanAdmission (RPA) are intentionally created in DIFFERENT namespaces:
+- ReleasePlan (RP) is created in the TENANT namespace (by you/your team)
+- ReleasePlanAdmission (RPA) is created in the MANAGED namespace (by the Platform Engineer)
+
+The RPA references the RP across namespace boundaries. Specifically:
+1. The ReleasePlan is created first in the tenant namespace
+2. The Platform Engineer then creates a ReleasePlanAdmission in the managed namespace that points to/references the ReleasePlan
+
+Key points:
+- They do NOT need to be in the same namespace
+- In fact, they are INTENTIONALLY placed in different namespaces
+- The RPA contains release pipeline credentials
+- The RP defines the release action for an Application
+- The RPA links the release credentials to the release plan across namespace boundaries
+
+This separation ensures:
+- Developers can define release plans (in tenant namespace)
+- Platform engineers control release credentials (in managed namespace)
+- Secure isolation of sensitive release information
+
+Would you like me to elaborate on any part of this explanation?
--- a/tests/results/rpa-creation-responsibility.1.txt
+++ b/tests/results/rpa-creation-responsibility.1.txt
@@ -0,0 +1,17 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the detailed Konflux resources explanation, I can directly answer your question:
+
+No, you do NOT create the ReleasePlanAdmission (RPA). The RPA is created by the Platform Engineer in the managed namespace. 
+
+Key points:
+- ReleasePlanAdmission (RPA) is manually created by Platform Engineers
+- It is created in the managed namespace (not your tenant namespace)
+- YOU create the ReleasePlan (RP) in your tenant namespace
+- The Platform Engineer then creates a corresponding RPA in the managed namespace to define the release pipeline and credentials
+
+The workflow is:
+1. You create a ReleasePlan in your tenant namespace
+2. Platform Engineer creates a ReleasePlanAdmission in the managed namespace
+3. These two resources work together across different namespaces
+
+So to directly answer your question: No, you do not create the RPA. That's a task for your Platform Engineering team.
--- a/tests/results/rpa-creation-responsibility.2.txt
+++ b/tests/results/rpa-creation-responsibility.2.txt
@@ -0,0 +1,14 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+Based on the skill output, I can definitively answer your question:
+
+No, you do NOT create the ReleasePlanAdmission (RPA). 
+
+**The ReleasePlanAdmission (RPA) is created by the Platform Engineer in the managed namespace.** 
+
+Key points:
+- You create the ReleasePlan (RP) in your tenant namespace
+- The Platform Engineer creates the ReleasePlanAdmission (RPA) in the managed namespace
+- RPAs are NOT automatically created by Konflux
+- RPAs contain release pipeline credentials and are manually set up by your platform team
+
+So if you want an RPA, you'll need to work with your platform engineering team to have them create it in the managed namespace, referencing the ReleasePlan you create in your tenant namespace.
--- a/tests/results/rpa-creation-responsibility.3.txt
+++ b/tests/results/rpa-creation-responsibility.3.txt
@@ -0,0 +1,17 @@
+# skill_digest: e80c8209ad23b68350bd657d2e171ecdd9cf826b295b86a83aa85c585139552d
+To directly answer your question: No, you do not create the ReleasePlanAdmission (RPA). 
+
+As explained in the skill document, the ReleasePlanAdmission (RPA) is:
+- Created by the Platform Engineer
+- Goes in the managed namespace (NOT your tenant namespace)
+- Defines the release pipeline and contains credentials
+
+You (as a developer/application owner) are responsible for creating:
+- The ReleasePlan (RP) in your tenant namespace
+- The Application
+- The Components
+- The IntegrationTestScenarios (if needed)
+
+The Platform Engineer will create the corresponding ReleasePlanAdmission (RPA) in the managed namespace to complete the release setup. This separation ensures that sensitive release credentials are kept in a controlled, restricted namespace while allowing you to define your release plans.
+
+Would you like me to elaborate on the specific roles and how ReleasePlan and ReleasePlanAdmission work together?
--- a/tests/scenarios.yaml
+++ b/tests/scenarios.yaml
@@ -0,0 +1,73 @@
+# Test scenarios for understanding-konflux-resources skill
+# This file defines all test cases for validating the skill's behavior
+
+skill_name: understanding-konflux-resources
+description: Tests for shortname discovery and Konflux resource understanding
+
+# Test scenarios following TDD methodology (RED-GREEN-REFACTOR)
+test_scenarios:
+  - name: rp-namespace-placement
+    description: Test RP abbreviation recognition and namespace guidance
+    prompt: "In Konflux, I'm confused about where to create my RP - should it go in the tenant namespace or managed namespace?"
+    model: haiku
+    samples: 3
+    expected:
+      contains_keywords:
+        - tenant namespace
+        - ReleasePlan
+      does_not_contain:
+        - Resource Pool
+    baseline_failure: "Agent didn't recognize RP abbreviation, gave generic answer"
+
+  - name: its-not-running
+    description: Test ITS abbreviation and troubleshooting guidance
+    prompt: "In Konflux, my ITS is not running after builds complete. I have the Component and Application set up. What am I missing?"
+    model: haiku
+    samples: 3
+    expected:
+      contains_keywords:
+        - integration
+      does_not_contain: []
+    baseline_failure: "Agent didn't recognize ITS, couldn't provide specific troubleshooting"
+
+  - name: rpa-creation-responsibility
+    description: Test RPA abbreviation and role/responsibility understanding
+    prompt: "In Konflux, do I create the RPA?"
+    model: haiku
+    samples: 3
+    expected:
+      contains_keywords:
+        - ReleasePlanAdmission
+        - platform engineer
+        - managed namespace
+      does_not_contain:
+        - you create the RPA
+        - user creates the RPA
+    baseline_failure: "Agent confused about who creates ReleasePlanAdmission"
+
+  - name: rp-rpa-relationship
+    description: Test multiple abbreviations in single query
+    prompt: "In Konflux, how does the RPA reference the RP? Do they need to be in the same namespace?"
+    model: haiku
+    samples: 3
+    expected:
+      contains_keywords:
+        - ReleasePlan
+        - ReleasePlanAdmission
+        - tenant
+        - managed
+        - different namespace
+      does_not_contain: []
+    baseline_failure: "Agent confused about namespace separation"
+
+  - name: its-lowercase
+    description: Test case-insensitive abbreviation matching
+    prompt: "In Konflux, my its isn't triggering after builds"
+    model: haiku
+    samples: 3
+    expected:
+      contains_keywords:
+        - integration
+      does_not_contain: []
+    baseline_failure: "Agent didn't recognize lowercase 'its'"
+