workflow-automation

어떤 스킬인가요?

Automate repetitive development tasks and workflows. Use when creating build scripts, automating deployments, or setting up development workflows. Handles npm scripts, Makefile, GitHub Actions workflows, and task automation.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

{
  "skill_name": "workflow-automation",
  "evals": [
    {
      "id": 1,
      "prompt": "Our repo keeps relying on copied shell commands for setup, lint, test, and build. I want one repeatable workflow surface without turning this into platform engineering.",
      "expected_output": "A repo-scoped automation plan that inventories existing commands, chooses one light command surface, and avoids drifting into deployment or infrastructure advice.",
      "assertions": [
        "Response explicitly inventories or asks for the existing repo command surface before recommending a new wrapper",
        "Response names at least three top-level repo commands from the set `setup`, `build`, `test`, `lint`, `check`, `release-prep`",
        "Response avoids recommending deployment, Kubernetes, Terraform, or environment provisioning as the default solution"
      ]
    },
    {
      "id": 2,
      "prompt": "Should this mixed Node and Python repository use npm scripts, make, just, or Taskfile for local automation?",
      "expected_output": "A choice-oriented answer that compares the task runner options against the repo shape and recommends the lightest viable surface rather than a one-size-fits-all default.",
      "assertions": [
        "Response compares at least two of `npm scripts`, `make`, `just`, or `Taskfile` instead of naming only one tool",
        "Response mentions at least one repo-shape factor such as language mix, portability, existing commands, or team conventions",
        "Response includes an explicit condition for keeping the existing command surface instead of adding a new runner"
      ]
    },
    {
      "id": 3,
      "prompt": "Add pre-commit checks and a local CI-parity command, but keep expensive tests and publish steps out of default local automation.",
      "expected_output": "Guidance that separates fast hooks from heavier CI-only checks, keeps release or publish commands explicit, and names a local parity command.",
      "assertions": [
        "Response explicitly separates fast hook candidates from heavier CI-only checks such as integration, browser, or end-to-end suites",
        "Response states that publish, deploy, migration, or destructive flows must stay opt-in rather than default hook behavior",
        "Response names a local parity command such as `check` or clearly labels an equivalent top-level quality lane"
      ]
    }
  ]
}

# Local CI Parity and Hooks

Use this reference when the user needs repeatable quality checks, local guardrails,
or lightweight maintenance automation.

## Local parity pattern

Aim for one local command that mirrors the repo's main CI quality lane:

```text
check -> lint -> test -> typecheck -> build
```

Adjust the sequence to match the repo, but keep the mapping explicit.

## What belongs local vs CI

| Surface | Good local candidate | Keep in CI by default |
|---|---|---|
| Formatting / lint | Yes | Also in CI if the repo enforces it |
| Unit tests | Yes | Yes |
| Type checks / static analysis | Yes | Yes |
| Long integration tests | Sometimes | Usually yes |
| E2E / browser suites | Rarely | Usually yes |
| Publish / deploy | No | Explicit release path only |

## Hook policy

Use hooks for fast, deterministic checks:

- formatting or lint on changed files
- lightweight tests when they finish quickly
- generated-file consistency if the command is stable and cheap

Avoid heavy or risky defaults:

- full integration suites in pre-commit
- cleanup commands that delete caches or build output implicitly
- publish, deploy, or migration commands
- commands that depend on secrets, VPN access, or production credentials

## Maintenance routines

Good candidates for explicit automation:

- dependency update dry-runs
- stale artifact cleanup
- local docs or schema generation
- release-prep summaries

Keep them named and opt-in, for example:

```text
deps-check
clean-artifacts
generate-schema
release-prep
```

## GitHub Actions parity note

If the repo uses GitHub Actions, keep the local automation aligned with the main
workflow checks instead of inventing a different quality lane. GitHub's reusable
workflow guidance is a good fit when multiple repos need the same CI contract:
https://docs.github.com/en/actions/reference/workflows-and-actions/reusable-workflows

# Task Runner Selection

Use this reference only when the user needs to choose or justify a repo-level
command surface.

## Selection order

Pick the lightest surface that can express the repeated workflow cleanly:

1. Existing package-manager scripts
2. `just` or `Taskfile`
3. Existing `make`
4. Small helper scripts under `scripts/`

Do not add a new runner just because it is fashionable.

## Quick comparison

| Option | Best fit | Strengths | Watch-outs |
|---|---|---|---|
| `npm` / package scripts | Single-language JS/TS repos | Already present, low setup, easy for contributors | Gets noisy in polyglot repos or long multi-step flows |
| `make` | Existing POSIX-heavy repos | Common on Unix, good for simple command aliases | Rough Windows story, build-system semantics can confuse command-runner use |
| `just` | Human-friendly command runner for many repos | Clear recipe syntax, strong ergonomics, good for mixed workflows | New dependency if the team does not already use it |
| `Taskfile` | Cross-platform command orchestration | Good Windows/Linux/macOS support, explicit task metadata | More structure than small repos need |
| `scripts/` wrappers | Complex reusable logic | Best place for non-trivial shell or language-specific orchestration | Can become a junk drawer if basic tasks are moved there too early |

## Decision rules

- Stay with package scripts when the repo is mostly one ecosystem and the
  command set is small.
- Prefer `just` or `Taskfile` when workflows are multi-step, mixed-language, or
  need better readability than nested package scripts.
- Keep `make` when the team already uses it successfully and portability beyond
  POSIX shells is not a priority.
- Move logic into `scripts/` only when the task runner line becomes unreadable
  or the workflow needs branching, loops, or reusable functions.

## Avoidable mistakes

- Adding both `make` and `just` for the same top-level commands
- Wrapping every package script with another identical task-runner alias
- Hiding destructive cleanup or publish commands behind innocent names
- Choosing a runner before listing the actual repeated jobs

## Pointers

- `just` positions itself as a command runner rather than a build system:
  https://github.com/casey/just
- `Task` emphasizes cross-platform Taskfiles:
  https://taskfile.dev/
- npm documents `package.json` scripts as the built-in command surface:
  https://docs.npmjs.com/cli/v11/configuring-npm/package-json

---
name: workflow-automation
description: Automate repetitive development tasks and workflows. Use when creating build scripts, automating deployments, or setting up development workflows. Handles npm scripts, Makefile, GitHub Actions workflows, and task automation.
allowed-tools: Bash Read Write Edit Grep Glob
metadata:
  tags: automation, scripts, workflow, npm-scripts, Makefile, task-runner
  platforms: Claude, ChatGPT, Gemini
---


# Workflow Automation


## When to use this skill

- **Repetitive tasks**: running the same commands every time
- **Complex builds**: multi-step build processes
- **Team onboarding**: a consistent development environment

## Instructions

### Step 1: npm scripts

**package.json**:
```json
{
  "scripts": {
    "dev": "nodemon src/index.ts",
    "build": "tsc && vite build",
    "test": "jest --coverage",
    "test:watch": "jest --watch",
    "lint": "eslint src --ext .ts,.tsx",
    "lint:fix": "eslint src --ext .ts,.tsx --fix",
    "format": "prettier --write \"src/**/*.{ts,tsx,json}\"",
    "type-check": "tsc --noEmit",
    "pre-commit": "lint-staged",
    "prepare": "husky install",
    "clean": "rm -rf dist node_modules",
    "reset": "npm run clean && npm install",
    "docker:build": "docker build -t myapp .",
    "docker:run": "docker run -p 3000:3000 myapp"
  }
}
```

### Step 2: Makefile

**Makefile**:
```makefile
.PHONY: help install dev build test clean docker

.DEFAULT_GOAL := help

help: ## Show this help
	@grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'

install: ## Install dependencies
	npm install

dev: ## Start development server
	npm run dev

build: ## Build for production
	npm run build

test: ## Run all tests
	npm test

lint: ## Run linter
	npm run lint

lint-fix: ## Fix linting issues
	npm run lint:fix

clean: ## Clean build artifacts
	rm -rf dist coverage

docker-build: ## Build Docker image
	docker build -t myapp:latest .

docker-run: ## Run Docker container
	docker run -d -p 3000:3000 --name myapp myapp:latest

deploy: build ## Deploy to production
	@echo "Deploying to production..."
	./scripts/deploy.sh production

ci: lint test build ## Run CI pipeline locally
	@echo "✅ CI pipeline passed!"
```

**Usage**:
```bash
make help        # Show all commands
make dev         # Start development
make ci          # Run full CI locally
```

### Step 3: Husky + lint-staged (Git Hooks)

**package.json**:
```json
{
  "lint-staged": {
    "*.{ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md}": [
      "prettier --write"
    ]
  }
}
```

**.husky/pre-commit**:
```bash
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

echo "Running pre-commit checks..."

# Lint staged files
npx lint-staged

# Type check
npm run type-check

# Run tests related to changed files
npm test -- --onlyChanged

echo "✅ Pre-commit checks passed!"
```

### Step 4: Task Runner scripts

**scripts/dev-setup.sh**:
```bash
#!/bin/bash
set -e

echo "🚀 Setting up development environment..."

# Check prerequisites
if ! command -v node &> /dev/null; then
    echo "❌ Node.js is not installed"
    exit 1
fi

if ! command -v docker &> /dev/null; then
    echo "❌ Docker is not installed"
    exit 1
fi

# Install dependencies
echo "📦 Installing dependencies..."
npm install

# Copy environment file
if [ ! -f .env ]; then
    echo "📄 Creating .env file..."
    cp .env.example .env
    echo "⚠️ Please update .env with your configuration"
fi

# Start Docker services
echo "🐳 Starting Docker services..."
docker-compose up -d

# Wait for database
echo "⏳ Waiting for database..."
./scripts/wait-for-it.sh localhost:5432 --timeout=30

# Run migrations
echo "🗄️ Running database migrations..."
npm run migrate

# Seed data (optional)
read -p "Seed database with sample data? (y/n) " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    npm run seed
fi

echo "✅ Development environment ready!"
echo "Run 'make dev' to start the development server"
```

**scripts/deploy.sh**:
```bash
#!/bin/bash
set -e

ENV=$1

if [ -z "$ENV" ]; then
    echo "Usage: ./deploy.sh [staging|production]"
    exit 1
fi

echo "🚀 Deploying to $ENV..."

# Build
echo "📦 Building application..."
npm run build

# Run tests
echo "🧪 Running tests..."
npm test

# Deploy based on environment
if [ "$ENV" == "production" ]; then
    echo "🌍 Deploying to production..."
    # Production deployment logic
    ssh production "cd /app && git pull && npm install && npm run build && pm2 restart all"
elif [ "$ENV" == "staging" ]; then
    echo "🧪 Deploying to staging..."
    # Staging deployment logic
    ssh staging "cd /app && git pull && npm install && npm run build && pm2 restart all"
fi

echo "✅ Deployment to $ENV completed!"
```

### Step 5: GitHub Actions workflow automation

**.github/workflows/ci.yml**:
```yaml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Type check
        run: npm run type-check

      - name: Run tests
        run: npm test -- --coverage

      - name: Upload coverage
        uses: codecov/codecov-action@v3
```

## Output format

```
project/
├── scripts/
│   ├── dev-setup.sh
│   ├── deploy.sh
│   ├── test.sh
│   └── cleanup.sh
├── Makefile
├── package.json
└── .husky/
    ├── pre-commit
    └── pre-push
```

## Constraints

### Required rules (MUST)

1. **Idempotency**: safe to run scripts multiple times
2. **Error handling**: clear messages on failure
3. **Documentation**: comments on how to use the scripts

### Prohibited items (MUST NOT)

1. **Hardcoded secrets**: do not include passwords or API keys in scripts
2. **Destructive commands**: do not run rm -rf without confirmation

## Best practices

1. **Use Make**: platform-agnostic interface
2. **Git Hooks**: automated quality checks
3. **CI/CD**: automated with GitHub Actions

## References

- [npm scripts](https://docs.npmjs.com/cli/v9/using-npm/scripts)
- [Make Tutorial](https://makefiletutorial.com/)
- [Husky](https://typicode.github.io/husky/)

## Metadata

### Version
-- **Current version**: 1.0.0
-- **Last updated**: 2025-01-01
-- **Compatible platforms**: Claude, ChatGPT, Gemini

### Tags
`#automation` `#scripts` `#workflow` `#npm-scripts` `#Makefile` `#utilities`

## Examples

### Example 1: Basic usage
<!-- Add example content here -->

### Example 2: Advanced usage
<!-- Add advanced example content here -->

N:workflow-automation
D:Repo-scoped recurring workflow automation for setup build test lint release-prep and repo hygiene. Choose the lightest command surface, keep local-CI parity explicit, and add hooks or maintenance routines without drifting into deployment or environment provisioning.
G:workflow-automation task-runner makefile just taskfile npm-scripts local-ci-parity pre-commit hooks repo-automation bootstrap

U[5]:
  Replace copied shell rituals with one repeatable repo command surface
  Choose between package scripts make just or Taskfile for an existing repository
  Add setup build test lint check or release-prep entrypoints without extra platform sprawl
  Mirror the main CI quality lane locally without hiding slow or destructive tasks in default hooks
  Add lightweight maintenance routines or fast local guardrails while keeping deployment and machine setup in sibling skills

S[5]{n,action,details}:
  1,Triage,Name the repeated jobs existing command surface team shape portability needs and risky side effects before picking a tool
  2,Choose-Surface,Prefer existing package scripts then just or Taskfile then existing make then small scripts only when the workflow logic no longer fits cleanly inline
  3,Keep-Parity,Expose a small top-level command set such as setup build test lint check and map check to the main local-CI parity lane
  4,Constrain-Hooks,Keep hooks fast and deterministic; leave heavy integration browser publish deploy and destructive flows explicit or CI-only
  5,Load-References,Read references/task-runner-selection.md for runner choice and references/local-ci-parity-and-hooks.md for quality-lane and guardrail policy when needed

R[5]:
  Keep workflow-automation repo-scoped and route deployment work to deployment-automation
  Route Docker devcontainer and machine bootstrap work to system-environment-setup
  Route .env precedence and config questions to environment-setup
  Do not add a new task runner when the existing command surface already fits
  Keep destructive or credentialed commands visibly opt-in rather than default hook behavior

E[3]{desc,in,out}:
  "Replace tribal shell history","Everyone copies setup lint test and build commands from Slack. I want one repeatable repo entrypoint without overengineering it.","Inventories the current commands, chooses one light surface, and proposes a small setup/build/test/lint/check command set"
  "Choose a runner","Should this mixed Node and Python repo use npm scripts make just or Taskfile for local automation?","Compares multiple runner options against repo shape and recommends the lightest viable surface"
  "Add local guardrails","Add pre-commit checks and a local CI-parity command, but keep expensive tests and publish steps out of default automation.","Separates fast hooks from CI-only checks and keeps publish or destructive flows opt-in"