How to Dry-Run a design-control-loop Workflow With No Prior Run History

The design-control-loop skill recommends adding a temporary push trigger to your workflow YAML, executing the run on your branch, and then immediately removing the trigger to restore workflow_dispatch-only mode.

The design-control-loop skill in the humanlayer/skills repository provides a structured approach for implementing control loops in GitHub Actions. When you create a new workflow that relies on workflow_dispatch triggers, you face a catch-22: GitHub does not permit manual dispatch until the workflow has executed at least once. The skill solves this through a specific Phase H validation protocol that enables safe testing without polluting your CI configuration.

Why Workflows Require a First Run Before Manual Dispatch

GitHub Actions restricts manual workflow dispatch to files that exist on the default branch and have recorded at least one execution. When you bootstrap a new design-control-loop workflow from plugins/design-control-loop/skills/design-control-loop/references/workflow-template.yml, the file may be valid YAML but remains undispatchable until it has historical run data. This creates a deployment barrier for fresh implementations that need validation before merging to main.

The Phase H Dry-Run Strategy

The skill documentation in plugins/design-control-loop/skills/design-control-loop/SKILL.md (lines 151-155) defines Phase H as the validation and iteration phase. Within this phase, the skill prescribes a four-step procedure for dry-running a workflow with no prior run history without leaving permanent trigger artifacts.

Step 1: Add a Transient Push Trigger

Edit your workflow file to include a temporary push event limited strictly to your current feature branch. This modification belongs in the on: block alongside the permanent workflow_dispatch trigger.

# .github/workflows/design-loop.yml

on:
  workflow_dispatch: {}    # Permanent manual trigger

  # --- Temporary injection for dry-run ---

  push:
    branches:
      - my-feature-branch  # Isolate to current branch only

Add this block only to the branch you are testing. Never commit this change to main or other long-lived branches.

Step 2: Execute the Workflow

Commit the temporary trigger and push to trigger the workflow automatically:

git add .github/workflows/design-loop.yml
git commit -m "Add temporary push trigger for dry-run"
git push origin my-feature-branch

Navigate to the Actions tab in your repository to observe the execution. Verify that the workflow correctly processes the sensor, controller, and actuator steps as defined in your design-control-loop implementation.

Step 3: Remove the Trigger Immediately

Once the run succeeds and you have confirmed the behavior, revert the temporary trigger to restore the intended workflow_dispatch-only configuration:

git revert HEAD          # Removes the temporary push block

git push origin my-feature-branch

Alternatively, manually edit the file to delete the push: block and commit the change. The repository now contains a validated workflow with clean history, ready for merge without lingering event listeners.

Code Implementation Reference

The following example demonstrates the complete lifecycle of the temporary trigger technique as implemented in the skill template:

# File: plugins/design-control-loop/skills/design-control-loop/references/workflow-template.yml

# Excerpt showing trigger configuration

name: Design Control Loop

on:
  workflow_dispatch:
    inputs:
      dry_run:
        description: 'Execute without side effects'
        default: false
  # Temporary addition for first-run validation:

  # push:

  #   branches: [ 'feature/initial-test' ]

When executing the dry-run, monitor the workflow logs to ensure the control loop correctly identifies state transitions before you remove the push trigger.

Summary

• design-control-loop uses Phase H specifically for validating and iterating on workflow logic before production deployment.
• Temporary push triggers bypass the GitHub Actions requirement for prior run history without modifying the default branch.
• Branch-scoped events ensure the trigger fires only on your feature branch, preventing unintended executions on other contributors' work.
• Immediate cleanup after successful validation maintains repository hygiene and adheres to the principle of minimal CI surface area.

Frequently Asked Questions

Why can't I use workflow_dispatch on a new workflow file?

GitHub Actions requires at least one successful execution record before enabling the manual dispatch interface. This security measure prevents execution of unvalidated code, but it creates a bootstrap problem for fresh workflows. The temporary push trigger technique documented in SKILL.md provides the initial execution required to activate workflow_dispatch functionality.

What happens if I forget to remove the temporary push trigger?

Leaving the push trigger in place causes the workflow to execute on every commit to that branch, which violates the design-control-loop's event-driven architecture intended for workflow_dispatch. This can generate noise in your Actions logs and potentially trigger unintended side effects if the workflow contains state-modifying actuators.

Can I use this technique for workflows other than design-control-loop?

Yes. While the pattern is explicitly documented in plugins/design-control-loop/skills/design-control-loop/SKILL.md, the temporary push trigger method applies to any GitHub Actions workflow that requires workflow_dispatch validation before the first official run. The key constraint remains isolating the trigger to a specific branch and removing it immediately after verification.

How do I validate the workflow behavior during the dry-run?

During the temporary push execution, verify that the workflow completes all three design-control-loop phases: sensor data collection, controller decision logic, and actuator execution (or dry-run simulation). Check that environment variables, secrets injection, and conditional logic perform as expected before you revert the trigger commit.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}