Design task-specific workflows for repeated agent work, with pass/fail checks, progress records, and handoff notes. Identify when a temporary workflow should become a shared skill that teammates can run and evaluate again.
Design task-local harnesses, eval gates, and reusable skill extraction for Claude dynamic workflow mode and other adaptive agent harnesses. Use when building a task-local harness, adding eval gates, or extracting a reusable skill from ad-hoc work.
This skill helps design a task-specific harness, a structure that supports execution, for recurring agent work. It organizes the objective, inputs, deliverables, pass/fail checks, and handoff information. It then defines the flow from checking current state through updating deliverables, validating results, and recording progress. It also helps decide when procedures used across teams or projects should be captured in a shared SKILL.md.
Use it when the same task repeats with different inputs or several agents need to follow a consistent process. For work spanning sessions, it records the plan, ownership, execution status, validation results, and unresolved issues so the next person or agent has the information needed to resume.
One-off tasks are handled directly without building a dedicated mechanism. Work with safety risks requires evaluation-based stop conditions and human approval before merging. A procedure can be treated as a shared skill only when another operator can rerun its validation.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Use this skill when a coding agent can generate or adapt a task-local harness instead of only following a static command flow. The goal is to turn dynamic workflow mode into a disciplined system: temporary harnesses for one-off work, shared skill extraction for repeated work, and observable control pane checkpoints for teams.
Dynamic workflow mode should produce a task-local harness only when the harness is cheaper and safer than manually driving the same steps. The harness must have:
Use this structure before writing code:
# Dynamic Workflow Harness
Objective:
- Ship:
- Do not ship:
Inputs:
- Repo or workspace:
- External systems:
- Credentials policy:
Loop:
1. Discover current state.
2. Generate or update the smallest useful artifact.
3. Run eval checks.
4. Record status and handoff.
5. Stop on failed gate, unclear ownership, or unsafe external action.
Eval:
- Command:
- Expected pass signal:
- Failure owner:
Handoff:
- Status:
- Evidence:
- Next action:
Promote a task-local harness into a shared skill only when at least two of these are true:
When extracting, write the skill first in skills/<name>/SKILL.md. Add command shims only if a legacy slash-entry surface is still required.
Dynamic workflow mode becomes team-usable when it exposes state. Record these checkpoints whenever the task spans more than one session:
If the repo has ECC2 state enabled, prefer adding or reading checkpoints through the ECC control pane or state-store-backed scripts instead of scattering untracked notes.
Every dynamic harness needs a task-specific eval. Pick the cheapest reliable gate:
| Work Type | Eval Gate |
|---|---|
| Code feature | Focused test, lint, coverage, and one integration path |
| UI/control pane | Browser smoke with screenshot and overflow/error checks |
| Agent workflow | Fixture transcript or seeded work item with expected routing |
| Research/content | Source-neutral brief, claim checklist, and publish-ready outline |
| Integration | Dry-run command, config validation, and no-secret scan |
Do not claim a dynamic workflow is reusable until the eval can be rerun by another teammate.
Finish with:
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.
Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.
Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.
Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.
Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.
Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.