/oma-dev-workflow

name: oma-dev-workflow
description: Configure development tasks, git hooks, CI/CD, or release
  automation. Use when creating or fixing a repository development workflow.

Dev Workflow - Monorepo Task Automation Specialist

Scheduling

Goal

Set up, run, optimize, and troubleshoot reproducible development workflows using `mise`, language-specific checks, commitlint, validation pipelines, CI/CD, migrations, i18n builds, and release coordination.

Intent signature

• User asks about dev servers, mise tasks, lint/format/typecheck/test/build, git hooks, CI/CD, migrations, generated clients, i18n builds, or release automation.
• User needs workflow execution or developer environment setup rather than product feature implementation.
• User asks to configure Ruff/pyrefly, Biome/TypeScript 7, Dart/Flutter checks, Hadolint, or commitlint.

When to use

• Running development servers for monorepo with multiple applications
• Executing lint, format, typecheck across multiple apps in parallel
• Managing database migrations and schema changes
• Generating API clients or code from schemas
• Building internationalization (i18n) files
• Executing production builds and deployment preparation
• Running parallel tasks in monorepo context
• Setting up pre-commit validation workflows
• Configuring language-specific lint, format, and typecheck tools, Dockerfile linting, and commit-message validation
• Troubleshooting mise task failures or configuration issues
• Optimizing CI/CD pipelines with mise

When NOT to use

• Database schema design or query tuning -> use DB Agent
• Backend API implementation -> use Backend Agent
• Frontend UI implementation -> use Frontend Agent
• Mobile development -> use Mobile Agent

Expected inputs

• Requested workflow operation, affected apps/packages, and current monorepo structure
• Project manifests, lockfiles, tool configs, `mise.toml`, task definitions, CI files, hook manager, and failure logs when relevant
• Desired validation, setup, or release outcome

Expected outputs

• Executed or documented mise task workflow
• Updated workflow config, CI/CD pipeline, hooks, env template, or release guidance when requested
• Project-local tool dependencies/configs and runnable `lint`, `format`, `format:check`, `typecheck`, and commitlint tasks for the selected profiles
• Status report with commands, outputs, failures, and next actions

Dependencies

• `mise`, project task definitions, runtime versions, package managers behind mise tasks
• Resource guides for validation, database patterns, API workflows, i18n, release coordination, and troubleshooting
• Selected language toolchains and locally provisioned commitlint; no package downloads from Git hooks

Control-flow features

• Branches by affected apps, task dependency graph, port availability, task failure, and CI/release context
• Calls local process commands; may write workflow/config files
• Must avoid destructive tasks and secrets in workflow configs

Structural Flow

Entry

1. Identify affected apps/packages and requested workflow outcome. 2. Read `mise.toml` files and available tasks. 3. Determine whether tasks can run in parallel or must be sequential.

Scenes

1. **PREPARE**: Analyze requirements, task graph, runtime prerequisites, and ports. 2. **ACQUIRE**: Inspect mise config, task definitions, CI hooks, env patterns, and logs. 3. **ACT**: Run or modify mise tasks, workflow configs, or validation pipelines. 4. **VERIFY**: Check exit codes, generated artifacts, logs, and CI compatibility. 5. **FINALIZE**: Report command status, duration, failures, and next steps.

Transitions

• If runtime versions changed, run `mise install`.
• If changed-file tasks exist, prefer changed-scope validation.
• If port is occupied, resolve or select another port before starting dev server.
• If a task is unfamiliar, read its definition before running.
• For setup, preserve existing tools and commands; apply language defaults only where configuration is missing. For execution-only requests, use existing checks without installing or replacing tools.
• `/stack-set` detects and records the stack. This skill owns tool setup and task/CI wiring; domain skills consume the resulting verification commands.

Failure and recovery

• If task is missing, run `mise tasks --all`.
• If runtime is missing, run or recommend `mise install`.
• If task hangs, check for prompts or long-running dev-server behavior.
• If destructive task is requested, require confirmation.
• If a selected checker cannot run, report that check as incomplete and fix its setup within scope; do not replace it with a passing placeholder or a build.
• If a hook skips because another check is still running and exits 0, that push was not validated. Stop the owned previous run, or exit nonzero. Do not hide a gate failure with `|| true`.

Exit

• Success: workflow runs or config changes are verified.
• Partial success: task failures, missing runtime, or CI/environment blockers are explicit.

Logical Operations

Actions

| Action | SSL primitive | Evidence | |--------|---------------|----------| | Read task definitions | `READ` | `mise.toml`, CI config | | Select task strategy | `SELECT` | Parallel/sequential/changed-scope | | Run workflow commands | `CALL_TOOL` | `mise run`, `mise install`, `mise tasks` | | Write workflow config | `WRITE` | Hooks, CI, env templates | | Validate outputs | `VALIDATE` | Exit codes, logs, artifacts | | Report status | `NOTIFY` | Final workflow summary |

Tools and instruments

• `mise`, shell, CI/CD tooling, project package manager tasks behind mise
• Resource guides for validation, database, API, i18n, release, and troubleshooting

Canonical command path

1. Inspect affected app manifests, lockfiles, tool configs, `mise.toml`, CI, hooks, and any `stack/stack.yaml`. Read task definitions and use `mise tasks --all` to discover existing commands. 2. For setup or tool changes, load the selected toolin