Agent Repository Task Runners and Package Scripts

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Repository task runners tell agents which commands are authoritative for build, test, lint, verify, code generation, deployment, and local reproduction.

## Core Explanation

Agents should not guess project commands from framework names. The repository usually defines its own command surface through `package.json`, Makefiles, CI workflows, task files, and documentation. Those commands encode environment setup, generated artifacts, cache behavior, test grouping, and deployment assumptions.

Useful evidence includes the command name, runner, working directory, package manager, shell, environment variables, required files, dependency install step, and whether the command is local-only, CI-only, destructive, or deploy-capable. Before changing code, an agent should identify the smallest existing command that verifies the affected behavior.

## Source-Mapped Facts

- npm documentation says the scripts property of package.json supports built-in lifecycle events and arbitrary scripts. ([source](https://docs.npmjs.com/cli/v11/using-npm/scripts/))
- Node.js child_process documentation describes the module as enabling the spawning of child processes. ([source](https://nodejs.org/api/child_process.html))
- GitHub Actions workflow syntax documentation says a job contains a sequence of tasks called steps. ([source](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax))

## Further Reading

- [npm Scripts](https://docs.npmjs.com/cli/v11/using-npm/scripts/)
- [Node.js child_process](https://nodejs.org/api/child_process.html)
- [GitHub Actions Workflow Syntax](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax)