wheel-skip

Cancel stalled interactive wheel steps and clear awaiting_user_input via CLI.

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/yoshisada/ai-repo-template --skill wheel-skip
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: wheel-skip
Source: https://github.com/yoshisada/ai-repo-template/tree/main/plugin-wheel/skills/wheel-skip
Command: npx skills add https://github.com/yoshisada/ai-repo-template --skill wheel-skip

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Stalled interactive workflow steps waiting for user input can block progress. wheel-skip provides a safe escape hatch to cancel the pending step, write a clear sentinel, and free downstream steps to proceed.

Core Features & Use Cases

  • Cancel a step that is awaiting input and write the exact cancel sentinel to the step's output.
  • Clear the awaiting_user_input flag so the workflow can continue.
  • Downstream steps inspect the output for {"cancelled": true, "reason": "user-skipped"} and adapt accordingly.
  • Safe no-op when there is no active workflow or no step awaiting input.
  • Overwrite any existing output to ensure the cancellation intent is explicit.
  • Aligns with v1 contract expectations and simplifies recovery from stalled steps.

Quick Start

Invoke the wheel-skip CLI to cancel a waiting interactive step and advance the workflow.

Frequently Asked Questions about wheel-skip

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I cancel a stalled interactive workflow step waiting for user input?

Canceling a stalled interactive workflow step involves writing a cancel sentinel to the step's output and clearing the awaiting_user_input flag. The wheel-skip CLI automates this by writing {"cancelled": true, "reason": "user-skipped"} so downstream steps can adapt.

How do I bypass an awaiting_user_input flag without manual intervention?

Bypassing an awaiting_user_input flag without manual intervention requires writing a specific cancel sentinel to the step's output. The CLI overwrites existing output with {"cancelled": true, "reason": "user-skipped"} and clears the flag automatically.

What happens to downstream workflow steps when a waiting interactive step is skipped?

Downstream workflow steps inspect the step's output for the {"cancelled": true, "reason": "user-skipped"} sentinel and adapt accordingly. This explicit cancellation intent frees them to proceed safely after a skipped interactive step.

Is it safe to cancel a workflow step if there is no active workflow or awaiting input?

Canceling a workflow step when there is no active workflow or no step awaiting input is a safe no-op. The CLI detects the absence of an awaiting_user_input flag and exits without causing unintended side effects.

What is the exact cancel sentinel written when bypassing a stalled workflow step?

The exact cancel sentinel written when bypassing a stalled workflow step is {"cancelled": true, "reason": "user-skipped"}. This JSON output overwrites any existing data to ensure explicit cancellation intent adheres to v1 contracts.

Why does my workflow block when a step is waiting on user input?

A workflow blocks when a step sets the awaiting_user_input flag, halting progress until manual intervention occurs. This stalls downstream steps unless bypassed safely by clearing the flag and writing an explicit cancellation sentinel.