agentleFS
aaronfloreyaaronflorey/agent-skills/skills/taskfile/SKILL.md

taskfile

Skill2 starsChanged 7 months agoMITView on GitHub

Build, debug, and refactor `Taskfile.yml` or `Taskfile.yaml` automation using go-task and the `task` CLI. Use this skill whenever the user mentions Taskfile, go-task, `task`, task dependencies, includes, variables, templates, `sources` or `generates` caching, taskfiles split across directories, or migrating Makefiles or npm scripts to Task.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 2 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill to create production-grade Taskfile.yml automation for local dev, CI, and monorepos.

    line 11
  2. Distinctive:

    add tasks to existing Taskfile,

    line 24
  3. Very specific:

    Prefer small, composable tasks with clear desc and predictable variables.

    line 27
  4. Very specific:

    Keep root schema on version: '3' unless user needs stricter semver gating.

    line 31
  5. Very specific:

    Use desc on user-facing tasks so task --list is useful.

    line 32
  6. Very specific:

    Use internal: true for helper tasks not meant for direct invocation.

    line 33
  7. Very specific:

    Use deps for parallelizable prerequisites.

    line 34
  8. Very specific:

    Use requires.vars for mandatory inputs and enum constraints for safety.

    line 35
  9. Very specific:

    Use sources + generates (or status) to skip unnecessary work.

    line 36
  10. Very specific:

    Use preconditions for hard-fail checks (missing tools/files/env).

    line 37
  11. Very specific:

    Use if to conditionally skip tasks without failing.

    line 38
  12. Very specific:

    Use task-level dir when running in subfolders/services.

    line 39
  13. Distinctive:

    When writing or editing Taskfiles:

    line 43

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Taskfile Skill

Use this skill to create production-grade Taskfile.yml automation for local dev, CI, and monorepos.

Task is a YAML task runner with:

  • dependency graphs (deps)
  • templating via Go text/template + slim-sprig functions
  • incremental execution (sources, generates, status, method)
  • task composition via includes

What to do first

  1. Identify the user's goal (dev workflow, build, test, release, codegen, deploy).
  2. Inspect existing Taskfile.yml and project scripts (package.json, Makefile, CI configs).
  3. Decide whether to:
    • add tasks to existing Taskfile,
    • split into included Taskfiles,
    • or bootstrap a fresh Taskfile.
  4. Prefer small, composable tasks with clear desc and predictable variables.

Core implementation rules

  • Keep root schema on version: '3' unless user needs stricter semver gating.
  • Use desc on user-facing tasks so task --list is useful.
  • Use internal: true for helper tasks not meant for direct invocation.
  • Use deps for parallelizable prerequisites; use cmds: - task: ... for ordered execution.
  • Use requires.vars for mandatory inputs and enum constraints for safety.
  • Use sources + generates (or status) to skip unnecessary work.
  • Use preconditions for hard-fail checks (missing tools/files/env).
  • Use if to conditionally skip tasks without failing.
  • Use task-level dir when running in subfolders/services.

Output expectations

When writing or editing Taskfiles:

  • return valid YAML that can run as-is;
  • include concise comments only for non-obvious behavior;
  • include at least one default or clearly documented entrypoint task when useful;
  • include practical examples of calling tasks (with variables and -- CLI args) in your response.

Routing guide

  • Schema keys and valid shapes: references/schema-and-model.md
  • Templating and special variables: references/templating-and-vars.md
  • Execution model, caching, and reliability: references/execution-patterns.md
  • CLI flags, debug flow, and troubleshooting: references/cli-and-debugging.md
  • Ready-to-copy Taskfiles: examples/basic-taskfile.yml, examples/monorepo-taskfile.yml

High-value patterns to prefer

1) Safe deploy tasks

  • prompt for confirmation
  • requires.vars for environment selection
  • preconditions for required secrets/tools

2) Fast local dev loops

  • a top-level dev task that fans out to service tasks
  • watch where appropriate
  • clear task aliases for common commands

3) Incremental builds/codegen

  • sources and generates for deterministic re-runs
  • method: checksum for content-sensitive workflows
  • method: timestamp only when filesystem mtime behavior is desired

4) Monorepo composition

  • includes with namespaces
  • flatten only when naming collisions are controlled
  • excludes for clashing task names

Anti-patterns to avoid

  • Giant single tasks that hide multiple concerns.
  • Relying on shell state shared between separate commands.
  • Omitting desc on user-facing tasks.
  • Using --force routinely instead of modeling sources/status correctly.
  • Putting sensitive values directly in Taskfiles when env/dotenv is more appropriate.

Minimal quality checklist

Before finishing, verify:

  • task --list is readable and meaningful.
  • Required variables are enforced (requires).
  • Tasks run from expected directories (dir, USER_WORKING_DIR when needed).
  • Incremental tasks have correct invalidation (sources/generates/status).
  • Task names and namespaces are consistent and predictable.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.