back
loading skill details...
Evaluates if a multi-step workflow has sufficient information, permission, tools, evidence, and safety to proceed or needs clarification or review.
# AANA Workflow Readiness Check Skill Use this skill when an OpenClaw-style agent is about to begin a workflow, plan, multi-step task, tool sequence, external action, file operation, research task, customer action, code change, booking, purchase, or high-impact decision. This is an instruction-only skill. It does not install packages, run commands, write files, call services, persist memory, or execute a checker on its own. ## Core Principle Before starting a workflow, the agent should confirm it has enough information, permission, tools, evidence, and safe boundaries to proceed. The agent should separate: - workflows that are ready to start, - workflows that need clarification, - workflows that need explicit permission, - workflows that need evidence or retrieval first, - workflows that need a tool or credential the agent does not have, - workflows that need human, professional, or admin review, - workflows that should not start. ## When To Use Use this skill before: - starting a multi-step workflow, - calling tools or connectors, - changing files, code, settings, accounts, or production systems, - sending, publishing, uploading, booking, buying, subscribing, renewing, refunding, or transferring, - answering with material factual, legal, medical, financial, safety, policy, or customer impact, - using private data, user records, logs, inboxes, calendars, drives, databases, repositories, or account information, - continuing from an ambiguous or underspecified request. ## Readiness Categories Classify the workflow: - `ready`: enough information, permission, tools, and evidence are available. - `needs_information`: required inputs or constraints are missing. - `needs_permission`: approval or authorization is missing. - `needs_evidence`: facts, records, sources, tests, or tool results are missing. - `needs_tool_access`: a required tool, credential, connector, file, or account is unavailable. - `needs_review`: human, professional, admin, or policy review is required. - `not_safe`: the workflow should not start. ## AANA Readiness Loop 1. Identify the workflow and intended outcome. 2. Define the minimum completion criteria. 3. Check required information: inputs, constraints, dates, targets, identities, amounts, policies, and success criteria. 4. Check permission: user approval, ownership, authority, target scope, and external-action consent. 5. Check tools: required tools, access, credentials, permissions, and safer alternatives. 6. Check evidence: available facts, sources, records, test results, citations, and uncertainty. 7. Check risk: private data, financial impact, legal/medical/safety impact, irreversible actions, production impact, and public exposure. 8. Choose action: start, ask, retrieve, request approval, route to review, narrow, or refuse. ## Required Pre-Workflow Checks Before starting, verify: - user request, - workflow summary, - intended outcome, - completion criteria, - required information, - permission status, - tool/access status, - evidence status, - risk level, - first safe step. ## Information Rules Do not start a workflow when: - the target is unclear, - required dates, amounts, recipients, files, accounts, systems, or success criteria are missing, - the user has not selected between materially different options, - the workflow could affect another person or organization and identity/authority is unclear. Ask a focused question instead of guessing. ## Permission Rules Require explicit approval before starting when the workflow: - changes files, accounts, code, settings, permissions, or production systems, - sends, publishes, posts, uploads, books, buys, subscribes, renews, refunds, transfers, cancels, deletes, or overwrites, - accesses private data beyond what the user clearly provided, - affects money, legal rights, health, safety, employment, housing, education, insurance, reputation, or public records. Approval should name the workflow, target scope, and first state-changing step. ## Tool Rules Do not start a tool-dependent workflow when: - the required tool is unavailable, - the target scope cannot be limited, - credentials or permissions are missing, - the tool would expose unrelated private data, - a safer read-only, preview, draft, or dry-run step is available and has not been used. Prefer a narrow readiness step before a broad action. ## Evidence Rules Do not start or complete an evidence-dependent workflow when: - key facts are unsupported, - sources are missing or stale, - test claims are unrun, - policy claims are unverified, - customer/account facts are not available, - legal, medical, financial, or safety conclusions lack qualified evidence. Retrieve, ask, or route to review before acting. ## Review Payload When using a configured AANA checker, send only a minimal redacted review payload: - `user_request` - `workflow_summary` - `intended_outcome` - `readiness_status` - `information_status` - `permission_status` - `tool_status` - `evidence_status` - `risk_level` - `recommended_action` Do not include raw secrets, credentials, full private records, full logs, full transcripts, full account records, or unrelated private data when a redacted summary is enough. ## Decision Rule - If information, permission, tools, evidence, and risk boundaries are sufficient, start with the first safe step. - If required inputs are missing, ask. - If facts or records are missing, retrieve with the narrowest safe scope. - If authorization is missing, request explicit approval. - If tools or credentials are unavailable, explain the blocker or choose a safer available path. - If the workflow is high-impact, irreversible, professional, production, or policy-sensitive, route to review. - If the workflow is unsafe, unauthorized, deceptive, or harmful, refuse unsafe parts. - If a checker is unavailable or untrusted, use manual readiness review. ## Output Pattern For readiness-sensitive work, prefer: ```text AANA readiness check: - Workflow: ... - Intended outcome: ... - Information: sufficient / missing / ambiguous / conflicting / unknown - Permission: explicit / implicit_low_risk / required / denied / unclear - Tools: available / unavailable / limited / unsafe_scope / not_needed - Evidence: sufficient / partial / missing / stale / conflicting / unknown - Risk: low / moderate / high / irreversible / private / production / professional / unknown - Decision: start / ask / retrieve / request_approval / route_to_review / narrow / refuse ``` Do not include this check in the user-facing answer unless clarification, approval, retrieval, review, or a readiness blocker needs to be explained.
don't have the plugin yet? install it then click "run inline in claude" again.
restructured original into six implexa components (intent, inputs, procedure, decision_points, output_contract, outcome_signal), added edge cases (rate limits, auth expiry, unsafe_scope), clarified tool access and credential inputs with env var examples, expanded decision logic into explicit if-else branches, and preserved original readiness loop and category definitions.
use this skill before starting any multi-step workflow, tool sequence, external action, or high-impact decision. the skill evaluates whether the workflow has sufficient information, permission, tools, evidence, and safety boundaries to proceed. it separates workflows into seven readiness states: ready to start, needs clarification, needs explicit permission, needs evidence retrieval, needs tool access, needs human or admin review, or unsafe to start. run this check before any state-changing action, especially file operations, code changes, financial transactions, access to private data, or decisions with legal, medical, safety, or policy impact.
SALESFORCE_API_KEY, HUBSPOT_PAT, GITHUB_TOKEN).identify the workflow name and intended outcome. write a one-sentence summary of what the workflow does and what state it should reach on completion.
define minimum completion criteria. list the measurable conditions that mark success (e.g., "file written to location X", "API returns status 200", "approval logged with timestamp").
check required information. verify that all inputs, constraints, dates, targets, identities, amounts, policies, and success thresholds are specified. if any are missing, unclear, or in conflict, flag them as "needs_information".
check permission. determine whether the user owns the target, has authority over it, or has explicit consent. if the workflow affects another person or organization, verify identity and authorization. flag as "needs_permission" if approval is missing.
check tool access and credentials. confirm that each required tool is available and that credentials or API keys are valid and in scope. if a tool is unavailable, flag as "needs_tool_access". if a safer alternative (read-only, preview, draft, or dry-run mode) exists and has not been used, prefer it.
check evidence. verify that key facts, sources, records, and test results are available. if claims about policies, customer data, legal status, medical facts, or financial figures are unsupported, flag as "needs_evidence". do not proceed on assumptions.
assess risk. evaluate whether the workflow involves private data, financial impact, legal or medical or safety implications, irreversible actions, production system changes, or public exposure. rate risk as low, moderate, high, irreversible, private, production, or professional.
choose action based on readiness state. apply the decision rule (see decision points section) to determine whether to start, ask, retrieve, request approval, route to review, narrow, or refuse.
output the readiness check result in the standard format (see output contract). do not include raw secrets, full private records, full logs, or unredacted transcripts in the output.
if the workflow is ready, proceed with the first safe step. if it is not ready, explain the blocker and ask for clarification, evidence, approval, or review before proceeding.
if information is sufficient and permission is explicit and tools are available and evidence is complete and risk is low or manageable: start the workflow with the first safe step.
if required information is missing or ambiguous: ask a focused question to clarify the target, dates, amounts, recipients, files, accounts, systems, or success criteria. do not guess. do not proceed until the user confirms.
if facts, records, sources, or test results are missing: retrieve the missing evidence with the narrowest safe scope before proceeding. cite sources in the workflow record.
if authorization is missing for a state-changing action: request explicit approval that names the workflow, target scope, and first state-changing step. do not proceed without written or logged confirmation.
if a required tool, credential, or API key is unavailable: explain the blocker. if a safer read-only, preview, draft, or dry-run alternative exists, offer it. if no alternative is available, refuse the workflow and suggest a manual path.
if the workflow is high-impact, irreversible, professional, policy-sensitive, or involves production systems: route to a human, professional, or admin review before proceeding. include the readiness check payload in the review request.
if the workflow is unsafe, unauthorized, deceptive, or harmful: refuse to proceed. explain why and suggest a safe alternative if one exists.
if the aana checker service is unavailable or untrusted: use manual readiness review. follow the readiness loop steps explicitly and document the review in the workflow record.
if the user has not selected between materially different options: ask the user to clarify which path to take before proceeding. do not assume intent.
if the workflow could be split into a safer narrow readiness step and a broader action: prefer the narrow step first (e.g., a read-only preview before a write or publish).
output a readiness check result in one of two formats:
format 1: standard readiness check (for inline workflows):
AANA readiness check:
- Workflow: <name and one-sentence summary>
- Intended outcome: <desired end state>
- Information: <sufficient / missing / ambiguous / conflicting / unknown>
- Permission: <explicit / implicit_low_risk / required / denied / unclear>
- Tools: <available / unavailable / limited / unsafe_scope / not_needed>
- Evidence: <sufficient / partial / missing / stale / conflicting / unknown>
- Risk: <low / moderate / high / irreversible / private / production / professional / unknown>
- Decision: <start / ask / retrieve / request_approval / route_to_review / narrow / refuse>
- First safe step: <description of first action if ready, or blocker if not>
format 2: aana review payload (for routing to checker or human review):
{
"user_request": "<original user request>",
"workflow_summary": "<one-sentence workflow description>",
"intended_outcome": "<desired end state>",
"readiness_status": "<ready / needs_information / needs_permission / needs_evidence / needs_tool_access / needs_review / not_safe>",
"information_status": "<sufficient / missing / ambiguous / conflicting / unknown>",
"permission_status": "<explicit / implicit_low_risk / required / denied / unclear>",
"tool_status": "<available / unavailable / limited / unsafe_scope / not_needed>",
"evidence_status": "<sufficient / partial / missing / stale / conflicting / unknown>",
"risk_level": "<low / moderate / high / irreversible / private / production / professional / unknown>",
"recommended_action": "<start / ask / retrieve / request_approval / route_to_review / narrow / refuse>",
"blockers": [<list of specific missing information, permission, tools, or evidence>],
"first_safe_step": "<description if ready, null if not>"
}
do not include raw secrets, credentials, full private records, full logs, full transcripts, full account records, or unrelated private data in the output. use redacted summaries instead (e.g., "user has Salesforce API access" instead of the full API key).
the skill worked if: