Wander — CI Workflow Monitor
Don't watch. Wander. CLI toolkit for monitoring GitHub Actions. No polling; optional macOS notifications when runs finish.
Agent auto-trigger (mandatory)
After every git push that triggers GitHub Actions, start Wander in background mode unless the user opts out.
- 1. If
.workflows.yml exists in the repo root: prefer a project wrapper (scripts/watch-*.sh) when present. - Otherwise:
"$WANDER_HOME/watch-workflow-bg.sh" <workflow.yml> (or pass the workflow file the project uses). - Run in the background so the session stays responsive.
- After ~8s, check terminal output and report initial status.
If there is no .workflows.yml but .github/workflows/ exists, offer monitoring but do not auto-start without confirmation.
When to use this skill
- - User wants to monitor a workflow after INLINECODE6
- User asks for notifications when CI completes
- User wants to avoid manually refreshing the Actions page
- Long-running E2E or publish pipelines (minutes)
- Project integrates CI monitoring (e.g. ClawHub publish)
Prerequisites
- -
gh CLI installed and authenticated - INLINECODE8 (used by scripts)
- Wander clone on disk;
WANDER_HOME or default INLINECODE10 - macOS for notification center integration
Install (tool)
CODEBLOCK0
Add to ~/.zshrc or ~/.bashrc:
CODEBLOCK1
Or run ./scripts/install-personal.sh from the Wander repo (see main README).
Usage patterns
Smart push (Wander repo or similar)
CODEBLOCK2
Suggests smoke / e2e / skip from changed files, then push and monitor.
Manual control (any repo)
CODEBLOCK3
Modes
| Mode | Script | Use case |
|---|
| Foreground | INLINECODE14 | Block until result |
| Background |
watch-workflow-bg.sh | Keep working; notify when done |
| Detached |
watch-workflow-detached.sh | Close terminal; logs under
~/.wander_logs/ |
Project wrapper (recommended)
CODEBLOCK4
Then: INLINECODE18
Examples elsewhere: openclaw-uninstall uses ./scripts/watch-publish.sh and watch-publish-detached.sh when present.
Workflow registry
For check_window / expected_duration, add .workflows.yml at project root or set WORKFLOW_REGISTRY_FILE:
CODEBLOCK5
Default check_window is 300 seconds when a workflow is not listed.
Edge cases
| Scenario | Behavior | Tip |
|---|
| Workflow finishes in under ~30s | May show "already completed" + quick notify | INLINECODE27 detects recent completion |
| Push then monitor immediately |
Run may not appear for 5–10s | Scripts wait up to ~30s for the run to show |
| Wrong branch | No workflow after wait window | Confirm workflow
on: filters match current branch |
| No lockfile in repo |
setup-node with
cache: npm can fail | Remove
cache: npm if there is no package lockfile |
When CI fails
- 1. Note the run ID from output or notification.
- View failed logs: INLINECODE32
- Fix and
git push, or INLINECODE34
WANDER_HOME resolution
- - Environment variable
WANDER_HOME if set - Sibling path:
$(dirname "$REPO_ROOT")/wander (common in wrappers) - Default: INLINECODE37
Reference
Wander — CI 工作流监视器
别盯着看。去溜达。 用于监视 GitHub Actions 的 CLI 工具包。无需轮询；工作流完成时可选 macOS 通知。
代理自动触发（强制）
每次触发 GitHub Actions 的 git push 后，自动在后台启动 Wander，除非用户选择退出。
- 1. 如果仓库根目录存在 .workflows.yml：优先使用项目包装脚本（scripts/watch-*.sh）。
- 否则：执行 $WANDER_HOME/watch-workflow-bg.sh （或传入项目使用的工作流文件）。
- 在后台运行，保持会话响应。
- 约 8 秒后，检查终端输出并报告初始状态。
如果没有 .workflows.yml 但存在 .github/workflows/，提供监视选项但未经确认不自动启动。
何时使用此技能
- - 用户想在 git push 后监视工作流
- 用户希望在 CI 完成时收到通知
- 用户希望避免手动刷新 Actions 页面
- 长时间运行的 E2E 或发布流水线（数分钟）
- 项目集成了 CI 监视（例如 ClawHub 发布）
前提条件
- - 已安装并认证 gh CLI
- jq（脚本使用）
- 本地有 Wander 克隆；WANDER_HOME 或默认 ~/code/wander
- macOS 用于通知中心集成
安装（工具）
bash
git clone https://github.com/ERerGB/wander.git ~/code/wander
cd ~/code/wander
chmod +x *.sh
添加到 ~/.zshrc 或 ~/.bashrc：
bash
export WANDERHOME=${WANDERHOME:-$HOME/code/wander}
export PATH=$WANDER_HOME:$PATH
alias wf=watch-workflow.sh
alias wfbg=watch-workflow-bg.sh
alias wfdt=watch-workflow-detached.sh
或者从 Wander 仓库运行 ./scripts/install-personal.sh（参见主 README）。
使用模式
智能推送（Wander 仓库或类似）
bash
cd /path/to/wander
./smart-push.sh
根据变更文件建议 smoke / e2e / skip，然后推送并监视。
手动控制（任意仓库）
bash
git push
cd /path/to/target-repo
$WANDER_HOME/watch-workflow-bg.sh publish.yml
模式
| 模式 | 脚本 | 使用场景 |
|---|
| 前台 | watch-workflow.sh | 阻塞直到获得结果 |
| 后台 |
watch-workflow-bg.sh | 继续工作；完成时通知 |
| 分离 | watch-workflow-detached.sh | 关闭终端；日志保存在 ~/.wander_logs/ |
项目包装脚本（推荐）
bash
#!/bin/bash
scripts/watch-publish.sh
REPO
ROOT=$(cd $(dirname ${BASHSOURCE[0]})/.. && pwd)
WANDER
DIR=${WANDERDIR:-$(dirname $REPO_ROOT)/wander}
cd $REPO_ROOT
exec $WANDER_DIR/watch-workflow-bg.sh publish.yml $@
然后：git push && ./scripts/watch-publish.sh
其他示例：openclaw-uninstall 在存在时使用 ./scripts/watch-publish.sh 和 watch-publish-detached.sh。
工作流注册表
对于 checkwindow / expectedduration，在项目根目录添加 .workflows.yml 或设置 WORKFLOWREGISTRYFILE：
yaml
workflows:
- name: publish.yml
description: 发布到 ClawHub
check_window: 120
expected_duration: 30
category: publish
当工作流未列出时，默认 check_window 为 300 秒。
边界情况
| 场景 | 行为 | 提示 |
|---|
| 工作流在约 30 秒内完成 | 可能显示已完成并快速通知 | watch-workflow-bg.sh 检测近期完成 |
| 推送后立即监视 |
运行可能 5-10 秒后才出现 | 脚本等待最多约 30 秒让运行显示 |
| 错误的分支 | 等待窗口后无工作流 | 确认工作流 on: 过滤器匹配当前分支 |
| 仓库无锁文件 | setup-node 使用 cache: npm 可能失败 | 如果没有 package 锁文件，移除 cache: npm |
当 CI 失败时
- 1. 从输出或通知中记下运行 ID。
- 查看失败日志：gh run view ID> --log-failed
- 修复并 git push，或 gh run rerun ID> --failed
WANDER_HOME 解析
- - 环境变量 WANDERHOME（如果设置）
- 同级路径：$(dirname $REPOROOT)/wander（常见于包装脚本）
- 默认：~/code/wander
参考
