RTK 的 /worktree-status 命令解析Git Worktree 后台 cargo check 状态查询机制【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk/worktree-status是 RTK 仓库为 Claude Code 定义的一条 slash command用于查询由/worktree命令在后台启动的cargo check的执行状态运行中 / 通过 / 失败。读完本文你将掌握该命令的完整 Bash 实现、基于日志标记的状态机判定逻辑、/tmp/worktree-cargocheck-*.log日志协议以及它与 worktree 创建、清理等周边命令的协作关系。1. 背景为什么 RTK 需要这条命令RTKRust Token Killer本身是一个 Rust 项目见 Cargo.toml其 Claude Code 工作流中定义了一套围绕 git worktree 的命令。其中 /worktree 命令的职责是在.worktrees/worktree-name下用git worktree add创建隔离工作树以约 1 秒完成 setup然后默认在后台执行cargo check非阻塞把完整输出重定向到日志文件打印提示Check status: /worktree-status branch-name把后续查询交给/worktree-status。也就是说/worktree只负责发起而/worktree-status负责跟踪。两者通过一个约定格式的日志文件解耦。日志文件的写入侧在 worktree.md 的脚本中( cd $WORKTREE_DIR echo cargo check started at $(date %H:%M:%S) $LOG_FILE if cargo check $LOG_FILE 21; then echo PASSED at $(date %H:%M:%S) $LOG_FILE else echo FAILED at $(date %H:%M:%S) $LOG_FILE fi ) 从这段写入逻辑可以看出日志协议只有三种合法状态标记首行cargo check started at HH:MM:SS末尾追加PASSED at HH:MM:SS或FAILED at HH:MM:SS。/worktree-status的全部判定逻辑就是围绕这三个标记构建的。注意一个前提/worktree脚本会在创建前检查主仓库 .gitignore 中包含.worktrees/当前仓库的 .gitignore 第 50 行确实有这一行否则 fail-fast。2. 命令定义与调用方式/worktree-status的完整定义位于 worktree-status.md。其 frontmatter 如下model: haiku description: Check background cargo check status for a git worktree argument-hint: branch-namemodel: haiku指定由轻量模型执行该命令脚本符合状态查询属于低复杂度操作的成本考量argument-hint: branch-name提示唯一参数是分支名且必须与创建 worktree 时使用的分支名完全一致脚本不做模糊匹配。用法示例/worktree-status feature/new-filter /worktree-status fix/bug-name分支命名约定来自/worktree文档分支名采用category/description斜杠形式而目录名与日志名中的斜杠会被替换为连字符即feature/new-filter→ 目录.worktrees/feature-new-filter、日志/tmp/worktree-cargocheck-feature-new-filter.log。3. 完整实现脚本以下是原文档中的实现脚本以分支名取自$ARGUMENTS执行#!/bin/bash set -euo pipefail BRANCH_NAME$ARGUMENTS LOG_FILE/tmp/worktree-cargocheck-${BRANCH_NAME//\//-}.log if [ ! -f $LOG_FILE ]; then echo No cargo check found for branch: $BRANCH_NAME echo echo Possible reasons: echo 1. Worktree created with --fast (check skipped) echo 2. Branch name mismatch (use exact branch name) echo 3. Check hasnt started yet (wait a few seconds) echo echo Available logs: ls -1 /tmp/worktree-cargocheck-*.log 2/dev/null || echo (none) exit 1 fi LOG_CONTENT$(head -n 500 $LOG_FILE) if echo $LOG_CONTENT | grep -q ^PASSED; then TIMESTAMP$(echo $LOG_CONTENT | grep ^PASSED | sed s/PASSED at //) echo cargo check passed echo Completed at: $TIMESTAMP echo echo Worktree is ready for development! elif echo $LOG_CONTENT | grep -q ^FAILED; then TIMESTAMP$(echo $LOG_CONTENT | grep ^FAILED | sed s/FAILED at //) echo cargo check failed echo Completed at: $TIMESTAMP echo echo Errors: echo ------------------------------------- grep -v ^PASSED\|^FAILED\|^cargo check started $LOG_FILE | head -30 echo ------------------------------------- echo echo Full log: cat $LOG_FILE echo echo You can still work on the worktree - fix errors as you go. elif echo $LOG_CONTENT | grep -q ^cargo check started; then START_TIME$(echo $LOG_CONTENT | grep ^cargo check started | sed s/cargo check started at //) CURRENT_TIME$(date %H:%M:%S) echo cargo check still running... echo Started at: $START_TIME echo Current time: $CURRENT_TIME echo echo Usually takes 5-30s depending on crate size. echo echo Live progress: tail -f $LOG_FILE else echo Unknown state echo echo Log content: cat $LOG_FILE fi4. 实现要点逐段解析4.1 日志路径推导LOG_FILE/tmp/worktree-cargocheck-${BRANCH_NAME//\//-}.log${BRANCH_NAME//\//-}是 Bash 的全局替换语法把分支名中所有/替换为-。这与 worktree.md 中WORKTREE_NAME${BRANCH_NAME//\//-}的目录命名规则完全一致保证查询侧与写入侧对同一分支推导出同一个文件名。使用/tmp作为存储位置意味着状态不随仓库走、不进入 git 跟踪代价是重启系统或清理/tmp后状态丢失——此时命令会走到日志不存在分支。4.2 日志不存在的诊断分支set -euo pipefail之下脚本对文件缺失做了显式处理而非直接崩溃。它输出三类最常见原因Worktree created with --fast/worktree --fast会跳过cargo check根本不产生日志Branch name mismatch查询名与创建名不一致例如漏写斜杠或分支已重命名Check hasnt started yet后台子 shell 启动有短暂延迟日志尚未落盘。随后ls -1 /tmp/worktree-cargocheck-*.log列出当前所有可用日志供人工比对最后exit 1以非零状态退出便于上层 agent 感知失败。4.3 状态机四个互斥分支脚本用head -n 500截取日志前 500 行然后按优先级顺序 grep 锚定行首的标记构成一个四态判定优先级匹配标记判定行为1^PASSED通过用sed s/PASSED at //提取完成时间戳提示 worktree 可开发2^FAILED失败提取时间戳用grep -v剔除协议标记行后head -30展示编译错误摘要并提示可用cat查看完整日志3^cargo check started运行中展示开始时间与当前时间差提示 5-30 秒量级给出tail -f实时跟踪命令4均不匹配未知状态原样cat整个日志交给人工/模型判断这个顺序是刻意的PASSED/FAILED是终态标记只可能出现在检查结束后只要日志里有终态标记就优先报告终态避免已开始的旧首行干扰判定。失败分支的grep -v ^PASSED\|^FAILED\|^cargo check started过滤掉三条协议行只留下 cargo 的真实错误输出这与 RTK 项目压缩命令输出的整体理念一致。时间戳提取依赖sed s/FAILED at //这类简单替换能工作的前提是写入侧严格按PASSED at HH:MM:SS格式追加——两个脚本共同遵守这一非正式协议。4.4 与 /worktree 的集成点原文档 Integration 一节说明/worktree在后台模式完成创建后会打印精确的查询命令cargo check running in background... Check status: /worktree-status feature/new-filter这与 worktree.md 脚本末尾的 Report 段完全对应。因此两条命令的交互模式是/worktree同步返回 给出状态查询入口开发者开始写代码若干秒后或下一次会话中调用/worktree-status获取编译结论。若检查失败文档明确提示 You can still work on the worktree - fix errors as you go即失败不阻塞开发符合该工作流先隔离、后验证的设计意图。另外/worktree还支持--check阻塞模式同步等待 cargo check 结束并直接打印结果在这种模式下日志文件同样会写入/worktree-status依然可用于事后复查。5. 三种输出示例原文档给出了全部典型输出以下原样保留Passedcargo check passed Completed at: 14:23:45 Worktree is ready for development!Failedcargo check failed Completed at: 14:24:12 Errors: ------------------------------------- error[E0308]: mismatched types -- src/git.rs:45:12 | 45 | let x: i32 hello; ------------------------------------- Full log: cat /tmp/worktree-cargocheck-feature-new-filter.log You can still work on the worktree - fix errors as you go.Still Runningcargo check still running... Started at: 14:22:30 Current time: 14:22:45 Usually takes 5-30s depending on crate size. Live progress: tail -f /tmp/worktree-cargocheck-feature-new-filter.log6. 与仓库中同族命令的协作/worktree-status是 RTK 仓库 worktree 生命周期工具链中的一环仓库里还有若干互补命令均以 Claude Code slash command 形式定义/worktree创建 worktree 并发起后台cargo check是本命令的数据来源/tech:worktree-status同一状态查询的 tech 命名空间变体。值得注意的一个细节从仓库内容看该变体查询的日志前缀是/tmp/worktree-cargo-check-*.log连字符分隔而/worktree实际写入的前缀是/tmp/worktree-cargocheck-*.log两者并不一致因此根目录版本才是与创建脚本真正配对的那一份/tech:remove-worktree删除指定 worktree目录 git 引用 本地/远程分支带已合并检查与确认交互/clean-worktree交互式审计并清理已合并的 worktree含永不删除 master/main等安全约束/clean-worktrees自动批量清理已合并 worktree支持--dry-run。典型生命周期为/worktree feature/x→ 开发期间/worktree-status feature/x轮询 → 合并后/tech:remove-worktree feature/x或/clean-worktrees统一回收。7. 实用细节与适用前提适用前提该命令依赖 git worktree 特性、Bash 与cargo环境且要求处于 RTK 仓库或遵循同一日志协议的仓库的 Claude Code 环境中日志生命周期状态存于/tmp重启或/tmp清理后历史状态不可查此时应重新执行/worktree branch --check阻塞式检查来获得确定结论前提是该分支 worktree 仍存在;token 优化配合RTK 本身对git worktree输出做了压缩支持rtk git worktree [add|remove|prune|list]见 FEATURES.md 中 rtk git worktree -- Worktree compact 一节在会话中管理多个 worktree 时可直接用 rtk 包装 git 命令以节省 token排错入口日志不存在时先跑ls /tmp/worktree-cargocheck-*.log核对实际文件名worktree.md 的 Troubleshooting 一节给出了同样的建议再检查是否用了--fast。小结/worktree-status用一个不到 60 行的 Bash 脚本把后台编译状态这一易失信息变成了可查询、可诊断的资源日志路径由分支名确定性推导协议标记构成四态状态机失败时自动摘要错误并给出完整日志入口。它与 /worktree、/tech:remove-worktree 等命令共同构成了 RTK 仓库中秒级隔离开发环境 异步编译验证 交互式清理的 worktree 工作流值得任何需要多分支并行开发且重视反馈延迟的 Rust 项目借鉴。【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考