Workflow readiness
Skill finnfotschki/mindful-agent-collaboration/skills/workflow-readiness
Installable skills, gates, hooks and templates for deliberate human-agent work — drops into your existing Claude Code or Codex setup.
npx -y skills add finnfotschki/mindful-agent-collaboration --skill workflow-readinessAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Screen a recurring workflow before task profiling or automation by checking task-fit, task-specific agent reliability, effective human intervention points, and system resilience. Use before creating recurring agent runs, expanding a pilot, granting end-to-end workflow ownership, or deciding whether an automation initiative is mature enough to profile. Return ready for task profiling, pilot/assistive only, or not ready; unknown reliability or resilience never supports autonomous delegation.
SKILL.md
5.2 KB, 987 tokens by cl100k_base, as published. Nobody here has run it
Workflow Readiness
Overview
Run the first stage of the collaboration framework before assigning delegation modes. Determine whether a recurring workflow has enough evidence and control infrastructure to justify detailed task profiling; do not treat this screen as permission to automate.
When to use
- Before a recurring, long-running, background, or end-to-end agent workflow.
- Before promoting a prototype or pilot to routine use or broader scope.
- When someone asks whether an agent is "ready to take over" a workflow.
When NOT to use: a one-off read-only request; a trivial local task; or
mode assignment for a workflow whose readiness was already confirmed against
current evidence. Use task-profile for the second-stage, per-step analysis.
Process
- Bound the candidate. Name the workflow, users, frequency, inputs, outputs, systems touched, and the point at which an output becomes effective. Split off obviously distinct or judgment-heavy segments rather than averaging them into one score.
- Check task-fit. Identify candidate segments that are sufficiently structured and have a criterion named before seeing the output. Mark where problem framing, criteria, or their weighting must first be set by a human.
- Check agent reliability. Require task- and context-specific evidence from representative cases, including relevant failure modes. General model reputation, confidence, fluency, and success on another task are not evidence.
- Check intervention design. Locate checkpoints before consequence. Confirm that the authorized human can see the needed evidence, apply a real criterion where one exists or exercise the human-owned judgment where it does not, revise or stop the run, and has enough time and competence to intervene.
- Check system resilience. Verify constraint and state retention across the
workflow horizon, error containment, checkpoint/restart behavior, audit logs,
and recovery or rollback proportional to the exposure. Name the evidence.
Treat this as an initiative-level screen;
task-profilereapplies the architecture gate to each concrete implementation step. - Rate each prerequisite
supported,conditional,unsupported, orunknowninassets/workflow-readiness.md. Never convert missing evidence into a positive rating. - Issue one outcome using the rules below, record the gaps and evidence plan, and ask the human to confirm the screen before any recurring setup.
Outcome rules
ready for task profiling— all four prerequisites aresupportedfor the bounded candidate. Continue withtask-profile; no action is authorized.pilot/assistive only— no fatal barrier is known, but at least one prerequisite isconditionalorunknown, task-fit is unsupported for autonomy but bounded non-effecting assistance remains viable, or only such assistance is justified. Keep work reversible and bounded; use a pilot to gather missing reliability or resilience evidence. Unknown reliability or resilience explicitly rules outautonomousdelegation.not ready— no useful segment can be bounded into verifiable work or safely governed non-effecting assistance, no effective intervention point exists before consequence, the architecture cannot contain/recover from plausible failures, or an applicable constraint forbids the candidate design. Redesign or narrow it before profiling.
These outcomes are readiness verdicts, not delegation modes. Do not substitute
pilot/assistive only for the assistive mode without a task profile.
Rationalizations
| Excuse | Rebuttal |
|---|---|
| "The model is generally excellent." | Reliability must be demonstrated for this task, context, and failure exposure. |
| "We can add a reviewer later." | An intervention point is a design prerequisite, not a post-launch promise. |
| "Unknown means probably fine." | Unknown means evidence is absent; it cannot support autonomous delegation. |
| "The workflow is too mixed to rate." | Segment it. Readiness and delegation are properties of bounded task segments. |
Red flags
- A readiness claim based on demos, confidence, or aggregate model benchmarks.
- A checkpoint after the output has already taken effect.
- Recovery described as "rerun it" without state, idempotency, or rollback evidence.
- One workflow-wide average hiding an unsupported segment.
Verification
The screen is complete when the candidate is bounded; all four prerequisites have a rating, evidence, and owner for any gap; unknown reliability or resilience does not yield a positive autonomy claim; exactly one outcome is recorded; and the human has confirmed the result before second-stage profiling or setup.
What ships with it: 3 files
3.9 KB alongside SKILL.md
agents/
- openai.yaml252 B
assets/
evals/
- evals.json2.8 KB