Adding Claude slash command helper to external-dns-operator

[Thealisyed]

This PR adds a new Claude Code slash command /external-dns-operator-helper that automates comprehensive PR reviews for the External DNS Operator repository.

What It Does

Runs a complete PR review workflow in a single command:

• ✅ Fetches and checks out the PR
• ✅ Shows Prow CI status with clickable links
• ✅ Validates commit message format (JIRA-ID: Description)
• ✅ Checks Effective Go style (receiver names, error strings, exported docs)
• ✅ Runs make verify, make test, make build
• ✅ Validates API changes, test coverage, and documentation updates
• ✅ Returns comprehensive pass/fail summary

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign miciah for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Thealisyed]

Example usecase:

> /external-dns-operator-helper is running… https://github.com/openshift/external-dns-operator/pull/267 

● I'll run the comprehensive PR review workflow for PR #267. This will execute all checks in a single automated run.

● Bash(#!/bin/bash        timeout: 15m 0s
      set -euo pipefail…)
  ⎿  📍 Current branch: addingclaude
     🔍 Reviewing PR #267
     … +153 lines (ctrl+o to expand)

● PR Review Summary: #267

  The automated review workflow completed in 21 seconds. Here's what was found:

  ❌ Critical Issues (2)

  1. Commit message validation failed
    - Commit fbb04c9c lacks JIRA-ID prefix
    - Current: This is demo PR to check the konflux pipeline
    - Required: <JIRA-ID>: Description (e.g., NE-2076: Check konflux pipeline)
  2. Verification failed (make verify)
    - golangci-lint errors in test/e2e/util.go:
        - Line 79: deploymentConditionMap unused
      - Line 87: waitForOperatorDeploymentStatusCondition unused
      - Line 106: conditionsMatchExpected unused
    - Action: Remove unused functions or mark with // nolint:unused if intentionally kept

  ✅ Passed Checks

  - Effective Go style: No issues
  - Unit tests: All passed (53.4% overall coverage)
  - Build: Successful (binary: 60M)
  - Specialized checks: No API/CRD/controller/docs issues

  🤖 CI Status (Prow)

  - ✅ Passed: ci/prow/unit, ci/prow/images
  - ❌ Failed: ci/prow/verify (https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/openshift_external-dns-operator/267/pull-ci-openshift-external-dns-operator-main-verify/1983555971309375488)
  - ⏳ Pending: Multiple e2e tests (AWS, Azure, GCP, Infoblox)

  📝 PR Details

  - Size: 1 file, 17 lines changed (small PR ✅)
  - Commits: 1

  ---
  Action Items

  Before merging:

  1. Fix commit message: Prefix with JIRA-ID
  2. Run make verify locally: Remove unused functions in test/e2e/util.go:79,87,106
  3. Wait for CI: Ensure ci/prow/verify passes after fixes

  The PR is otherwise clean - tests pass, build succeeds, and code style complies with Effective Go guidelines.

[Miciah]

How much of this could be done using a generic review command in https://github.com/openshift-eng/ai-helpers? Would it be practical to use a generic review command and rely on AGENT.md, CLAUDE.md, README.md, and HACKING.md for project-specific details?

[Thealisyed]

@Miciah So I had a look into this too. From what I understood, the api-helpers is a generic helper for reviewing and it is also something a user would have to download from the marketplace to configure (vs having the helper in the repo can be called by anyone working in the repo via the claude cli).

The custom helper also focuses on a few specific areas that the ai-helper overlooks such as Prow CI config, effective go checks (although this is something we should add to the ai-helpers repo for all agents to refer to in general)
Also if you were to use ai-helpers, the user would have to run multiple commands whereas the helper does everything in a single execution.

Our custom helper can be seen as more of a quick 'hey is this ready to merge/pushed?"

However I am not stuck in stone to having this merged and of course open to more understanding of the best approach going forward!!

This is a shift-week project and a way to get myself familiar with the plugins, claude code and the ai-helpers repo :)

[openshift-ci]

@Thealisyed: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.