If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/kubernetes-sigs/krew shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 6w ago
• 49+ active contributors
• Distributed ownership (top contributor 19% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live kubernetes-sigs/krew repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/kubernetes-sigs/krew.

What it runs against: a local clone of kubernetes-sigs/krew — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in kubernetes-sigs/krew | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 72 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of kubernetes-sigs/krew. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/kubernetes-sigs/krew.git
#   cd krew
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of kubernetes-sigs/krew and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "kubernetes-sigs/krew(\\.git)?\\b" \\
  && ok "origin remote is kubernetes-sigs/krew" \\
  || miss "origin remote is not kubernetes-sigs/krew (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "cmd/krew/main.go" \\
  && ok "cmd/krew/main.go" \\
  || miss "missing critical file: cmd/krew/main.go"
test -f "cmd/krew/cmd/root.go" \\
  && ok "cmd/krew/cmd/root.go" \\
  || miss "missing critical file: cmd/krew/cmd/root.go"
test -f "cmd/krew/cmd/install.go" \\
  && ok "cmd/krew/cmd/install.go" \\
  || miss "missing critical file: cmd/krew/cmd/install.go"
test -f "go.mod" \\
  && ok "go.mod" \\
  || miss "missing critical file: go.mod"
test -f "docs/KREW_ARCHITECTURE.md" \\
  && ok "docs/KREW_ARCHITECTURE.md" \\
  || miss "missing critical file: docs/KREW_ARCHITECTURE.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 72 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~42d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/kubernetes-sigs/krew"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Krew is a kubectl plugin package manager (similar to apt, brew, or dnf) that discovers, installs, and manages kubectl plugins across multiple platforms. It solves the problem of plugin distribution fragmentation by providing a centralized index and consistent installation mechanism for over 200 kubectl extensions, written in Go with a CLI built on Cobra. Modular Go CLI structure: cmd/krew/cmd/ contains feature commands (install.go, list.go, info.go, index.go), with internal/ housing shared concerns like fetch_tag.go, setup_check.go, and security_notice.go. The main entry point is cmd/krew, tests are colocated with source files (install_test.go pattern), and documentation lives in docs/ with assets/logo/ containing branding.

kubectl users who need to discover and install kubectl plugins without managing individual GitHub repos; plugin developers who want to package and distribute their kubectl extensions on multiple platforms (Linux, macOS, Windows) via a unified plugin registry.

Production-ready and actively maintained. The project has 1000+ GitHub stars, is part of kubernetes-sigs (official Kubernetes SIG for CLI tooling), has comprehensive CI/CD via GitHub Actions (.github/workflows/ci.yml), and supports Go 1.25. The codebase is well-structured with unit tests (cmd/krew/cmd/install_test.go, internal/fetch_tag_test.go, setup_check_test.go) and clear governance via OWNERS and OWNERS_ALIASES.

Low risk for a mature SIG project. Dependencies are conservative and well-maintained (k8s.io, spf13/cobra, sigs.k8s.io/yaml). The k8s.io/client-go and k8s.io/apimachinery dependencies tie Krew to Kubernetes versioning (currently 0.34.1), which requires attention during Kubernetes major upgrades. No single-maintainer risk due to kubernetes-sigs governance model.

Active development focused on plugin discovery and installation reliability. The presence of setup_check.go/setup_check_test.go suggests ongoing work on system validation, internal/fetch_tag.go handles version fetching (likely for plugin metadata), and cmd/krew/cmd/info.go indicates plugin information retrieval features. CI pipeline via .github/workflows/ci.yml is active.

git clone https://github.com/kubernetes-sigs/krew.git && cd krew && go mod download && go build -o krew ./cmd/krew. Verify with ./krew version. Go 1.25+ is required per go.mod.

Daily commands: Development: go run ./cmd/krew -- <command> (e.g., go run ./cmd/krew -- list). Tests: go test ./... or go test ./cmd/krew/cmd/. Linting: golangci-lint run (configured in .golangci.yml). Docker builds are supported (.Dockerfile present).

• cmd/krew/main.go — Entry point for the krew CLI tool; all contributors must understand how commands are initialized and executed.
• cmd/krew/cmd/root.go — Root command definition and initialization; establishes the CLI framework structure that all subcommands depend on.
• cmd/krew/cmd/install.go — Core plugin installation logic; the most critical user-facing operation and primary extension point for plugin management.
• go.mod — Dependency manifest including Cobra CLI framework, Kubernetes client libs, and YAML parsing; critical for understanding architectural dependencies.
• docs/KREW_ARCHITECTURE.md — High-level architecture documentation that explains the overall design philosophy and component interactions.
• cmd/krew/cmd/index.go — Plugin index management and repository handling; essential for understanding how plugin discovery and metadata work.
• integration_test/commandline_test.go — End-to-end CLI integration tests that validate the happy path and critical workflows.

Add a New CLI Command

1. Create a new command file in cmd/krew/cmd/ following the naming pattern (e.g., cmd/krew/cmd/mycommand.go) (cmd/krew/cmd)
2. Define the command using Cobra framework with appropriate Run callback; see install.go as a template (cmd/krew/cmd/install.go)
3. Register the command in root.go by calling rootCmd.AddCommand(MyCommand) (cmd/krew/cmd/root.go)
4. Add integration tests in integration_test/commandline_test.go to validate the new command (integration_test/commandline_test.go)

Add Plugin Validation or Manifest Rules

1. Review the manifest validation tool in cmd/validate-krew-manifest/main.go to understand current validation rules (cmd/validate-krew-manifest/main.go)
2. Add new validation logic or schema constraints in the validation binary or related manifest parsing code (cmd/validate-krew-manifest/main_test.go)
3. Update unit tests to cover new validation scenarios (cmd/validate-krew-manifest/main_test.go)
4. Document the new rule in docs/PLUGIN_LIFECYCLE.md (docs/PLUGIN_LIFECYCLE.md)

Improve Plugin Discovery or Filtering

1. Review existing search implementation in cmd/krew/cmd/search.go which uses fuzzy matching (cmd/krew/cmd/search.go)
2. Enhance filtering logic or metadata indexing in the search command or index management code (cmd/krew/cmd/index.go)
3. Add test coverage in cmd/krew/cmd/search_test.go (cmd/krew/cmd/search_test.go)
4. Update USER_GUIDE.md to document the new discovery features (docs/USER_GUIDE.md)

Enhance Authentication or Security

1. Review current .netrc handling in cmd/krew/cmd/netrcutils.go (cmd/krew/cmd/netrcutils.go)
2. Add new authentication mechanisms or security checks in the netrc utilities or setup check module (cmd/krew/cmd/internal/setup_check.go)
3. Update cmd/krew/cmd/internal/security_notice.go if adding new security warnings or notices (cmd/krew/cmd/internal/security_notice.go)
4. Document security practices in docs/USER_GUIDE.md and update SECURITY_CONTACTS file if needed (SECURITY_CONTACTS)

• Cobra (CLI framework) — Provides standardized command structure, subcommand routing, and flag parsing essential for a kubectl-like plugin manager
• Kubernetes client libraries (k8s.io/client-go, k8s.io/apimachinery) — Enables integration with Kubernetes cluster operations and kubeconfig handling for plugin discovery and installation context
• Go 1.25 — Cross-platform compilation and distribution; fits Kubernetes ecosystem standard
• YAML (sigs.k8s.io/yaml) — Plugin manifests are YAML-based, aligning with Kubernetes native formats for consistency
• Fuzzy search (github.com/sahilm/fuzzy) — Enables user-friendly plugin discovery without exact name matching

• Single binary distribution with no daemon/background service

  • Why: Simplifies installation and keeps krew lightweight; matches kubectl plugin architecture expectations
  • Consequence: Plugin index updates require explicit user commands; no automatic background checks for updates

• Manifest-based plugin definition (YAML) rather than binary introspection

  • Why: Allows plugin authors full control over metadata, versioning, and platform-specific builds without requiring krew to understand plugin internals
  • Consequence: Requires maintained plugin manifests in central index; validation complexity increases

• Local filesystem-based plugin cache and installation directory

  • Why: Avoids external service dependency; works offline and respects Unix conventions
  • Consequence: Limited ability to enforce plugin security/updates across machines; manual cache management

• GitHub as primary source for plugin index and releases

  • Why: Leverages existing Kubernetes community infrastructure; enables decentralized plugin authoring
  • Consequence: Dependency on GitHub API rate limits and availability; requires internet access for plugin discovery

• Real-time plugin update notifications or automatic background updates
• Plugin sandboxing or security isolation (assumes plugins are trusted)

Plugin installation depends on the krew-index GitHub repository (referenced in docs); if index is unavailable, plugin discovery fails. The setup_check.go logic validates kubectl and shell PATH integration—missing or misconfigured .bashrc/.zshrc can break plugin discoverability. Cross-platform path handling (Windows .exe vs Unix) is subtle in install.go. The git-lfs/go-netrc dependency means Krew uses .netrc for GitHub credential handling if present, which can mask authentication issues. KUBECONFIG environment variable isn't required for krew itself, but installed plugins depend on it.

• kubectl plugin discovery mechanism — Krew wraps kubectl's native plugin system (PATH-based discovery); understanding how kubectl loads plugins from $PATH is essential to debugging installation and PATH issues in setup_check.go
• GitHub release versioning and tags — Krew's fetch_tag.go relies on GitHub API to resolve semantic versions and fetch plugin binaries from releases; critical for install.go version resolution logic
• Cross-platform binary packaging (GOARCH/GOOS) — Krew supports Linux/macOS/Windows; install.go must select the correct binary for the target OS/architecture from release assets
• Plugin manifest (YAML schema) — The krew-index contains YAML manifests defining plugin metadata (name, version, platforms, install URL); index.go parses these via sigs.k8s.io/yaml
• Kubernetes API client-go patterns — Krew depends on k8s.io/client-go (0.34.1); understanding discovery clients and API machinery helps when interfacing with Kubernetes cluster state or kubeconfig
• Credential handling via .netrc — git-lfs/go-netrc dependency enables Krew to read ~/.netrc for GitHub API authentication; relevant for private plugin repositories and rate limiting
• Fuzzy search in CLI — sahilm/fuzzy powers plugin discovery search in list.go; understanding fuzzy matching helps optimize plugin discovery UX

• kubernetes-sigs/krew-index — Official plugin index repository; contains 200+ kubectl plugin manifests that Krew's index.go fetches and uses for discovery
• kubernetes/kubectl — Krew plugins extend kubectl; understanding kubectl's plugin discovery mechanism (docs/tasks/extend-kubectl/kubectl-plugins/) is prerequisite knowledge
• spf13/cobra — Krew's CLI framework; cmd/krew/cmd structure directly mirrors Cobra's command patterns
• kubernetes/sig-cli — Parent SIG governing Krew; other CLI tools and enhancements live here
• helm/helm — Parallel package manager for Kubernetes (Helm for charts vs Krew for plugins); similar architecture and use cases

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for netrcutils.go network credentials handling

The file cmd/krew/cmd/netrcutils.go handles sensitive .netrc file parsing for authentication, but there's no corresponding netrcutils_test.go file. Given the recent dependency on github.com/git-lfs/go-netrc v0.0.0-20250218165306-ba0029b43d11, adding tests would ensure credentials are parsed securely and edge cases (malformed files, permission issues, missing files) are handled correctly. This is security-critical for a package manager.

• [ ] Create cmd/krew/cmd/netrcutils_test.go with unit tests
• [ ] Test valid .netrc file parsing with various credential formats
• [ ] Test error handling for malformed .netrc files and missing files
• [ ] Test that sensitive data is not leaked in error messages or logs
• [ ] Verify compatibility with the go-netrc dependency

Add tests for cmd/validate-krew-manifest validation logic

The cmd/validate-krew-manifest/main.go file validates plugin manifests but main_test.go appears minimal or incomplete. This tool is critical for plugin authors and the plugin index. Comprehensive tests covering valid/invalid YAML, missing required fields, version constraints, and OS/architecture specifications would prevent malformed plugins from being indexed.

• [ ] Expand cmd/validate-krew-manifest/main_test.go with comprehensive test cases
• [ ] Test valid manifest files across different schema versions
• [ ] Test validation failures: missing name, invalid version format, unsupported OS/arch
• [ ] Test edge cases: empty manifests, duplicate plugin definitions, invalid URLs
• [ ] Add tests for cross-platform binary URI validation

Add CI workflow for golangci-lint with specific linter configurations

The repo has .golangci.yml configuration file but .github/workflows/ci.yml may not be running it in an automated way. A dedicated GitHub Actions workflow would catch code quality issues early. Additionally, the repo's Go version is 1.25 (future release) which may require specific linter configurations. This ensures consistent code quality across contributions.

• [ ] Review .github/workflows/ci.yml to confirm golangci-lint is running
• [ ] If missing, create a new workflow step or dedicated .github/workflows/lint.yml
• [ ] Configure the workflow to use the Go 1.25 version specified in go.mod
• [ ] Ensure the workflow runs against the existing .golangci.yml configuration
• [ ] Add caching for Go modules and linter results to speed up CI

• Add unit tests for cmd/krew/cmd/info.go—currently no info_test.go exists, and information retrieval for installed plugins lacks test coverage
• Improve error messages in cmd/krew/cmd/install.go when fetch_tag.go fails to resolve a plugin version (add specific test case for malformed GitHub release JSON)
• Document the .krew plugin manifest schema with inline examples in docs/—list.go reads manifests but no docs/PLUGIN_MANIFEST.md exists explaining required fields and formats

Krew demonstrates reasonable security practices for a Kubernetes plugin manager, with proper use of established Go libraries and a modular command structure. However, there are concerns regarding the invalid Go version specification (1.25), potential dependency vulnerabilities, and the need for stronger plugin source validation and SBOM generation. The project should prioritize fixing the Go version, implementing vulnerability scanning in CI/CD, and enhancing security controls around untrusted plugin installation. Overall security posture is moderate with room for improvement in supply chain security.

• Medium · Deprecated Go Version — go.mod. The project specifies 'go 1.25' in go.mod, which does not exist. Go versions follow semantic versioning (1.20, 1.21, 1.22, etc.). This likely indicates a typo or misconfiguration that could lead to unexpected build behavior or security patches not being applied. Fix: Update go.mod to specify a valid, recent Go version (e.g., 'go 1.23' or 'go 1.22'). Ensure the specified version receives active security updates from the Go team.
• Low · Outdated Dependencies — go.sum and go.mod (indirect dependencies). Several indirect dependencies use older versions that may have known vulnerabilities. Notable examples include 'gopkg.in/inf.v0 v0.9.1' and other transitive dependencies. While the direct dependencies appear reasonable, indirect dependencies should be audited regularly. Fix: Run 'go mod tidy' and 'go mod verify' to ensure dependency consistency. Regularly run 'go list -u -m all' to check for available updates and 'go mod graph' to audit the dependency tree. Consider using 'go vulncheck' to identify known vulnerabilities.
• Low · Missing SBOM and Dependency Verification — Repository root, CI/CD configuration. No evidence of Software Bill of Materials (SBOM) generation or dependency signature verification in the provided file structure. For a package manager tool (Krew), this is a notable gap as it handles plugin distribution to users. Fix: Implement SBOM generation as part of the build pipeline (using tools like syft or cyclonedx-gomod). Consider verifying dependency signatures and publishing artifacts with provenance information (SLSA framework).
• Low · Potential Privilege Escalation via Plugin Installation — cmd/krew/cmd/install.go and related installation logic. Krew is a kubectl plugin package manager. The cmd/krew/cmd/install.go file suggests plugin installation functionality. Without visible security controls, there is a risk of installing untrusted or malicious plugins. Fix: Verify that the installation process validates plugin signatures and checksums. Ensure plugins are sourced from trusted registries only. Implement plugin sandboxing or privilege limitations where feasible. Document security best practices for users regarding plugin sources.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.