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/GoogleContainerTools/skaffold 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 1d ago
• 21+ active contributors
• Distributed ownership (top contributor 45% 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 GoogleContainerTools/skaffold repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GoogleContainerTools/skaffold.

What it runs against: a local clone of GoogleContainerTools/skaffold — 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 GoogleContainerTools/skaffold | 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 main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of GoogleContainerTools/skaffold. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/GoogleContainerTools/skaffold.git
#   cd skaffold
#
# 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 GoogleContainerTools/skaffold and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GoogleContainerTools/skaffold(\\.git)?\\b" \\
  && ok "origin remote is GoogleContainerTools/skaffold" \\
  || miss "origin remote is not GoogleContainerTools/skaffold (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "cmd/skaffold/app/skaffold.go" \\
  && ok "cmd/skaffold/app/skaffold.go" \\
  || miss "missing critical file: cmd/skaffold/app/skaffold.go"
test -f "cmd/skaffold/app/cmd/commands.go" \\
  && ok "cmd/skaffold/app/cmd/commands.go" \\
  || miss "missing critical file: cmd/skaffold/app/cmd/commands.go"
test -f "cmd/skaffold/app/cmd/runner.go" \\
  && ok "cmd/skaffold/app/cmd/runner.go" \\
  || miss "missing critical file: cmd/skaffold/app/cmd/runner.go"
test -f "cmd/skaffold/app/cmd/flags.go" \\
  && ok "cmd/skaffold/app/cmd/flags.go" \\
  || miss "missing critical file: cmd/skaffold/app/cmd/flags.go"
test -f "cmd/skaffold/app/cmd/dev.go" \\
  && ok "cmd/skaffold/app/cmd/dev.go" \\
  || miss "missing critical file: cmd/skaffold/app/cmd/dev.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
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/GoogleContainerTools/skaffold"
  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).

Skaffold is a CLI tool that automates the Kubernetes development workflow—detecting source code changes, building container images, pushing them to registries, and deploying to local or remote Kubernetes clusters. It eliminates repetitive manual steps in the build-push-deploy cycle, enabling developers to iterate on Kubernetes applications in seconds with continuous log aggregation and port forwarding. Single monorepo architecture: cmd/skaffold/app/cmd/ contains the CLI command entrypoints (build.go, deploy.go, dev.go, etc.), pkg/ likely contains the core logic (builders, deployers, sync logic), examples/ contains reference projects, and .github/workflows/ orchestrate CI across three OSes. The project uses Cobra for CLI structure and pluggable interfaces for builders/deployers.

Go developers and DevOps engineers building containerized Kubernetes applications who need fast local iteration without manual kubectl or docker CLI orchestration. Also platform teams building CI/CD pipelines that need pluggable, declarative build and deploy stages.

Highly mature and production-ready. Skaffold has stable releases on GitHub (visible in ROADMAP.md and release badges), comprehensive test coverage across Linux/Darwin/Windows (unit-tests-*.yml workflows), active integration tests (integration-linux.yml), and CI enforcing linting (linters-checks.yml) and code scanning (codeql-analysis.yml). This is an established Google-backed project with ongoing maintenance.

Low risk for production use. Heavy Go codebase (9.5MB) with well-established patterns and CI/CD validation. Main risks: heavy dependency on Kubernetes API compatibility (requires tracking upstream K8s versions), complex plugin architecture (builders, deployers) may introduce subtle bugs if misconfigured, and single point of configuration (skaffold.yaml) means typos cascade across the entire pipeline.

Active development visible in the workflow files (integration-linux.yml, unit-tests across OSes, linters-checks.yml, and verify-examples.yml indicate continuous testing). The DEVELOPMENT.md, CONTRIBUTING.md, and pull_request_template.md suggest an organized contribution process. Dependabot.yml shows automated dependency management.

git clone https://github.com/GoogleContainerTools/skaffold && cd skaffold && make build (or check DEVELOPMENT.md for local setup with Go 1.19+). The Makefile at the root should provide build targets; review Makefile.diag for diagnostic tools.

Daily commands: make build produces the skaffold binary. For development: make test runs unit tests, make integration-tests runs end-to-end tests. For daily use: skaffold dev (watches files and redeploys), skaffold build (builds only), skaffold deploy (deploys only), skaffold run (one-shot build+deploy).

• cmd/skaffold/app/skaffold.go — Main entry point for the Skaffold CLI; defines the root command structure and initializes the application.
• cmd/skaffold/app/cmd/commands.go — Core command registry that wires all Skaffold subcommands (build, deploy, dev, run, etc.) and their lifecycle.
• cmd/skaffold/app/cmd/runner.go — Orchestrates the build-push-deploy workflow; the primary execution engine for all Skaffold operations.
• cmd/skaffold/app/cmd/flags.go — Global flag definitions and parsing for all commands; essential for understanding CLI option handling.
• cmd/skaffold/app/cmd/dev.go — Implements the dev loop (watch, rebuild, redeploy) that is Skaffold's primary use case for iterative development.
• Makefile — Build, test, and deployment targets; shows how to compile and release Skaffold itself.
• DEVELOPMENT.md — Developer setup guide covering Go version, dependencies, and local testing workflow.

• CLI & Commands Layer (Cobra, Go stdlib flag parsing) — Parses user input, displays help, and delegates to appropriate command handler. Routes to build, deploy, dev, test, debug, etc.
  • Failure mode: Unclear help text, incorrect flag parsing, or command not found—user cannot start workflow.
• undefined — undefined

Add a New Skaffold Command

1. Create a new command file in cmd/skaffold/app/cmd/ (e.g., mycommand.go) that implements the command logic using Cobra. (cmd/skaffold/app/cmd/mycommand.go)
2. Register the command in the commands.go file by adding it to the command registry returned by GetAll(). (cmd/skaffold/app/cmd/commands.go)
3. Define any command-specific flags in your command file or in a shared flags structure. (cmd/skaffold/app/cmd/flags.go)
4. Write unit tests for your command in a *_test.go file, following the pattern of existing tests (e.g., build_test.go). (cmd/skaffold/app/cmd/mycommand_test.go)

Add a New Inspect Subcommand

1. Create a new file cmd/skaffold/app/cmd/inspect_mynewaspect.go that implements inspection logic for a new config aspect. (cmd/skaffold/app/cmd/inspect_mynewaspect.go)
2. Follow the pattern of existing inspect commands (e.g., inspect_profiles.go) which load the skaffold config and extract/output specific information. (cmd/skaffold/app/cmd/inspect_profiles.go)
3. Register your new inspect subcommand in inspect.go by adding it to the command tree. (cmd/skaffold/app/cmd/inspect.go)

Add Global CLI Flag Support

1. Define your flag constant and parsing logic in cmd/skaffold/app/cmd/flags.go with appropriate types and defaults. (cmd/skaffold/app/cmd/flags.go)
2. Add the flag to the base command setup in cmd.go so it's available to all commands that inherit from it. (cmd/skaffold/app/cmd/cmd.go)
3. Write tests in flags_test.go to verify parsing and defaults. (cmd/skaffold/app/cmd/flags_test.go)

• Cobra CLI Framework — Provides structured command parsing, help generation, and subcommand hierarchies; industry standard for Go CLI tools.
• Go 1.19+ — Enables cross-platform compilation and deployment; necessary for reaching macOS, Linux, and Windows users with a single codebase.
• Kubernetes Client Library (client-go implicit) — Required for querying cluster state, applying manifests, and monitoring pod status during deploy operations.
• Docker / OCI Image Builders — Supports multiple build backends (Docker, Kaniko, Buildpacks, Bazel, jib) to let users choose their preferred container build strategy.

• Synchronous build-push-deploy pipeline in dev loop

  • Why: Simplifies user mental model and ensures feedback is immediate and sequential.
  • Consequence: Slower iteration if any step is slow; no pipelining between build, push, and deploy.

• File watching and rebuild triggered at source level, not container level

  • Why: Reduces complexity and allows users to define rebuild logic via skaffold.yaml.
  • Consequence: Misses optimization opportunities like layer caching or incremental container updates.

• Single skaffold.yaml per project root

  • Why: Simpler mental model and discoverability for new users.
  • Consequence: Multi-repo or monorepo workflows require more complex configurations or multiple runs.

• Does not manage Kubernetes cluster lifecycle (creation, deletion, upgrades).
• Does not provide service mesh or networking setup—assumes cluster already exists.
• Does not handle secrets management or credential rotation—relies on existing Kubernetes RBAC.
• Not a package manager or dependency resolver—assumes application dependencies are pre-managed.
• Does not provide real-time log aggregation or advanced debugging UI—focuses on CLI interaction.
• Not a CI/CD platform itself—designed as a building block for CI/CD pipelines (e.g., in Cloud Build, GitHub Actions).

Config-based design: Skaffold behavior is entirely driven by skaffold.yaml; missing or malformed config causes silent failures or cryptic errors—always validate schema. Kubeconfig dependency: Commands assume KUBECONFIG is set or ~/.kube/config exists; tests may fail locally if no K8s cluster is reachable. Docker/buildkit availability: Many builders require Docker daemon or buildkit; CI uses container-in-container or system Docker. Sync mode subtleties: file-sync (in dev.go) has edge cases with symlinks, large files, and permission changes—trap for new contributors modifying sync logic.

• File sync and rebuilds — Core feature of Skaffold dev mode; understanding how source changes trigger rebuilds vs. inline syncs vs. full redeploys is essential to optimize dev loop speed.
• Pluggable builders and deployers — Skaffold's architecture uses interface-based plugins (builders like Docker/Buildpacks, deployers like kubectl/Kustomize/Helm) to remain agnostic; contributors must understand the builder/deployer contract.
• Image tagging and registry push policy — Skaffold auto-detects when to rebuild vs. reuse images via tag strategies (timestamp, git SHA, etc.) and intelligently pushes to registries; misunderstanding this causes 'why is my image not deploying?' bugs.
• Skaffold profiles and context-aware config — Profiles allow different build/deploy pipelines per environment (dev, staging, prod); critical for multi-environment setups and a frequent source of user confusion.
• Port forwarding and log aggregation — Skaffold streams logs from deployed pods and forwards container ports to localhost; dev.go orchestrates this; bugs here break the local development experience.
• Skaffold render and GitOps integration — skaffold render outputs hydrated Kubernetes manifests without deploying, enabling CI/CD pipelines to use Skaffold as a build stage; key feature for enterprise GitOps workflows.
• Cobra CLI framework — Skaffold's command structure (build, deploy, dev, run, etc.) is built on Cobra; contributors adding commands must understand Cobra's command registration, flag binding, and subcommand patterns.

• kubernetes/kubernetes — Upstream Kubernetes; Skaffold's deploy logic depends on K8s API compatibility and kubectl behavior.
• moby/moby — Docker daemon and container runtime that Skaffold uses for building images and managing local clusters.
• GoogleContainerTools/kaniko — Sibling Google tool for building container images inside Kubernetes; Skaffold can use Kaniko as an alternative builder.
• helm/helm — Helm chart templating and deployment tool; Skaffold integrates Helm as a pluggable deployer option.
• tilt-dev/tilt — Alternative to Skaffold for local Kubernetes development; competitor with similar watch-build-deploy workflow but different config philosophy.

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 unit tests for cmd/skaffold/app/cmd/inspect_*.go commands

The inspect subcommands (inspect_build_env.go, inspect_config_dependencies.go, inspect_execution_modes.go, inspect_job_manifest_paths.go, inspect_modules.go, inspect_namespaces.go) lack corresponding _test.go files, while similar commands like build_test.go, debug_test.go, and delete_test.go have full test coverage. This represents a significant gap in test coverage for the inspection functionality.

• [ ] Create cmd/skaffold/app/cmd/inspect_build_env_test.go with unit tests for build environment inspection logic
• [ ] Create cmd/skaffold/app/cmd/inspect_config_dependencies_test.go with tests for dependency resolution
• [ ] Create cmd/skaffold/app/cmd/inspect_execution_modes_test.go with execution mode validation tests
• [ ] Create cmd/skaffold/app/cmd/inspect_job_manifest_paths_test.go with manifest path extraction tests
• [ ] Create cmd/skaffold/app/cmd/inspect_modules_test.go with module detection tests
• [ ] Create cmd/skaffold/app/cmd/inspect_namespaces_test.go with namespace handling tests
• [ ] Run 'make test' to ensure all tests pass and verify improved coverage metrics

Add integration tests for config management subcommands (config set/list/unset)

The config subcommands in cmd/skaffold/app/cmd/config/ (set.go, list.go, unset.go) have unit tests but lack integration tests that verify end-to-end config file persistence and multi-operation scenarios. The .github/workflows/integration-linux.yml exists but may not cover these workflows comprehensively.

• [ ] Review existing integration test patterns in .github/workflows/integration-linux.yml
• [ ] Create integration test file (e.g., cmd/skaffold/app/cmd/config/integration_test.go) testing config lifecycle
• [ ] Add test cases for: setting values, listing all configs, unsetting values, and verifying file persistence
• [ ] Test config interaction with different Kubernetes contexts and namespaces
• [ ] Ensure tests validate YAML syntax and format of generated config files

Add missing test coverage for cmd/skaffold/app/cmd/find_configs.go and generate_pipeline.go edge cases

While find_configs_test.go and init_test.go exist, the generate_pipeline.go command (which orchestrates config generation for CI/CD) lacks a corresponding test file. Additionally, find_configs_test.go should be expanded to cover edge cases like missing skaffold.yaml files, symlinks, and deeply nested directory structures.

• [ ] Create cmd/skaffold/app/cmd/generate_pipeline_test.go with tests for pipeline template generation
• [ ] Add tests for different pipeline providers (GCP Cloud Build, GitHub Actions, GitLab CI, etc.) if supported
• [ ] Expand cmd/skaffold/app/cmd/find_configs_test.go with edge case tests: empty directories, invalid YAML, permission errors, circular symlinks
• [ ] Add performance tests for find_configs with large directory trees (1000+ files)
• [ ] Test config discovery with flags like --config and --module-list from cmd/skaffold/app/cmd/flags.go

• Add missing unit tests for cmd/skaffold/app/cmd/config/*.go (list_test.go and set_test.go exist, but unset.go lacks tests); contributes to test coverage without deep architecture knowledge.
• Enhance help text and examples in cmd/skaffold/app/cmd/completion.go—shell completion is often underdocumented; good UX win for new users.
• Add inline documentation comments to the pluggable builder/deployer interfaces in pkg/ (inferred path); current code likely has minimal GoDoc, blocking IDE hints and onboarding.

The Skaffold project demonstrates a solid security posture with established security reporting procedures (SECURITY.md with Google's vulnerability disclosure program), active GitHub workflows for linting and code quality checks, and automated dependency management via dependabot. However, the codebase uses an outdated Go version (1.19) which is no longer supported and poses potential security risks. The main improvement areas include: (1) upgrading to a current Go version, (2) implementing comprehensive SBOM tracking, and (3) ensuring full visibility into all dependencies for vulnerability scanning. The presence of comprehensive testing infrastructure and security-focused CI/CD workflows indicates good security practices overall. No critical or high-severity vulnerabilities were identified from the static analysis of the provided file structure and metadata.

• Low · Outdated Go Version — go.mod (go 1.19). The codebase specifies Go 1.19 in the module file (go.mod). Go 1.19 is no longer actively supported and has reached end-of-life. This may expose the project to known vulnerabilities that are not patched in older Go versions. Fix: Upgrade to the latest stable Go version (1.22 or later). Update the go version directive in go.mod and test thoroughly to ensure compatibility.
• Low · Missing SBOM/Dependency Tracking Documentation — .github/dependabot.yml and root directory. While the repository uses dependabot.yml for dependency updates, there is no visible SBOM (Software Bill of Materials) or comprehensive dependency documentation visible in the provided file structure. This makes it harder to track and audit all dependencies for security vulnerabilities. Fix: Implement and maintain an SBOM using tools like syft or cyclonedx. Document all direct and transitive dependencies with their versions and known vulnerabilities.
• Low · Limited Visibility into Dependency Content — go.mod file. The provided go.mod file shows only the module declaration and version without listing actual dependencies. Without seeing the full dependency list, it's difficult to assess whether vulnerable packages are in use. Fix: Provide the complete go.mod and go.sum files for full dependency audit. Regularly run 'go mod tidy' and 'go list -json -m all' to review and audit dependencies.

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.