👋 Welcome to KubeIntellect — what it is, and how to get involved

[MSKazemi]

KubeIntellect is a human-governed AI SRE for Kubernetes — ask your cluster questions in plain English, and it fans out to specialized agents that query kubectl, Prometheus (PromQL), and Loki (LogQL) live, correlates the evidence, and answers. Any change to the cluster pauses for explicit human approval, gated by RBAC. An LLM never touches your cluster unilaterally.

kq "why is my api-server pod crashlooping?"
kq "scale the frontend deployment to 5 replicas"   # pauses for your approval

Try it in 30 seconds — the browser demo (read-only) at https://kubeintellect.com/demo, or pip install kube-q. Full local stack: pip install kubeintellect && kubeintellect init.

Where things are

• 🐛 Found a bug? → Issues
• 💡 Have an idea? → the Ideas category here
• 🙋 Need help? → Q&A here
• 🧑‍💻 Want to contribute? → CONTRIBUTING.md. Start with a good first issue.

Introduce yourself in a reply 👋 — what cluster do you run, and what would make an AI SRE actually useful to you? We read every one.

[MSKazemi]

The contributor wall no longer requires a merged commit

A change worth announcing here, because it changes what it takes to get your name on the project.

The contributor table used to read "People other than the maintainer whose work is in the shipped code" — while the paragraph twelve lines below it promised that documentation, bug reports, reviews, ideas and triage were all recorded, "not just merged commits". Both could not be true, and the header was the one being enforced.

As of #205 the promise is the rule:

• A merged commit is not the entry fee. A bug report, a platform verification, a review, or an argument that changed a design decision all count.
• Your name goes up when you start, not when you merge. Claim an issue and you are added that day, marked 🛠️, with a row saying what you took on.
• The row is rewritten as the work lands — it describes what you actually did.
• If it never lands, the row stays. You ran out of time, the cluster went away, life happened. Deciding to help is a real thing that happened, and pretending otherwise is how projects teach people not to volunteer.
• Nobody is ever removed.

Three people went up under the new rule before writing any code — one of whom, @1cbyc, changed the project's encoding policy from outside the codebase by arguing that a substituted character can turn operational data into a plausible wrong answer. That argument improved the code before a line of it was written, and under the old rule it was worth nothing on the wall.

Where to start

• good first issue — bounded, mentored, and each one says what "done" looks like.
• area/deploy — no code and no Python. Run the documented install on GKE or OpenShift and report what happened. CI only ever sees Kind, so these are genuinely unknown. A precise failure report is worth more than a clean pass — the last person to do one found a bug on the README's first code block.
• #13 — write a failure playbook. The most contributor-friendly surface in the repo.

Every issue gets a human first response, including "not this way" — that is written down in TRIAGE.md. It is a one-person project, so if a thread of yours goes quiet, a nudge is welcome rather than rude.

And if the project is useful to you, a ⭐ or a short post about what you tried is the highest-leverage thing you can do that costs nothing — the repo currently has more forks than stars, which means the people who like it are mostly not the people making it findable. Entirely optional, and it changes nothing about how your issues or PRs are treated.