go-task

Field	Value
Type	Skill
Source	`~/.copilot/skills/go-task/SKILL.md`
Description	Author Taskfile.yml files for go-task and Task v3.51. Use when the user asks to create a task, add a task, write or scaffold a Taskfile, convert Makefile or package.json scripts to Task, or design build, test, lint, deploy, dev, setup, reset, kubectl, docker, or monorepo task workflows. Verify with the installed task binary, task —dry, task —list-all, yamllint, and shell syntax checks for referenced scripts. Do not use for GitHub Actions YAML, Makefiles, or application business logic.

Bundled Pages

Group	Name	Source
References	Taskfile Authoring Reference	`~/.copilot/skills/go-task/references/taskfile-authoring.md`
Resources	_meta	`~/.copilot/skills/go-task/_meta.json`
Scripts	Check Task Version	`~/.copilot/skills/go-task/scripts/check-task-version.sh`
Scripts	Verify Taskfile	`~/.copilot/skills/go-task/scripts/verify-taskfile.sh`
Templates	Taskfile	`~/.copilot/skills/go-task/templates/Taskfile.yml`
Templates	Taskfile.docker	`~/.copilot/skills/go-task/templates/Taskfile.docker.yml`
Templates	Taskfile.kubectl	`~/.copilot/skills/go-task/templates/Taskfile.kubectl.yml`
Templates	Taskfile.lint	`~/.copilot/skills/go-task/templates/Taskfile.lint.yml`
Templates Scripts	Bootstrap	`~/.copilot/skills/go-task/templates/scripts/bootstrap.sh`
Templates Scripts	Deploy	`~/.copilot/skills/go-task/templates/scripts/deploy.sh`
Templates Scripts	Reset	`~/.copilot/skills/go-task/templates/scripts/reset.sh`
Templates Scripts	Run	`~/.copilot/skills/go-task/templates/scripts/run.sh`

Source Content

Go-Task Author


Domain	go-task / Taskfile.yml authoring
Role	Taskfile author and reviewer
Scope	Taskfile schema v3, task design, includes, inputs, scripts, verification
Output	A working `Taskfile.yml`, optional included Taskfiles, and extracted `scripts/*.sh`
Pinned to	Task v3.51.1

Use this skill for Taskfile.yml work: creating a new Taskfile, adding tasks to an existing one, converting Makefile or npm scripts, designing incremental tasks with sources and generates, adding requires and preconditions, or splitting task families into includes.

Do not use this skill for GitHub Actions workflow YAML, Makefiles, Kubernetes manifests, Dockerfiles, or application code. Hand those to the relevant platform, backend, frontend, or CI skill.

Workflow

Inspect the existing repo conventions first: existing Taskfile.yml, Taskfile.*.yml, package.json scripts, Makefile, go.mod, scripts/, and README commands.
Confirm the installed Task version with scripts/check-task-version.sh when available, or task --version as a fallback.
Choose the smallest task surface that solves the request. Default to root Taskfile.yml with version: '3'; use includes only for separate domains such as docker, k8s, db, or docs.
Keep task names kebab-case and namespace groups with colons, such as docker:build or k8s:pods.
Use UPPERCASE variables and no-whitespace templates, such as {{.BINARY_NAME}}.
Push real logic into scripts/*.sh when a command needs conditionals, loops, or more than about two lines.
Guard risky or parameterized behavior with requires.vars, enum or enum.ref, preconditions, and prompt for destructive tasks.
Add sources, generates, or status when incremental skipping is meaningful.
Verify before handoff with task --dry, task --list-all, yamllint when installed, and bash -n or shellcheck on every referenced script.

Style Rules

Key order: version, includes, config, vars, env, dotenv, tasks.
Use two-space YAML indentation and one blank line between top-level sections and tasks.
Give every user-facing task a desc; mark helpers internal: true.
Quote any desc, summary, label, msg, or cmd containing a colon.
Use deps for parallel prerequisite work; use ordered task: calls in cmds for sequential steps.
Use {{.CLI_ARGS}} for pass-through args after --.
Keep .env and .env.local in dotenv where the repo uses env files; do not put secrets in committed files.
Prefer the bundled templates for new project scaffolds: templates/Taskfile.yml, templates/Taskfile.docker.yml, templates/Taskfile.kubectl.yml, and templates/scripts/*.sh. They already ship the standard vocabulary below.

Standard task vocabulary

Every dmwd-io project exposes the same verbs, so an engineer who learned one repo already knows them all. Scaffold these from templates/Taskfile.yml; never invent a synonym (start, serve, clean, bootstrap as a top-level verb) when a standard verb already covers the intent. The documentation lives in each task’s desc — task --list reads like a manual, so these never need re-explaining to a junior engineer.

Verb	Meaning	Notes
`task setup`	One-time bootstrap on a fresh clone (create `.env`, install deps, build)	Non-destructive; safe on an existing checkout
`task dev`	Local development / watch mode	Auto-detects the stack via `scripts/run.sh`
`task test`	Run the test suite	Extra args pass through after `--`
`task lint`	Run static analysis	Fans out to `lints:go` / `lints:py` / `lints:js` / `lints:docs` — see below
`task build`	Compile / bundle the app	Incremental via `sources` / `generates`
`task prod`	Production build, then run	-
`task reset`	DESTRUCTIVE — clean, reinstall, re-bootstrap	Guarded by `prompt:`; runs `reset.sh` then the bootstrap helper

Namespaced groups

Tool families live in their own included Taskfile and are called under a namespace, so the root file stays a readable index.

`docker:*`

From templates/Taskfile.docker.yml: docker:build, docker:run, docker:up, docker:down, and docker:push (the push confirms first via prompt: because the image leaves the machine).

`k8s:*`

From templates/Taskfile.kubectl.yml: k8s:context, k8s:pods, k8s:logs, k8s:apply, and k8s:crds. The k8s:crds task applies CustomResourceDefinitions with kubectl apply --server-side and waits for them to be established. It pairs with the helm skill: CRDs are always a separate kubectl step that runs BEFORE any Helm install or upgrade — never Helm-managed (no installCRDs, crds.enabled, CRD hooks, or app-of-apps CRD ownership). Run task k8s:crds first, then hand the chart install to the helm skill.

`lints:*` — one polyglot lint entrypoint instead of five

From templates/Taskfile.lint.yml (named lints, plural, to avoid colliding with the root lint verb): lints:go, lints:py, lints:js, lints:docs. Each is already a single-command consolidation of several underlying checkers (golangci-lint wraps ~15 Go linters; ruff replaces flake8/isort/pyupgrade/black; oxlint replaces eslint at 50-100x the speed with a custom no-unnecessary-react-import JS plugin; the technical-writing skill’s lint.py dispatches readability/Markdown/Mermaid/prose). Each degrades to a clear skip message — never a failure — when that language isn’t present in the repo (no go.mod, no pyproject.toml, etc.), and each properly propagates a real lint failure through to task lint’s exit code even when an optional tool (mypy, tsc, Biome) isn’t installed. task lint runs all four in one shot; live-tested against real Go/Python/JS/Markdown bugs plus every skip path.

Documentation and helper discipline

Every user-facing task carries a clear desc. Helpers shared by the standard verbs (such as the bootstrap step behind setup and reset) are internal: true, so they parse and run but never appear in task --list. Destructive tasks (reset, docker:push) use prompt: to confirm before acting; the prompt is skipped automatically under task --yes and in CI.

Verification

Prefer the bundled verifier:

/Users/davidholmes/.copilot/skills/go-task/scripts/verify-taskfile.sh

If the verifier does not fit the repo, run the equivalent checks manually:

task --version
task --list-all
task --dry <task-name>
yamllint Taskfile.yml
bash -n scripts/*.sh

Report any skipped check explicitly, including missing local tools such as task, yamllint, or shellcheck.

References

Load references/taskfile-authoring.md only when deeper Task syntax, recipes, or edge-case behavior is needed.