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

taskfile

Skill4 starsChanged 44 days agoMITView on GitHub

Expert guidance for Taskfile (taskfile.dev) — the YAML task runner. Use when creating, editing, debugging, or optimizing a Taskfile.yml, or when the user asks about tasks, task dependencies, variables, includes, file watching, or migrating from Make.

  • Reads credentials
  • Deletes or force-pushes
  • Installs packages

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. sunsided/taskfile-skills★ 3same name
    2. aaronflorey/agent-skills★ 2same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 4 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always use version 3 (current stable):

    line 19
  2. Distinctive:

    Run tasks only when files change:

    line 123
  3. Very specific:

    Always specify version: - Use version: '3' at the top

    line 395
  4. Very specific:

    Add descriptions: - Use desc: for all tasks to make task --list useful

    line 396
  5. Distinctive:

    Leverage sources/generates: - Avoid unnecessary rebuilds

    line 398
  6. Very specific:

    Group related tasks: - Use colon notation (e.g., docker:build, docker:push)

    line 399
  7. Very specific:

    Set a default task: - Create a default task for common workflow

    line 400
  8. Very specific:

    Document complex tasks: - Use summary: for detailed explanations

    line 401
  9. Very specific:

    Silent by default: - Use silent: true for cleaner output when appropriate

    line 404
  10. Distinctive:

    Task not found: Check task name spelling and ensure you're in the correct directory

    line 410
  11. Very specific:

    Variables not expanding: Ensure proper {{.VAR}} syntax with dots

    line 411
  12. Very specific:

    Dependencies not running: Check task names in deps: array

    line 412
  13. Very specific:

    File watching not working: Ensure sources: paths are correct and watch: true is set

    line 413

≈ “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 Expert

You are an expert in Taskfile (taskfile.dev), a modern task runner and build tool. Help users create, modify, and optimize Taskfiles for their projects.

Core Principles

  1. Taskfile is a YAML-based task runner - Similar to Makefile but designed for modern workflows
  2. Cross-platform by design - Works consistently across Windows, macOS, and Linux
  3. Declarative syntax - Clear, readable task definitions with minimal boilerplate
  4. Built-in features - Variables, dependencies, file watching, and more without external plugins

Basic Taskfile Structure

Always use version 3 (current stable):

version: '3'

vars:
  # Global variables accessible to all tasks
  PROJECT_NAME: myapp
  BUILD_DIR: ./build

tasks:
  default:
    desc: Default task (runs when you type 'task' without arguments)
    cmds:
      - echo "Hello from Taskfile!"

  task-name:
    desc: Brief description of what this task does
    cmds:
      - command1
      - command2

Key Features and Syntax

Task Definition

tasks:
  build:
    desc: Build the application
    summary: |
      Extended description that appears in help.
      Can span multiple lines.
    cmds:
      - go build -o {{.BUILD_DIR}}/app
    silent: false  # Set to true to suppress command echoing

Variables

Variables can be defined at multiple levels with precedence order (highest to lowest):

  1. Task-level variables
  2. Command-line variables (task VAR=value)
  3. Environment variables
  4. Taskfile-level variables
version: '3'

vars:
  # Static variables
  GREETING: Hello, World!

  # Dynamic variables (command output)
  GIT_COMMIT:
    sh: git rev-parse --short HEAD

  # Variables with defaults
  ENV: {sh: echo ${ENVIRONMENT:-development}}

tasks:
  greet:
    vars:
      # Task-specific variable
      NAME: Developer
    cmds:
      - echo "{{.GREETING}}, {{.NAME}}"
      - echo "Commit: {{.GIT_COMMIT}}"

Dependencies

tasks:
  # Dependencies run in parallel by default
  build:
    deps: [install, lint, test]
    cmds:
      - go build

  # Force sequential execution
  deploy:
    deps:
      - task: build
      - task: push
    cmds:
      - kubectl apply -f deployment.yaml

  install:
    cmds:
      - go mod download

  lint:
    cmds:
      - golangci-lint run

  test:
    cmds:
      - go test ./...

Sources and Status (Smart Task Execution)

Run tasks only when files change:

tasks:
  build:
    desc: Build only if source files changed
    sources:
      - src/**/*.go
      - go.mod
      - go.sum
    generates:
      - bin/app
    cmds:
      - go build -o bin/app

  # Alternative: use status for custom checks
  compile-assets:
    status:
      - test -f dist/bundle.js
      - test dist/bundle.js -nt src/index.js
    cmds:
      - npm run build

Environment Variables

version: '3'

env:
  # Global environment variables
  GO111MODULE: on
  CGO_ENABLED: "0"

dotenv:
  - .env          # Load from .env file
  - .env.local    # Override with local settings

tasks:
  test:
    env:
      # Task-specific environment
      TEST_DATABASE: postgres://localhost/test_db
    cmds:
      - go test ./...

Platform-Specific Commands

tasks:
  build:
    cmds:
      - echo "Building for {{OS}}/{{ARCH}}"

  install:
    platforms: [linux, darwin]  # Only run on Linux/macOS
    cmds:
      - brew install tool

  install-windows:
    platforms: [windows]
    cmds:
      - choco install tool

Preconditions

tasks:
  deploy:
    preconditions:
      - sh: git diff-index --quiet HEAD
        msg: "Working directory must be clean"
      - test -f .env.production
      - sh: kubectl cluster-info
        msg: "Cannot connect to cluster"
    cmds:
      - kubectl apply -f k8s/

Including Other Taskfiles

version: '3'

includes:
  docker: ./docker/Taskfile.yml
  k8s:
    taskfile: ./kubernetes/Taskfile.yml
    dir: ./kubernetes  # Run tasks in this directory

tasks:
  all:
    deps:
      - docker:build
      - k8s:deploy

Interactive Commands

tasks:
  shell:
    interactive: true
    cmds:
      - docker exec -it mycontainer /bin/bash

Looping

tasks:
  test-all:
    vars:
      MODULES:
        sh: ls -d */
    cmds:
      - for: { var: MODULES }
        cmd: go test ./{{.ITEM}}

  # Or with static list
  lint-files:
    vars:
      FILES: [main.go, utils.go, config.go]
    cmds:
      - for: { var: FILES }
        cmd: golangci-lint run {{.ITEM}}

File Watching

tasks:
  dev:
    desc: Watch for changes and rebuild
    watch: true
    sources:
      - "**/*.go"
    cmds:
      - go build
      - ./app

Common Patterns

Multi-Stage Build Process

version: '3'

vars:
  APP_NAME: myapp
  BUILD_DIR: ./dist

tasks:
  default:
    deps: [build]

  clean:
    desc: Remove build artifacts
    cmds:
      - rm -rf {{.BUILD_DIR}}

  deps:
    desc: Install dependencies
    sources:
      - go.mod
      - go.sum
    cmds:
      - go mod download
    generates:
      - go.sum

  lint:
    desc: Run linters
    deps: [deps]
    cmds:
      - golangci-lint run

  test:
    desc: Run tests
    deps: [deps]
    cmds:
      - go test -v ./...

  build:
    desc: Build application
    deps: [deps, lint, test]
    sources:
      - "**/*.go"
      - go.mod
      - go.sum
    generates:
      - "{{.BUILD_DIR}}/{{.APP_NAME}}"
    cmds:
      - mkdir -p {{.BUILD_DIR}}
      - go build -o {{.BUILD_DIR}}/{{.APP_NAME}}

Docker Workflow

version: '3'

vars:
  IMAGE_NAME: myapp
  TAG:
    sh: git rev-parse --short HEAD

tasks:
  docker:build:
    desc: Build Docker image
    cmds:
      - docker build -t {{.IMAGE_NAME}}:{{.TAG}} .
      - docker tag {{.IMAGE_NAME}}:{{.TAG}} {{.IMAGE_NAME}}:latest

  docker:push:
    desc: Push image to registry
    deps: [docker:build]
    cmds:
      - docker push {{.IMAGE_NAME}}:{{.TAG}}
      - docker push {{.IMAGE_NAME}}:latest

  docker:run:
    desc: Run container locally
    deps: [docker:build]
    cmds:
      - docker run -p 8080:8080 {{.IMAGE_NAME}}:latest

Monorepo Management

version: '3'

includes:
  frontend:
    taskfile: ./apps/frontend/Taskfile.yml
    dir: ./apps/frontend
  backend:
    taskfile: ./apps/backend/Taskfile.yml
    dir: ./apps/backend
  shared:
    taskfile: ./packages/shared/Taskfile.yml
    dir: ./packages/shared

tasks:
  install:
    desc: Install all dependencies
    cmds:
      - task: frontend:install
      - task: backend:install
      - task: shared:install

  build:
    desc: Build all packages
    cmds:
      - task: shared:build
      - task: frontend:build
      - task: backend:build

  test:
    desc: Run all tests
    cmds:
      - task: shared:test
      - task: frontend:test
      - task: backend:test

Best Practices

  1. Always specify version - Use version: '3' at the top
  2. Add descriptions - Use desc: for all tasks to make task --list useful
  3. Use variables for flexibility - Define paths, names, and values as variables
  4. Leverage sources/generates - Avoid unnecessary rebuilds
  5. Group related tasks - Use colon notation (e.g., docker:build, docker:push)
  6. Set a default task - Create a default task for common workflow
  7. Document complex tasks - Use summary: for detailed explanations
  8. Use includes for organization - Break large Taskfiles into smaller, focused ones
  9. Add preconditions - Validate environment before running tasks
  10. Silent by default - Use silent: true for cleaner output when appropriate

Troubleshooting

Common Issues

  • Task not found: Check task name spelling and ensure you're in the correct directory
  • Variables not expanding: Ensure proper {{.VAR}} syntax with dots
  • Dependencies not running: Check task names in deps: array
  • File watching not working: Ensure sources: paths are correct and watch: true is set

Command Reference

# List all available tasks
task --list
task -l

# Run a task
task build

# Run multiple tasks
task clean build test

# Pass variables to tasks
task build VERSION=1.0.0

# Run task from specific Taskfile
task --taskfile ./path/to/Taskfile.yml build

# Watch for changes
task --watch dev

# Run task with increased verbosity
task --verbose build

# Show summary of a task
task --summary build

When to Use Taskfile

Good Use Cases:

  • Build automation and compilation
  • Development workflows (lint, test, build)
  • Docker and container management
  • Deployment orchestration
  • Database migrations
  • Asset compilation
  • CI/CD task definitions

Consider Alternatives When:

  • You need programming language features (use a build tool native to your language)
  • Complex conditional logic is required (consider a shell script or proper build system)
  • You're working in a team that's heavily invested in another tool (e.g., Make, Just, etc.)

Additional Resources

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.