| name | dynamic-workflow-mode |
| description | Design task-local harnesses, eval gates, and reusable-skill extraction for the case where an agent can generate or adapt its own workflow instead of only following a fixed command flow. Turns "the agent invents a harness" into a disciplined system — a temporary harness for one-off work, a shared skill for repeated work, observable checkpoints for teamwork, and an eval gate plus a human merge gate before anything autonomous. Use when a task needs a custom loop, evaluator, crawler, fixture generator, or watcher, when several agents need the same repeatable process that is not yet a skill, or when a workflow needs durable handoff artifacts and operator sign-off before merge. |
| version | 1.0.0 |
| risk_class | low |
| metadata | {"domain":"agents-meta","audit_action":"dynamic_harness_designed","activation_triggers":[{"event":"help-me-invoked","regex":"(?i)dynamic.?workflow|task.?local.?harness|harness.?per.?task|adaptive.?(workflow|harness)|custom.?(loop|evaluator|harness)|reusable.?skill.?extract|eval.?gate"},{"event":"plan-opened","regex":"(?i)harness|fixture.?generator|watcher|control.?pane|status.?board|handoff.?artifact"},{"event":"spawn-requested","regex":"(?i)harness|evaluator|crawler|watcher|dynamic.?workflow"}]} |
| source | affaan-m/ecc@81af4076 skills/dynamic-workflow-mode/ |
| license | MIT |
Dynamic Workflow Mode
Premise. Sometimes the cheapest correct move is not to follow a fixed
command — it is to let the agent generate a small, task-local harness: a
throwaway loop, evaluator, or watcher scoped to one job. That power is only
safe with discipline. This skill sets the contract: build a harness only when
it is cheaper and safer than driving the steps by hand, gate it with a
task-specific eval, keep the checkpoints observable, and never skip the human
merge gate.
When to Activate
Load this skill when:
- A task would benefit from a custom loop, evaluator, crawler, fixture
generator, watcher, or local dashboard — not just a one-shot command.
- Several agents need the same repeatable process, but the process is not yet
captured as a shared skill.
- A workflow spans more than one session and needs durable handoff artifacts,
eval evidence, or operator approval before merge.
Do not load it for:
- A genuine one-shot task → keep it inline; do not invent a harness.
- Work already covered by an existing skill or slash command → use that.
- Wiring recurrence or cron → that is
/loop and /schedule (host-harness
built-ins — Claude Code ships them; they are the mechanism layer, not
framework commands under .claude/commands/);
and whether the loop's goal is right is loop-design-check.
Core contract — what every harness must declare
Generate a task-local harness only when the harness is cheaper and safer than
manually driving the same steps. When you do, it must state:
- Objective — the outcome it owns, and the outcome it explicitly does not
own.
- Inputs — files, URLs, prompts, data sources, the credentials policy, and
any user-supplied constraints.
- Outputs — commits, reports, screenshots, status files, or checkpoint
snapshots.
- Eval — at least one pass/fail check tied to the task, not merely "it ran."
- Handoff — a short artifact that tells the next operator what happened,
what is blocked, and how to resume.
Decision tree — how much harness does this deserve?
- One-shot task → keep it inline. Do not invent a harness.
- Repeated task, changing inputs → build a task-local harness under a temp
or plan-local working area (for this framework:
PLAN-NNN/ scratch or the
session scratchpad — never a canonical path).
- Repeated task across teammates or repos → extract the pattern into a
shared skill.
- Task with external state, queueing, or approvals → add observable
checkpoints before adding more automation.
- Task with a safety risk → add an eval gate and a human merge gate before
any autonomous execution.
Task-local harness template
Fill this before writing any code:
# Task-Local Harness
Objective:
- Ships:
- Does 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 the eval check.
4. Record status + handoff.
5. Stop on a failed gate, unclear ownership, or an unsafe external action.
Eval:
- Command:
- Expected pass signal:
- Failure owner:
Handoff:
- Status:
- Evidence:
- Next action:
Promote to a shared skill only when it earns it
Turn a task-local harness into a shared skill only when at least two of
these hold:
- The same workflow shows up across multiple sessions, repos, or teams.
- The workflow needs specific language, tool, or safety sequencing.
- Failures repeat because operators skip a gate or lose context.
- The workflow has a stable input/output contract.
- The workflow benefits from a shared status board or team handoff.
When extracting, write the skill first as SKILL.md; add a slash-command shim
only if a legacy entry surface is still required. In this framework a new skill
is canonical-guarded — it lands through the import gate and /skill-review, not
by direct write.
Observable checkpoints (the "control pane")
A dynamic harness becomes team-usable only when it exposes its state. Whenever a
task spans more than one session, record these checkpoints in a durable place —
in this framework, the plan file, plan-scoped memory-scratchpad, the task
board, and the HMAC audit log, rather than scattered untracked notes:
- Plan — objective, owner, acceptance criteria, risky external systems.
- Queue — work items, assigned role, branch/worktree, dependency edges.
- Run — active harness, current loop step, latest eval result, token/cost
signal if available.
- Gate — test results, screenshots, security review, merge readiness.
- Handoff — what is done, what failed, what needs a human decision.
Prefer the framework's existing state surfaces (plan lifecycle, scratchpad,
audit log) over inventing a private store; a checkpoint no teammate can read is
not a checkpoint.
Eval gates — pick the cheapest reliable one
Every dynamic harness needs a task-specific eval. Do not call a workflow
reusable until another teammate can rerun its eval.
| Work type | Eval gate |
|---|
| Code feature | focused test + lint + coverage + one integration path |
| UI / dashboard | browser smoke with a screenshot + overflow/error check |
| Agent workflow | fixture transcript or seeded work item with expected routing |
| Research / content | source-neutral brief + claim checklist + publish-ready outline |
| Integration | dry-run command + config validation + no-secret scan |
Anti-patterns
- Generating scripts that hide the real decision logic from the operator.
- Treating "dynamic workflow" as permission to skip tests.
- Producing one-off docs when a shared skill or a status artifact is the real
deliverable.
- Running multiple agents with no ownership, merge gate, or conflict policy.
- Letting raw private data leak into public docs or committed artifacts.
Output standard
Close every dynamic-workflow task with:
- The harness or skill path.
- The eval command(s) and their result.
- The checkpoint / handoff artifact path.
- The next reusable-extraction candidate, if any.
Changelog
- 1.0.0 — Initial house-format authoring. Task-local-harness discipline:
core contract (objective/inputs/outputs/eval/handoff), 5-branch decision tree,
harness template, shared-skill promotion rule, observable checkpoints mapped
to framework state surfaces (plan lifecycle,
memory-scratchpad, task board,
audit log), per-work-type eval-gate table, anti-patterns, output standard.
Skill-Import-Attestation: reviewed-by=AE9B236FDAF0462874060C6BCFCFACF00335DC74; sha256=9fa5a68074d56dc144798500e74ac1f1deaa21cfd4d60142cd9c6ff7600ef915
