Create k8s-events-reviewer.md

[CatherineF-dev]

Which issue(s) this PR fixes:

Fixes #9036

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• contributors/devel/sig-instrumentation/OWNERS

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

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CatherineF-dev, dashpole

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• contributors/devel/sig-instrumentation/OWNERS [dashpole]

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

[CatherineF-dev]

@serathius

[serathius]

Without evals (https://agentskills.io/skill-creation/evaluating-skills) it's hard to judge if the SKILL is doing its job. It's like submitting code without a unit test, but it's worse for agents as it is non-deterministic. The event conventions you listed should have their own dedicated documentation and skill should just ask agent to read the conversions that are used by humans. Let's not put skip the problem that we need to first give community the guidance before we review. Using agents should be last step in multi stage solution for ensuring high quality instrumentation at scale, not just the only one.

Instead of SKILL.md I would rather review the "assertions" for prompt. Prompt "Review events added in PR #123" copy some example, the assertion "Point out that reason in event is too long breaking guidance X from K8s event practices". Putting a 4 step process harness doesn't mean better results, we need to measure the results not guess.

Also what about https://github.com/kubernetes/community/blob/main/contributors/guide/pull-requests.md#ai-guidance? Have you talked with K8s steering?

[CatherineF-dev]

https://github.com/kubernetes/community/blob/main/contributors/guide/pull-requests.md#ai-guidance

It will not publish AI comments directly. It will only provide some draft comments and sig-instrumentation reviewers choose which comments should be published.

[CatherineF-dev]

It's like submitting code without a unit test, but it's worse for agents as it is non-deterministic.

These skills are not involved in automatic workflows, and they are triggered manually with low impacts. Evals will be more important when we move into more automatic stages. We can add them in the current early stage.

[aojea]

Thanks for putting this together, I'm speaking on my behalf here.

I've taken a look, and I have some concerns about the approach here. There are a lot of opinionated rules in this PR, and I suggest that first the SIG should reach agreement on the API conventions and write them down , before hardcoding them into an execution pipeline like this.

A great example of how is this handled project wide (even before AI existed) can be found in our api-conventions.md and api_changes.md. These documents are the foundation for our consistency because the community first agreed on how the API should be reviewed and what the mechanics should look like.

This proposed SKILL seems to mix both execution instructions and API conventions. In the long term, this will make it hard to maintain and reach a consensus, as you can not decouple both things and new SKILLS can overlap.

My personal opinion is that we shouldn't treat this as something extraordinary just because it has an "AI" or "SKILL" tag on it. At the end of the day, these tools rely on good documentation ... and good documentation is what we want. I think the right path forward is:

1. The SIG first agrees on the actual conventions for these particular topics (Events review, Metrics review, etc.) and write them down.
2. Once the conventions are agreed upon, a process for how should be applied is defined.

It's also worth reminding everyone that kubernetes/kubernetes operates with SIGs and OWNERS. Independently of the reason or the technology being used, any code committed is under the exact same expectations: a high bar for quality, human accountability, and a two-person review process. Let's not get blinded by confirmation bias regarding what new technology can do to improve workflows; it cannot do magic and doesn't replace our established standards.