Content
78%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-crafted troubleshooting body: lean, AKS-specific gotchas instead of generic Kubernetes education, copy-paste commands, and a genuinely convergent diagnostic methodology with pre-flight and re-test checkpoints. Its main defects are the distributed (rather than consolidated) workflow presentation and a bundle-integrity problem where most of the symptom routing table links to topic files that are missing from the bundle as provided.
Suggestions
Ship (or restore) the eight topic files referenced in the routing table (pod-failures.md, node-issues.md, networking.md, load-balancer-and-ingress.md, network-policy.md, upgrade-operations.md, spot-and-zone-issues.md, general-diagnostics.md) or repoint those rows to existing files such as references/symptom-map.md so no navigation link is broken.
Consolidate the Operating rules, Evidence order, and Host capability gate sections into one ordered end-to-end procedure (bind -> route -> collect -> converge -> report) with the validation checkpoints embedded at each step.
Deduplicate the symptom-map description (currently in the route table, the following paragraph, and Log discipline) and trim the overlap between Tool preference and Host capability gate.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with AKS-specific, non-generic knowledge (SNAT exhaustion past a few hundred nodes, VM extension error codes 50/51/52, API-server IP change after stop/start, default max-surge of one node, kubectl version-skew rule) and avoids explaining concepts Claude already knows. Not 5 because a few sections could be tightened: the "Host capability gate" rule overlaps the "Tool preference" rule for several lines, and the symptom-map description is repeated in three places (route table row, dedicated paragraph, Scripts/Log discipline sections). | 4 / 5 |
Actionability | Guidance is copy-paste executable throughout: exact commands with their queries ("az aks show -o json --query networkProfile.networkPlugin", "kubectl get pdb -A", "az network lb probe list", "kubectl auth can-i", "date -u"), concrete script invocations with argument lists ("scripts/cluster-snapshot.sh <resource-group> <cluster> <kube-context>"), and a pointer to a 17-section symptom map of exact commands in order. The common cases are covered with specific, runnable commands; this matches the fully executable anchor. | 5 / 5 |
Workflow Clarity | The diagnostic sequence is clearly defined — bind subscription/cluster/context first, let the symptom select the first decisive read (workload-local vs control-plane branches), follow the causal branch, converge on 2-4 hypotheses with confirming/falsifying signals, stop at one supported cause or report the gap — with real validation checkpoints (host capability pre-check, script-side context-endpoint verification, re-test of the original signal after any remediation). Not 5 because the end-to-end procedure must be assembled from six separate prose sections rather than one coherent ordered walkthrough, and there are no checklists for the report/escalation stage. | 4 / 5 |
Progressive Disclosure | The in-body structure itself is strong — a symptom routing table, one-level-deep clearly-signaled references, and pointers to scripts and a report template — but scored against the actual bundle, 8 of the routing-table targets (general-diagnostics.md, pod-failures.md, node-issues.md, networking.md, load-balancer-and-ingress.md, network-policy.md, upgrade-operations.md, spot-and-zone-issues.md) do not exist anywhere in the provided bundle, and references/symptom-map.md itself links to ../node-issues.md. More than half of the primary navigation routes are broken, which prevents the clear navigation the top anchors require; the well-organized existing structure is the only reason this is not 2. | 3 / 5 |
Total | 16 / 20 Passed |