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/sagiegurari/cargo-make 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 3mo ago
• 3 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 3mo ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 63% 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 sagiegurari/cargo-make repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sagiegurari/cargo-make.

What it runs against: a local clone of sagiegurari/cargo-make — 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 sagiegurari/cargo-make | 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 ≤ 121 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sagiegurari/cargo-make(\\.git)?\\b" \\
  && ok "origin remote is sagiegurari/cargo-make" \\
  || miss "origin remote is not sagiegurari/cargo-make (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 "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "src/cli/cli.rs" \\
  && ok "src/cli/cli.rs" \\
  || miss "missing critical file: src/cli/cli.rs"
test -f "src/cli/types.rs" \\
  && ok "src/cli/types.rs" \\
  || miss "missing critical file: src/cli/types.rs"
test -f "src/cli/runner.rs" \\
  && ok "src/cli/runner.rs" \\
  || miss "missing critical file: src/cli/runner.rs"
test -f "src/cli/config.rs" \\
  && ok "src/cli/config.rs" \\
  || miss "missing critical file: src/cli/config.rs"

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

cargo-make is a Rust task runner and build tool that executes workflows defined in TOML-based Makefile.toml files, supporting multi-platform task execution with dependencies, environment variable management, script embedding (Duckscript, shell, Rust), and workspace integration. It replaces traditional Make for Rust projects with cross-platform capabilities and tight cargo integration. Dual-binary structure: src/lib/mod.rs exports the 'cli' library with core CLI and task-execution logic, while src/main.rs (cargo-make) and src/makers.rs (standalone makers binary) are entry points. Task graph execution uses petgraph for DAG resolution. Configuration is TOML-parsed from Makefile.toml and extended via docs/_includes/ templates.

Rust developers and CI/CD engineers who need to define complex build workflows, test suites, and deployment pipelines in a declarative, platform-agnostic way without shell script fragmentation or platform-specific gotchas.

Production-ready and actively maintained. At v0.37.24 with 1.2M+ lines of Rust code, comprehensive CI/CD in .github/workflows/ (ci.yml, publish.yml, cron.yml), 1000+ crates.io downloads, and a stable API documented in docs/api/. Latest commits and dependabot integration confirm ongoing maintenance.

Single-author project (sagiegurari) increases bus-factor risk. Heavy dependency chain (cargo_metadata, duckscript, duckscriptsdk, serde ecosystem, petgraph) creates supply-chain surface area, though all are pinned to caret versions. No breaking changes visible in recent CHANGELOG.md, suggesting API stability. Dependabot enabled mitigates drift risk.

Active CI/CD with GitHub Actions workflows running on commits and scheduled cron jobs. .buildnumber tracking and publish.yml suggest regular releases. Dependabot configured for dependency updates. No explicit PR/milestone data visible, but recent Cargo.lock changes and version bumps (0.37.x) indicate active development.

Clone: git clone https://github.com/sagiegurari/cargo-make.git && cd cargo-make. Build: cargo build --release. The repo includes Makefile.toml with self-hosted test/build tasks—run cargo make to see available tasks.

Daily commands: After cargo build, invoke with cargo make <task_name>. Development iteration: cargo make (runs default task), cargo make --list-all-steps (shows all tasks), cargo make test (runs test suite defined in Makefile.toml). Use RUST_LOG=debug cargo make to see detailed execution flow.

• src/main.rs — Entry point for cargo-make CLI; must understand how arguments are routed and the main execution flow begins here.
• src/cli/cli.rs — Core CLI runner that orchestrates task execution; essential for understanding how tasks are loaded, validated, and executed.
• src/cli/types.rs — Defines all core data structures (Config, Task, CliArgs, etc.); understanding these types is foundational for any code modification.
• src/cli/runner.rs — Task execution engine that handles task dependencies, conditions, and script execution; critical for task flow logic.
• src/cli/config.rs — Configuration loading and parsing logic; essential for understanding how Makefile.toml files are read and deserialized.
• Cargo.toml — Project dependencies and metadata; understanding version constraints and feature flags is necessary for contributing.
• Makefile.toml — The project's own task definitions; demonstrates best practices and serves as reference for Makefile.toml syntax.

• main.rs (Rust std, log crate) — Binary entry point; initializes logger and delegates to CLI runner
  • Failure mode: Unhandled panic; would terminate without graceful error message
• cli_parser.rs (clap) — Constructs clap command-line interface and parses user arguments into CliArgs struct
  • Failure mode: Invalid argument or parsing error; clap prints help and exits with code 2
• undefined — undefined

Add a new task to Makefile.toml

1. Edit Makefile.toml and add a new [tasks.your_task_name] section with script, command, or dependencies (Makefile.toml)
2. Define task properties: description, script/command, dependencies, conditions, env vars (Makefile.toml)
3. Run 'cargo make your_task_name' to test execution (N/A)

Add a new CLI flag or argument

1. Define the new argument in the clap builder in src/cli/cli_parser.rs (using Arg::new() and appropriate options) (src/cli/cli_parser.rs)
2. Add corresponding field to the CliArgs struct in src/cli/types.rs (src/cli/types.rs)
3. Extract the argument value in the parse_args function and populate CliArgs (src/cli/cli_parser.rs)
4. Use the new flag in src/cli/cli.rs or src/cli/runner.rs to modify execution behavior (src/cli/cli.rs)

Add a new task condition type or evaluation logic

1. Add variant to ConditionType enum or ConditionScriptValue enum in src/cli/types.rs (src/cli/types.rs)
2. Implement evaluation logic in src/cli/runner.rs in the condition checking function (src/cli/runner.rs)
3. Update documentation in README.md or docs files if the condition is user-facing (README.md)

Extend configuration parsing for new task properties

1. Add new field to Task struct (or relevant Config substruct) in src/cli/types.rs with appropriate derive macros (src/cli/types.rs)
2. Ensure TOML deserialization works via serde attributes (skip or rename as needed) (src/cli/types.rs)
3. Implement logic to use the new field during task execution in src/cli/runner.rs (src/cli/runner.rs)
4. Test by adding a Makefile.toml example task using the new property (Makefile.toml)

• Rust (Edition 2021) — Compiled language provides performance and safety for a build tool; static typing catches configuration errors early
• TOML (Makefile.toml) — Human-readable configuration format familiar to Rust community; serde enables seamless deserialization
• Clap (CLI argument parsing) — Declarative CLI definition reduces boilerplate; generates help text and shell completions automatically
• Serde (Serialization/Deserialization) — Flexible TOML parsing with strong type safety; supports nested structures and custom derives
• Log crate (Logging) — Standard Rust logging facade; integrates with env_logger for runtime verbosity control

• Task definitions in TOML rather than Rust code

  • Why: Non-developers can write tasks without programming knowledge; tasks can be version-controlled separately from tool code
  • Consequence: TOML parsing complexity; requires serde integration and careful error messaging for config mistakes

• Synchronous task execution by default with optional parallelism

  • Why: Simpler mental model and debugging; matches Makefile behavior expectations
  • Consequence: Sequential execution can be slower for independent tasks; async implementation is optional

• Shell script execution for task commands

  • Why: Familiar to developers; leverages existing shell tools and cross-platform compatibility
  • Consequence: Shell injection risks if user input is included; platform-specific behavior (Windows vs Unix shells)

• Cargo plugin architecture via subcommand

  • Why: Integrates naturally with Rust workflow (cargo make); automatic availability via cargo
  • Consequence: Tight coupling to Cargo; less suitable for non-Rust projects

• Does not provide a GUI; CLI-only interface
• Does not manage external dependencies or version pinning; delegates to Cargo/package managers
• Does not provide real-time task monitoring or web dashboard
• Does not support distributed/networked task execution
• Not a replacement for CI/CD systems; integrates with them instead

Makefile.toml is mandatory in project root or loaded from workspace Makefile.toml—missing it breaks task discovery. Environment variable loading order is significant (env declaration → global config → task-specific → CLI override → env file → setup scripts); see README for exact precedence. Duckscript SDK features (tls-rustls vs tls-native) must be consistent across dependency tree or linking fails. Workspace extension via Makefile.toml can create circular extend dependencies if not careful. Platform-specific tasks require explicit [platform] sections; missing them causes silent fallback.

• Directed Acyclic Graph (DAG) task execution — cargo-make uses petgraph to build and traverse task dependency graphs, ensuring correct execution order and cycle detection—core to reliable build workflows.
• TOML configuration as code — Makefile.toml replaces Makefiles with strongly-typed, nested TOML structure parsed via serde—enables IDE support and reduces syntax errors.
• Cross-platform shell translation (shell2batch) — Cargo-make converts bash shell scripts to batch on Windows without manual rewrites, critical for CI/CD portability in heterogeneous teams.
• Environment variable scoping and precedence — Multi-level env resolution (global → task → CLI → file → setup scripts) with explicit precedence rules prevents configuration surprises in large projects.
• Workspace extension and task inheritance — Cargo-make can extend external Makefile.tomls and override tasks per-platform, enabling DRY monorepo task definitions across heterogeneous member crates.
• Duckscript embedded DSL — Custom scripting language (duckscriptsdk dependency) enables logic in tasks without spawning subshells, with built-in functions for file ops, logging, and conditionals.
• Cargo metadata introspection — Via cargo_metadata crate, cargo-make reads workspace structure, member crates, and dependency trees to parameterize multi-crate builds and targeted task execution.

• just-rs/just — Direct alternative task runner for Rust with TOML-based task syntax, but simpler scoping and no workspace-level extension like cargo-make.
• casey/just — Predecessor inspiration; justfile format influenced modern task-runner design in the Rust ecosystem.
• rust-lang/cargo — Parent ecosystem; cargo-make is a cargo subcommand and introspects workspace metadata via cargo_metadata crate.
• task-rs/task — Competing task runner for Rust; uses YAML instead of TOML, worth comparing feature parity and syntax ergonomics.
• sagiegurari/duckscript — Authored by same maintainer; embedded scripting language deeply integrated into cargo-make for cross-platform task logic.

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 CLI argument parsing in src/lib/cli/cli_parser/mod.rs

The repo has a CLI parser module (docs/api/cli/cli_parser/) but lacks visible integration tests covering edge cases like conflicting flags, invalid combinations, and environment variable overrides. This is critical for a build tool where CLI parsing errors directly impact user experience. New contributors can add tests in tests/ directory covering scenarios like --profile with invalid values, --makefile with non-existent paths, and task argument escaping.

• [ ] Create tests/cli_parser_integration_tests.rs with test cases for argument validation
• [ ] Add tests for mutually exclusive flags (e.g., --list-all-steps vs --print-steps)
• [ ] Add tests for environment variable interpolation in CLI arguments
• [ ] Add tests for special character handling in task arguments and file paths
• [ ] Run with cargo test and ensure all pass

Add shell completion tests for bash/zsh/fish in tests/completion_tests.rs

The repo has a completion module (docs/api/cli/completion/) that generates shell completions, but there are no visible tests validating the generated completion scripts actually work in their target shells. This is important for UX. Contributors can add tests that generate completions and validate their syntax/functionality against actual shell parsers.

• [ ] Create tests/completion_tests.rs to test completion generation
• [ ] Add tests validating bash completion script syntax using 'bash -n'
• [ ] Add tests validating zsh completion script syntax
• [ ] Add tests for fish completion with fish -n syntax checking
• [ ] Test that generated completions include all available tasks from Makefile.toml
• [ ] Run with cargo test to ensure validations pass

Refactor error handling module to separate CargoMakeError variants into dedicated submodules in src/lib/cli/error/

The error module (docs/api/cli/error/enum.CargoMakeError.html) currently centralizes all error types in one file. As the codebase grows (evidenced by the large dependency tree), splitting error types into logical submodules (e.g., config_errors.rs, runtime_errors.rs, validation_errors.rs) would improve maintainability and make it easier for contributors to understand error handling patterns. This also enables better error-specific helper functions.

• [ ] Analyze src/lib/cli/error/mod.rs to categorize CargoMakeError variants by concern
• [ ] Create src/lib/cli/error/config_errors.rs for config-related errors
• [ ] Create src/lib/cli/error/runtime_errors.rs for execution-related errors
• [ ] Create src/lib/cli/error/validation_errors.rs for input validation errors
• [ ] Update src/lib/cli/error/mod.rs to re-export from submodules
• [ ] Update all existing error creation sites to use new structure
• [ ] Verify all tests still pass with cargo test

• Add integration tests for task graph cycle detection in petgraph execution—docs/api shows task DAG resolution but no explicit test coverage visible for circular dependency prevention.
• Document the env-var loading order with runnable examples in docs/_includes/—README mentions it but no worked examples exist showing interaction between task env, global config, and env files.
• Write cross-platform shell2batch translation tests for edge cases (pipes, redirects, conditionals) to expand coverage beyond basic command execution paths.

cargo-make has a generally secure posture for a Rust build tool. The codebase uses well-maintained dependencies and modern Rust practices (edition 2021). Primary security considerations are inherent to its design as a task runner that executes arbitrary scripts and commands. Key recommendations: (1) Implement security advisories monitoring for dependencies, (2) Update sha2 dependency strategy to allow patch updates, (3) Add explicit warnings in documentation about running untrusted Makefile.toml files, (4) Ensure proper input validation and sanitization for all user-provided task definitions before execution. No hardcoded secrets, SQL injection risks, or infrastructure misconfigurations detected.

• Medium · Outdated SHA2 Dependency — Cargo.toml - dependencies: sha2 = "0.10.9". The sha2 crate is pinned to version 0.10.9 without patch version flexibility. While not critically vulnerable, this limits automatic security updates through cargo update for patch releases. Fix: Change to sha2 = "0.10" to allow patch updates, or regularly review and update to newer minor/major versions (currently at 0.13.x). Implement dependabot or similar to monitor for security updates.
• Low · TLS Feature Default Uses Rustls — Cargo.toml - features: tls = ["tls-rustls"]. The default TLS feature (tls) is aliased to tls-rustls. While Rustls is a secure choice, the default should be explicitly documented. Users may not realize they're using Rustls and could have expectations about native OS certificate stores. Fix: Document the default TLS backend choice clearly in README and feature documentation. Consider if tls-native should be the default on platforms where it's available.
• Low · Script Execution Capabilities — Cargo.toml - dependencies: duckscript, run_script. The crate includes duckscript and run_script dependencies, indicating arbitrary script execution capabilities. This is by design for a task runner, but increases attack surface if task files come from untrusted sources. Fix: Ensure documentation clearly warns users about the risks of running Makefile.toml from untrusted sources. Implement optional sandboxing or restricted execution modes for untrusted task files.
• Low · Dynamic Process Execution — src/ - runner and execution modules (inferred from file structure). As a task runner, the tool executes arbitrary commands and scripts. Ensure proper input validation and escaping when constructing shell commands from user-provided task definitions. Fix: Validate and sanitize all user-provided inputs before passing to shell execution. Use shell-safe parameter passing mechanisms. Implement logging of executed commands for audit trails.
• Low · File System Access Without Validation — Cargo.toml - dependencies: fsio, glob, ignore. The crate uses fsio and glob for file operations. Task definitions could potentially specify paths that access sensitive files if not properly validated. Fix: Implement path canonicalization and validation to prevent directory traversal attacks. Restrict file operations to intended project directories when running untrusted tasks.

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.