Workflows

Workflows let you save commands, scripts, and multi-step processes and run them without rebuilding the same setup every time. Think of them as a task runner that lives next to your agents — with agent steps as a first-class citizen.

Opening the Workflows panel

Press Cmd+Shift+R (macOS) or Ctrl+Shift+R (Windows/Linux) to toggle the Workflows panel.

Where workflows come from

Discovered workflows appear automatically alongside your saved ones — click play to run any of them.

Creating a workflow

1. Open the Workflows panel
2. Click +
3. Fill in a name and command, choose a scope (shared, private, or global)
4. Save

Each saved workflow is a single YAML file:

name: Build & Test
command: npm run build && npm test
category: CI/CD

For advanced workflows, open the YAML editor and edit the full definition directly. Workflow files reload automatically when they change on disk.

Multi-step workflows

Use steps instead of command. Steps run in sequence — shell commands, agent prompts, file renders, or calls to other workflows:

name: Release
inputs:
  target:
    description: Deploy target
    type: choice
    options: [staging, production]
    default: staging
steps:
  - name: Build
    run: npm run build

  - name: Review
    agent:
      prompt: Review the diff for release blockers
      model: sonnet

  - name: Deploy
    run: ./scripts/deploy.sh ${{ inputs.target }}

Steps can pass data forward — ${{ steps.build.outputs.tag }}, ${{ steps.test.exit_code }} — and gate on conditions with if:. Failures stop the run unless a step sets on_error: continue or on_error: retry.

Inputs

Declare inputs and hob prompts for them before the run starts:

inputs:
  tag:
    description: Version tag
    type: string
  confirm:
    description: Really deploy?
    type: bool

Types are string, choice (pick from options), and bool. Mark an input secret: true for a password-style field that is scrubbed from logs and history.

Secrets

Secrets are encrypted at rest, scrubbed from workflow output and history, and never expanded in agent prompts. Manage them in the Workflows panel, then reference them:

steps:
  - name: Push
    run: ./deploy.sh
    env:
      TOKEN: "${{ secrets.DEPLOY_TOKEN }}"

Resolution order is project secret first, then global. Keep secret-bearing actions in run steps and pass only scrubbed outputs back to agents.

Scheduling

Workflows can run on a schedule with human-readable interval rules:

name: health-check
on:
  schedule:
    - every: 1d
      at: "09:00"
    - every: 2w
      weekday: tue
      at: "09:00"
steps:
  - name: Check
    run: ./scripts/health-check.sh

How scheduling behaves:

• Scheduled workflows fire only while the project is open in hob — there is no background daemon
• Missed runs are not replayed later; the schedule resumes at the next future occurrence
• If a fire would overlap a still-running copy of the same workflow, hob skips it
• With the same project open in multiple windows, exactly one window owns the scheduler — no duplicate runs

Scheduled workflows must be non-interactive: no inputs: and no pty-input: true.

Artifacts

Record files or directories alongside a run — build outputs, reports, coverage:

artifacts:
  - path: dist/
    name: build-output

Shell steps can also declare them at run time with ::set-artifact path=dist/report.html::build report.

Run history

Every run is recorded. The Workflows panel shows recent runs; multi-step runs show per-step status, duration, outputs, and artifacts. Runs appear in Activity unless you mute a workflow there.