ghwf0-remote_skill

This skill monitors ghwf labels on issues and PRs and automates workflow execution to keep projects moving.

Shell

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill shotaiuchi/dotclaude --skill ghwf0-remote

SKILL.md6.8 KB

Overview

This skill controls a daemon that monitors GitHub Issue and PR labels and triggers workflows automatically. It provides start/stop/status commands and enforces an opt-in labeling scheme so only designated Issues/PRs are processed. The daemon runs in a tmux session and logs state and current execution metadata for observability and recovery.

How this skill works

The daemon polls the repository for Issues/PRs labeled with the required opt-in label and user command labels (e.g., ghwf:exec, ghwf:redo, ghwf:revision, ghwf:stop). It reacts to command labels, manages state labels (ghwf:executing, ghwf:waiting, ghwf:completed) and progress labels (ghwf:step-1 .. ghwf:step-7), and launches workflow steps by invoking configured scripts. The daemon ignores bot comments and uses retry/backoff settings for API and Claude calls; it records runtime state in JSON files and writes Claude output as stream-json logs.

When to use it

You need automated, label-driven workflow execution for Issues or PRs.
You want a long-running controller that resumes work after interruptions.
You need fine-grained retry and polling control for CI-like sequences.
You prefer opt-in processing to avoid accidental workflow runs.
You want visibility into current steps, Claude output, and daemon logs.

Best practices

Apply the required opt-in label (ghwf) on Issues/PRs to enable monitoring.
Use command labels deliberately (ghwf:exec, ghwf:redo, ghwf:revision, ghwf:stop) and update content when using redo/revision.
Run the daemon under tmux and keep MAX_STEPS_PER_SESSION to limit long runs when debugging.
Set VERBOSE for troubleshooting and increase GHWF_RETRY_MAX when API errors are frequent.
Ensure only collaborators with admin/write/maintain are allowed to add command labels.

Example use cases

Kick off a multi-step review and publication workflow when an Issue is labeled ghwf:exec.
Re-run from a specific step after fixing content by applying ghwf:redo-N and updating the Issue body or comments.
Force a full workflow restart with ghwf:revision after significant changes to requirements.
Temporarily pause or stop monitoring for a work item using ghwf:stop.
Monitor active Claude runs and inspect .wf/ghwf-current.json and .wf/ghwf-claude.log for debugging.

FAQ

Use /ghwf0-remote start to launch the tmux session and script, and /ghwf0-remote stop to kill the ghwf-daemon session.

What happens if the daemon crashes mid-run?

Runtime state is stored in .wf/ghwf-state.json and .wf/ghwf-current.json (while running). On restart the daemon can resume based on those files; logs and Claude stream-json output help with recovery.