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/nuke-build/nuke 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 all four use cases

• Last commit 5mo ago
• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Single-maintainer risk — top contributor 93% of recent commits

_{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 nuke-build/nuke repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nuke-build/nuke.

What it runs against: a local clone of nuke-build/nuke — 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 nuke-build/nuke | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 189 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "build/_build.csproj" \\
  && ok "build/_build.csproj" \\
  || miss "missing critical file: build/_build.csproj"
test -f "build/Build.cs" \\
  && ok "build/Build.cs" \\
  || miss "missing critical file: build/Build.cs"
test -f ".nuke/build.schema.json" \\
  && ok ".nuke/build.schema.json" \\
  || miss "missing critical file: .nuke/build.schema.json"
test -f "Directory.Build.targets" \\
  && ok "Directory.Build.targets" \\
  || miss "missing critical file: Directory.Build.targets"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"

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

NUKE is a code-first build automation system for C#/.NET projects that replaces traditional build tools like MSBuild or Cake by letting developers write strongly-typed, IDE-friendly build logic directly in C#. It compiles build scripts into standalone executables (build.cmd, build.sh, build.ps1) and integrates deeply with .NET tooling, CI/CD platforms (TeamCity, GitHub Actions, Azure Pipelines, AppVeyor), and IDE runners (.run files). Multi-layered structure: source/ contains core NUKE framework libraries (strongly-typed task definitions, CI integrations, parameter handling); build/ folder is a meta-example using NUKE to build NUKE itself (bootstrapped pattern); .nuke/ holds schema and parameters; .github/workflows/, .teamcity/, azure-pipelines.yml, and appveyor.yml define CI gates. The build.cmd, build.sh, build.ps1 entry points are generated from the C# build definition.

.NET/C# developers and DevOps engineers who want to define build pipelines, packaging, testing, and deployment logic using C# instead of XML, YAML, or scripting languages—particularly those managing complex monorepos or multi-platform builds across Windows, macOS, and Linux.

NUKE is actively maintained and production-ready. The repo shows dense C# codebase (~11.6M lines), extensive CI coverage (workflows for Windows/macOS/Ubuntu, TeamCity, GitHub Actions), NuGet publishing with pre-release versions, and professional tooling (GitVersion.yml, Directory.Build.targets). Last commit recency and the scale of GitHub workflows indicate active development.

Low risk for a mature build tool, but consider: tight coupling to .NET SDK versions (Directory.Packages.props suggests centralized dependency management that could break), reliance on code generation (build/Build.CodeGeneration.cs suggests generated build files that must stay in sync), and build scripts as C# code mean failures can block CI entirely. The project appears single-maintainer-friendly but community-driven features depend on issue triage speed.

Based on file structure: active work on code generation (Build.CodeGeneration.cs), CI/CD unification across platforms (multiple workflow files), MSBuild task integration (./build/Run MSBuildTasks.run.xml suggests tooling integration), and global tool distribution (.run/GlobalTool files suggest CLI expansion). The alpha-deployment.yml and code-quality.yml workflows indicate continuous refinement.

git clone https://github.com/nuke-build/nuke.git cd nuke ./build.sh (macOS/Linux) or ./build.cmd (Windows) or pwsh ./build.ps1 (PowerShell)

Alternatively, nuke itself is a global tool:

dotnet tool install Nuke.GlobalTool --global nuke --help

Daily commands: If you've cloned the repo: ./build.sh (Linux/macOS) – runs default Compile target ./build.cmd (Windows cmd.exe) pwsh ./build.ps1 (PowerShell) If using NUKE as a global tool in your own project: nuke --init:empty # scaffold a new build.cs nuke --list # show available targets nuke [TargetName] # run a target

• build/_build.csproj — The entry point build project that defines the Nuke build system configuration and dependencies for the entire repo.
• build/Build.cs — Core build orchestration file containing the main build targets and workflow logic for the Nuke framework.
• .nuke/build.schema.json — Build schema definition that validates and documents all configurable build parameters and targets.
• Directory.Build.targets — Global MSBuild targets configuration applied to all projects, defining common build behavior across the solution.
• Directory.Packages.props — Centralized NuGet package version management ensuring consistent dependencies across all projects.
• README.md — Project overview and getting-started guide that explains Nuke's purpose as a C#/.NET build system alternative to Make.
• .github/workflows/code-quality.yml — CI/CD pipeline definition for automated code quality checks and testing across all pull requests.

• Build.cs (Core) (C#, Nuke.Common abstractions) — Orchestrates target execution, manages dependencies, and exposes the public build API
  • Failure mode: Build execution fails completely; cascading failure across all dependent targets
• Build.CI.*.cs (Platform Integration) (Environment variables, platform-specific APIs) — Detects and adapts build behavior for specific CI/CD environments
  • Failure mode: CI-specific features unavailable; build still executes but loses platform context
• MSBuild integration (MSBuild Engine, Visual Studio SDK) — Compiles source code and executes standard .NET build operations
  • Failure mode: Compilation failures halt build; partial builds prevent artifact generation
• External Tool Integrations (Tool-specific CLIs and APIs) — Wraps code analysis, signing, package management, and other external tools
  • Failure mode: Individual tool failures are isolated; build continues unless explicitly configured as blocking
• Schema & IDE Integration (JSON schema, IDE plugins) — Provides build target discovery and IntelliSense support in development environments
  • Failure mode: Loss of IDE support; targets still executable from CLI

• Developer CLI input → Build.cs — Target names and parameters passed to build orchestrator
• Directory.Packages.props → build/_build.csproj — Package versions propagate to build project dependencies
• build.schema → undefined — undefined

Add a new build target

1. Create a new partial class file in the build folder following the naming pattern Build.FeatureName.cs (build/Build.NewFeature.cs)
2. Define a public Target method with [PublicAPI] attribute and Task return type, use [DependsOn()] to specify dependencies (build/Build.NewFeature.cs)
3. Register the target in Build.cs by creating a property that returns the target method from your partial class (build/Build.cs)
4. Validate the schema updates in .nuke/build.schema.json to ensure the new target is discoverable (.nuke/build.schema.json)

Add a new CI/CD platform integration

1. Create a new build partial file Build.CI.PlatformName.cs following existing CI patterns (build/Build.CI.PlatformName.cs)
2. Implement platform-specific properties using abstract members from Build.cs (e.g., EnvironmentVariable, IsCI detection) (build/Build.CI.PlatformName.cs)
3. Create a corresponding workflow file in .github/workflows/ or equivalent for your platform (.github/workflows/platform-integration.yml)
4. Register the platform detection in the main Build class to enable automatic environment recognition (build/Build.cs)

Add a new global build package or tool

1. Add the NuGet package reference to Directory.Packages.props with appropriate version specification (Directory.Packages.props)
2. Add a PackageReference in build/_build.csproj if the tool is needed specifically during build execution (build/_build.csproj)
3. Create helper methods in a new or existing Build.*.cs partial class to provide convenient access to the tool (build/Build.ToolIntegration.cs)
4. Update .editorconfig and Directory.Build.targets if the tool introduces new code style or compilation settings (Directory.Build.targets)

• C# / .NET — Nuke is a build system specifically designed for C#/.NET projects, using the same language as the projects being built
• MSBuild — Standard build engine for .NET projects; Nuke wraps and orchestrates MSBuild targets across solutions
• GitHub Actions / TeamCity / Azure Pipelines — Multi-platform CI/CD integration allows Nuke builds to run consistently across diverse deployment environments
• NuGet — Package management system for .NET; Nuke distributes itself as a NuGet package for easy installation and updates

• C# DSL for build definitions instead of scripting languages

  • Why: Provides strong typing, IntelliSense, and code reuse for complex build logic
  • Consequence: Requires .NET toolchain to execute builds; steeper learning curve than simple shell scripts but better maintainability

• Modular partial class architecture (Build.*.cs files)

  • Why: Keeps build logic organized and allows multiple features to coexist without merge conflicts
  • Consequence: More files to navigate but clearer separation of concerns; requires discipline to organize features logically

• Schema-driven build target discovery (.nuke/build.schema.json)

  • Why: Enables IDE integration and external tooling to discover available targets without execution
  • Consequence: Schema must be kept in sync with actual build code; adds maintenance overhead but improves developer experience

• Does not replace MSBuild; wraps and orchestrates it instead
• Not a general-purpose task runner; focused specifically on .NET build workflows
• Does not provide its own package management; integrates with NuGet
• Not designed for non-.NET projects or cross-platform scripting beyond C# context

1. Bootstrap dependency: The build.sh/.cmd/.ps1 files must be present and in sync with build.cs; if missing or stale, the build won't initialize. 2. Schema regeneration: Changes to parameters in build.cs require .nuke/build.schema.json to be regenerated (often via nuke :setup or similar), or IDE intellisense breaks. 3. CI platform auto-detection: NUKE detects the CI platform at runtime via environment variables; if running locally without those env vars set, certain targets may skip or behave differently. 4. Generated code in version control: Many .run files and .nuke/build.schema.json are generated; committing stale versions breaks IDE experience.

• Fluent API / Method Chaining — NUKE's core abstraction for defining task dependencies and pipeline flows in C#; understanding fluent builders is essential for writing clean, readable build definitions
• Code Generation / Metaprogramming — NUKE generates parameter classes and CI integration attributes from schemas and build.cs; mastering this pattern unlocks extensibility and IDE integration
• MSBuild Task Integration — NUKE wraps and orchestrates MSBuild tasks (compilation, packaging, testing); understanding MSBuild targets and properties is critical for leveraging existing .NET tooling
• CI/CD Platform Abstraction — NUKE detects and adapts to TeamCity, GitHub Actions, Azure Pipelines, AppVeyor via environment variables and attributes; this abstraction lets a single build definition run on multiple CI platforms
• Strong Typing in Build Definitions — Unlike YAML or shell scripts, NUKE build.cs code is compiled C# with full type-checking; this prevents entire classes of runtime errors in CI/CD logic
• Bootstrapping Pattern — NUKE's build.sh/build.cmd/build.ps1 entry points self-compile the C# build logic without requiring pre-installed tools; this pattern ensures the build is hermetic and reproducible
• Schema-Driven Parameter Binding — .nuke/build.schema.json defines typed parameters that auto-generate C# classes and validate input from CI env vars or CLI args; critical for safe, IDE-friendly parameter passing

• cake-build/cake — Alternative C#-based build automation tool using Roslyn/scripting; direct competitor solving the same 'code-first builds' problem but with different API and execution model
• dotnet/msbuild — The native .NET build system that NUKE builds upon and integrates with; understanding MSBuild tasks and props is foundational for advanced NUKE usage
• jqlang/jq — While not .NET-specific, NUKE pipelines often filter/transform data (logs, artifacts); jq is the standard CLI tool for JSON querying that build scripts call
• nuke-build/nuke-examples — Official repository of real-world NUKE build scripts demonstrating patterns for ASP.NET, Xamarin, Docker integration, and multi-platform builds
• actions/setup-dotnet — GitHub Action that NUKE CI workflows rely on to bootstrap .NET SDK before running build.sh; essential for understanding NUKE's GitHub Actions integration

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 GitHub Actions workflow for code coverage reporting to Codecov

The repo has multiple CI workflows (ubuntu-latest.yml, windows-latest.yml, macos-latest.yml) but lacks a dedicated codecov integration workflow. Given the presence of DotCover references in build/references/DotCover.ref.000.txt and the sophistication of the build system, adding automated coverage reporting would improve visibility into test coverage trends and help new contributors understand quality standards.

• [ ] Create .github/workflows/codecov.yml that runs on pull requests and pushes to develop/main
• [ ] Configure the workflow to run dotcover/code coverage collection (reference existing build/references/DotCover.ref.000.txt)
• [ ] Add codecov/codecov-action@v3 to upload coverage reports
• [ ] Update README.md with codecov badge similar to existing NuGet and download badges
• [ ] Document coverage requirements in CONTRIBUTING.md

Extract Build.Terminal.cs concerns into separate modular files

The build/ directory contains multiple Build..cs partial class files (Build.CI., Build.GlobalSolution.cs, etc.) but Build.Terminal.cs likely handles multiple terminal/console output concerns. This monolithic file should be split into focused modules like Build.Terminal.Output.cs, Build.Terminal.Logging.cs, and Build.Terminal.Colors.cs to follow the established organizational pattern and improve maintainability.

• [ ] Analyze Build.Terminal.cs to identify distinct concerns (output formatting, logging, ANSI colors, etc.)
• [ ] Create separate partial class files: Build.Terminal.Output.cs, Build.Terminal.Logging.cs, Build.Terminal.Formatting.cs
• [ ] Move related methods and properties to appropriate files
• [ ] Ensure all partial classes remain in the build/ directory with consistent naming
• [ ] Add unit tests in a new build.Tests/ folder to verify terminal output behavior

Add integration tests for Docker build execution (Build.RunTargetInDockerTest.cs reference)

The build file structure includes Build.RunTargetInDockerTest.cs which suggests Docker test functionality exists, but the presence of both Dockerfile and .github/workflows files indicates this feature may lack comprehensive test coverage. Adding a dedicated GitHub Actions workflow that validates Docker build scenarios would catch regressions and document the expected Docker behavior.

• [ ] Review Build.RunTargetInDockerTest.cs to understand current test patterns
• [ ] Create .github/workflows/docker-integration-tests.yml workflow
• [ ] Add test cases for: building nuke targets inside Docker container, volume mounting, environment variable passing
• [ ] Reference the Dockerfile at repo root in the workflow
• [ ] Document Docker usage and testing expectations in CONTRIBUTING.md with examples from build/ directory

• Add a missing CI platform adapter: NUKE supports AppVeyor, TeamCity, GitHub Actions, Azure Pipelines—implement a Gitea or Woodpecker CI integration following the pattern in build/Build.CI.*.cs files.
• Improve parameter validation: Add null-safety checks and type coercion docs for the schema-generated parameters in .nuke/build.schema.json; currently some edge cases in parameter binding aren't documented.
• Expand global tool commands: The .run/GlobalTool_*.run.xml files hint at incomplete global tool features; implement or document missing subcommands like 'nuke :secrets' or 'nuke :configure-ci'.

The NUKE build system codebase presents moderate security concerns primarily around Docker build practices, dependency management, and potential secrets exposure in CI/CD configurations. The main risks involve unrestricted source copying in Docker builds, unvalidated external repository dependencies with snapshot builds enabled, and potential credential leakage through build artifacts and CI/CD logs. The incomplete maven configuration raises additional concerns about file integrity. Recommendations focus on implementing strict input validation, secret management integration, dependency verification, and container security hardening. No direct code injection vulnerabilities (SQLi/XSS) were identified in the provided file structure, but the build system's complexity creates opportunities for supply chain attacks.

• High · Unrestricted Docker Build from Untrusted Source — Dockerfile. The Dockerfile copies all repository contents (COPY ./ /code) and executes build scripts without validation. This creates a supply chain risk where malicious code in the repository could be executed during image building. Fix: Implement strict file validation, use .dockerignore to exclude sensitive files, verify build script integrity, and consider using multi-stage builds with minimal final images. Add signature verification for critical build scripts.
• High · Potential Secrets Exposure in Build Artifacts — Dockerfile, build/ directory, .github/workflows/. The build process references multiple CI/CD configuration files (.github/workflows, .teamcity, azure-pipelines.yml, appveyor.yml) and sensitive build scripts. These files may contain or generate secrets that could be exposed in Docker layers or build logs. Fix: Implement secret scanning in CI/CD pipelines, use secret management tools (HashiCorp Vault, Azure Key Vault), never log or expose secrets in build output, and scan Docker images for embedded credentials.
• Medium · Missing Build Argument Validation — Dockerfile (line: ARG registryUrl). The Dockerfile accepts an ARG 'registryUrl' without validation or constraints. This could allow registry injection attacks if the argument is used in subsequent build commands. Fix: Validate the registryUrl parameter against a whitelist of approved registries, sanitize the input, and document expected format constraints.
• Medium · Unverified External Repository Dependencies — .teamcity/pom.xml (repositories section). The pom.xml references external repositories (jetbrains-all, teamcity-server) with snapshot builds enabled. This allows automatic downloads of potentially unsigned or unverified artifacts. Fix: Disable snapshot builds in production, implement repository signing verification, use repository mirroring with content validation, and regularly audit transitive dependencies.
• Medium · Incomplete Kotlin Maven Plugin Configuration — .teamcity/pom.xml (kotlin-maven-plugin section). The pom.xml shows truncated/incomplete plugin configuration which may indicate file corruption or intentional obfuscation. The kotlin-maven-plugin configuration is missing crucial security settings. Fix: Complete and review the full plugin configuration, verify file integrity, implement plugin version pinning, and add signature verification for Maven plugins.
• Low · Sensitive File Path Exposure — Root directory structure (.github/, .teamcity/, .gitlab-ci.yml, azure-pipelines.yml, appveyor.yml). File structure exposes build configuration files and references that could reveal internal build systems, CI/CD providers, and infrastructure details useful for reconnaissance. Fix: Review what CI/CD information is necessary to expose publicly, consider using GitHub/GitLab secret management for sensitive configuration, and implement security through obscurity where applicable.
• Low · Missing Container Security Context — Dockerfile. The Dockerfile does not specify a non-root user, resource limits, or security options. The builder stage runs as root with full privileges. Fix: Add a non-root user (USER), specify resource limits in orchestration configs, use read-only filesystems where possible, and implement least privilege principles for container execution.

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.