feat(tools): add worktrunk as default worktree tool with fallback#109
feat(tools): add worktrunk as default worktree tool with fallback#109marcusquinn merged 1 commit intomainfrom
Conversation
- Add setup_worktrunk() to setup.sh for install/update via brew/cargo - Add worktrunk to tool-version-check.sh BREW_TOOLS for update tracking - Create tools/git/worktrunk.md subagent documentation - Update workflows/worktree.md to recommend worktrunk over worktree-helper.sh - Update .agent/AGENTS.md worktree section with worktrunk commands - Add architecture.md awareness instruction to root AGENTS.md Worktrunk (wt) provides better UX than raw git worktree: - Shell integration (cd support) - Hooks for automated setup - CI status and PR links in list output - Merge workflow (squash/rebase + cleanup) worktree-helper.sh remains as dependency-free fallback.
WalkthroughIntroduces Worktrunk (wt) as the primary tool for Git worktree management across documentation, tooling checks, and setup automation. Replaces explicit worktree commands with Worktrunk-centric workflows while maintaining fallback references to previous shell-script approaches. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @marcusquinn, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly upgrades the Git worktree management capabilities within the project by integrating Worktrunk as the primary tool. It streamlines the setup process for Worktrunk, provides extensive documentation for its usage, and updates existing workflow guides to reflect this new recommendation. The changes aim to enhance developer experience for parallel branch work, particularly for AI agent workflows, while maintaining a robust fallback option for environments where Worktrunk might not be installed. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Sat Jan 17 02:01:59 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces worktrunk as the recommended git worktree management tool, with comprehensive documentation and setup script integration. The changes are well-structured and align with the PR's goal.
My review focuses on the new setup_worktrunk function in setup.sh. I've identified several areas for improvement regarding robustness, maintainability, and user experience. Specifically, I've made suggestions to:
- Improve error handling by not suppressing output from installation commands.
- Enhance user input validation to be more flexible.
- Add support for the
fishshell, consistent withworktrunk's capabilities. - Address code duplication to improve maintainability.
- Fix an inconsistent user message after installation.
These changes will make the setup script more robust and easier for developers to use and maintain. The rest of the changes, primarily documentation, look excellent.
| case "$shell_name" in | ||
| zsh) shell_rc="$HOME/.zshrc" ;; | ||
| bash) | ||
| if [[ "$(uname)" == "Darwin" ]]; then | ||
| shell_rc="$HOME/.bash_profile" | ||
| else | ||
| shell_rc="$HOME/.bashrc" | ||
| fi | ||
| ;; | ||
| esac |
There was a problem hiding this comment.
According to the Worktrunk documentation, it supports fish shell in addition to bash and zsh. This logic for detecting the shell configuration file should be extended to handle fish to provide a better experience for users of that shell. Other parts of this script, like setup_aliases, already handle fish.
| case "$shell_name" in | |
| zsh) shell_rc="$HOME/.zshrc" ;; | |
| bash) | |
| if [[ "$(uname)" == "Darwin" ]]; then | |
| shell_rc="$HOME/.bash_profile" | |
| else | |
| shell_rc="$HOME/.bashrc" | |
| fi | |
| ;; | |
| esac | |
| case "$shell_name" in | |
| zsh) shell_rc="$HOME/.zshrc" ;; | |
| bash) | |
| if [[ "$(uname)" == "Darwin" ]]; then | |
| shell_rc="$HOME/.bash_profile" | |
| else | |
| shell_rc="$HOME/.bashrc" | |
| fi | |
| ;; | |
| fish) shell_rc="$HOME/.config/fish/config.fish" ;; | |
| esac |
| if ! grep -q "worktrunk" "$shell_rc" 2>/dev/null; then | ||
| print_info "Shell integration not detected" | ||
| read -r -p "Install Worktrunk shell integration (enables 'wt switch' to change directories)? (y/n): " install_shell | ||
| if [[ "$install_shell" == "y" ]]; then |
There was a problem hiding this comment.
This check is case-sensitive and only accepts a lowercase 'y'. For a more robust and user-friendly script, you should handle uppercase 'Y' as well. Other parts of the script, like the confirm_step function, handle various user inputs (e.g., 'y', 'yes', empty for default). Consider adopting a similar pattern here and in other read prompts within this function.
| if [[ "$install_shell" == "y" ]]; then | |
| if [[ "$install_shell" == "y" || "$install_shell" == "Y" ]]; then |
| print_info "Shell integration not detected" | ||
| read -r -p "Install Worktrunk shell integration (enables 'wt switch' to change directories)? (y/n): " install_shell | ||
| if [[ "$install_shell" == "y" ]]; then | ||
| if wt config shell install 2>/dev/null; then |
There was a problem hiding this comment.
Redirecting stderr to /dev/null for wt config shell install hides potentially useful error messages if the command fails. It's better to let the error message be displayed to the user for easier debugging.
| if wt config shell install 2>/dev/null; then | |
| if wt config shell install; then |
|
|
||
| if [[ "$install_wt" == "y" ]]; then | ||
| print_info "Installing Worktrunk..." | ||
| if brew install max-sixty/worktrunk/wt 2>/dev/null; then |
There was a problem hiding this comment.
Redirecting stderr from brew install to /dev/null prevents the user from seeing why an installation might have failed. Displaying error output from package managers is crucial for troubleshooting.
| if brew install max-sixty/worktrunk/wt 2>/dev/null; then | |
| if brew install max-sixty/worktrunk/wt; then |
| # Install shell integration | ||
| print_info "Installing shell integration..." | ||
| if wt config shell install 2>/dev/null; then | ||
| print_success "Shell integration installed" | ||
| print_info "Restart your terminal or source your shell config" | ||
| else | ||
| print_warning "Shell integration failed - run manually: wt config shell install" | ||
| fi |
There was a problem hiding this comment.
This block of code for installing shell integration is repeated multiple times in this function (here, after cargo install, and when wt is already present). To improve maintainability and reduce duplication, consider extracting this logic into a helper function.
For example:
_install_wt_shell_integration() {
local shell_rc_path="$1"
print_info "Installing shell integration..."
if wt config shell install; then
print_success "Shell integration installed"
if [[ -n "$shell_rc_path" ]]; then
print_info "Restart your terminal or run: source \"$shell_rc_path\""
else
print_info "Restart your terminal or source your shell config."
fi
else
print_warning "Shell integration failed - run manually: wt config shell install"
fi
}You could then call this function with the appropriate shell_rc path where needed.
|
|
||
| # Install shell integration | ||
| print_info "Installing shell integration..." | ||
| if wt config shell install 2>/dev/null; then |
There was a problem hiding this comment.
Similar to other commands in this function, redirecting stderr for wt config shell install here hides potentially useful error messages. Please remove the redirection to aid in debugging potential failures.
| if wt config shell install 2>/dev/null; then | |
| if wt config shell install; then |
|
|
||
| if [[ "$install_wt" == "y" ]]; then | ||
| print_info "Installing Worktrunk via Cargo..." | ||
| if cargo install worktrunk 2>/dev/null; then |
There was a problem hiding this comment.
Redirecting stderr from cargo install to /dev/null can make it hard to debug installation issues. It's best to show the user any errors that occur.
| if cargo install worktrunk 2>/dev/null; then | |
| if cargo install worktrunk; then |
| # Install shell integration | ||
| if wt config shell install 2>/dev/null; then | ||
| print_success "Shell integration installed" | ||
| else | ||
| print_warning "Shell integration failed - run manually: wt config shell install" | ||
| fi |
There was a problem hiding this comment.
After successfully installing the shell integration, you should inform the user that they need to restart their terminal or source their shell configuration file for the changes to take effect. This message is present in the other installation paths but is missing here. Also, it's better to not suppress stderr to help with debugging.
| # Install shell integration | |
| if wt config shell install 2>/dev/null; then | |
| print_success "Shell integration installed" | |
| else | |
| print_warning "Shell integration failed - run manually: wt config shell install" | |
| fi | |
| # Install shell integration | |
| if wt config shell install; then | |
| print_success "Shell integration installed" | |
| print_info "Restart your terminal or source your shell config to apply changes." | |
| else | |
| print_warning "Shell integration failed - run manually: wt config shell install" | |
| fi |
🤖 Augment PR SummarySummary: This PR standardizes on Worktrunk ( Changes:
Technical Notes: Worktrunk’s shell integration is required for 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| esac | ||
|
|
||
| if [[ -n "$shell_rc" ]] && [[ -f "$shell_rc" ]]; then | ||
| if ! grep -q "worktrunk" "$shell_rc" 2>/dev/null; then |
There was a problem hiding this comment.
grep -q "worktrunk" "$shell_rc" likely won’t detect Worktrunk’s actual shell integration snippet (docs show eval "$(wt config shell init …)"), so this may repeatedly prompt even when integration is already installed. Consider checking for the specific wt config shell init line (or using a wt config … status check) to avoid false negatives.
🤖 Was this useful? React with 👍 or 👎
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @.agent/tools/git/worktrunk.md:
- Around line 235-239: Add a blank line both immediately before and immediately
after each fenced code block in the Troubleshooting sections (e.g., the block
under the "Shell integration not installed:" paragraph containing "wt config
shell install" / "source ~/.zshrc", the block under the "Branch already checked
out" section with "wt list" / "wt remove feature/auth", and the Windows note
with "git-wt switch feature/auth") so that each ```bash fence is separated by a
blank line from surrounding text to satisfy markdownlint MD031.
- Around line 168-182: Update the "LLM Commit Messages" section to include a
short security note instructing developers to store llm API keys in the
project-standard credentials file (~/.config/aidevops/mcp-env.sh) and reference
any environment variable names used by llm; mention this applies when enabling
llm commits (e.g., wt config set llm_commits true) and give a one-line reminder
to keep the file permissions restricted.
In `@setup.sh`:
- Around line 575-603: The shell integration detection is using the wrong marker
"worktrunk" so it fails to recognize installed integration; update the grep
checks that reference the shell rc detection (the condition that inspects
"$shell_rc" and the other equivalent checks) to look for the actual marker "wt
init" instead, so change the grep pattern used in the conditional that guards
shell integration prompting (the block around shell_rc and the other two
equivalent checks) to grep -q "wt init" "$shell_rc" 2>/dev/null; keep the rest
of the flow (print_info, wt config shell install call, and success/warning
messages) unchanged.
🧹 Nitpick comments (1)
.agent/AGENTS.md (1)
225-234: Add Cargo installation option and clarify fallback conditions.The PR objectives mention offering installation via both Homebrew and Cargo, but only Homebrew is shown in the inline comment. Additionally, the fallback section doesn't clearly indicate WHEN users should use
worktree-helper.shinstead of Worktrunk.Consider enhancing the guidance:
📝 Suggested improvements
-# Recommended: Worktrunk (install: brew install max-sixty/worktrunk/wt) +# Recommended: Worktrunk (install: brew install worktrunk OR cargo install worktrunk) wt switch -c feature/my-feature # Create worktree + cd into it wt list # List with CI status wt merge # Squash/rebase + cleanup +wt remove <branch> # Remove merged worktree -# Fallback: worktree-helper.sh (no dependencies) +# Fallback: worktree-helper.sh (if Worktrunk unavailable - no dependencies) ~/.aidevops/agents/scripts/worktree-helper.sh add feature/my-feature
| ## LLM Commit Messages | ||
|
|
||
| Worktrunk integrates with [llm](https://llm.datasette.io/) for AI-generated commit messages: | ||
|
|
||
| ```bash | ||
| # Install llm | ||
| pip install llm | ||
|
|
||
| # Configure (uses your default LLM) | ||
| wt config set llm_commits true | ||
|
|
||
| # Now commits auto-generate messages from diffs | ||
| git add . | ||
| wt commit # Generates message via LLM | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the current state of worktrunk.md
fd worktrunk.mdRepository: marcusquinn/aidevops
Length of output: 93
🏁 Script executed:
# Search for existing credential storage patterns in documentation
rg -t md "mcp-env.sh|api.?key|credential" --max-count 20Repository: marcusquinn/aidevops
Length of output: 34366
🏁 Script executed:
# Look for documentation about the llm tool in the codebase
rg -t md "llm" -B 2 -A 5 | head -100Repository: marcusquinn/aidevops
Length of output: 5320
🌐 Web query:
llm datasette API keys configuration and requirements
💡 Result:
Summary — how Datasette's llm tooling and LLM-based plugins handle API keys, and what you must configure
- Where keys are stored / ways to provide them
- llm tool built‑in key store: run llm keys set to save a key (stored in keys.json). The saved alias can be used with llm and many Datasette plugins. [1]
- Environment variables: common for containers/servers (e.g. OPENAI_API_KEY). Plugins will read provider‑specific env vars if present. [1][3]
- Datasette plugin config / metadata: some plugins let you map model IDs to env vars or define keys in metadata.yml/json (plugins -> -> keys / key_env_var). Example: datasette-llm-embed and other plugins support configuring keys in metadata.yml pointing at an $env var. [2][3][4]
- Resolution / precedence (typical)
- Plugin-specific config in metadata.json/yml (if provided) → llm keys alias (keys.json) → environment variable → error if none present. Exact precedence can vary per plugin; check plugin docs. [3][4]
- What plugins expect (requirements)
- The underlying llm package must be installed and configured for the provider/model you intend to use (e.g., llm-openai plugin for OpenAI models). Some plugins require async-capable models or structured-output support — see each plugin for details. [1][5]
- Provide the full model ID when mapping keys where requested (e.g., ada-002). [2]
- For container deployments, prefer env vars; for local dev the llm key store is convenient. [1][3]
- Common config examples
- llm keys set openai (interactive storage in keys.json). [1]
- Environment variable: export OPENAI_API_KEY="sk-…". [1][3]
- metadata.yml plugin key example:
plugins:
datasette-llm-embed:
keys:
ada-002:
$env: OPENAI_API_KEY
(or plugin-specific key_env_var / env_api_key_var settings). [2][3][4]
- Security & operational notes
- Do not expose server-side API keys to client-side/localStorage. Plugins note that UI localStorage is used only for UI state/history; keys must be provided on the server. [3]
- Sharing a Datasette instance with a configured key lets users potentially consume your paid LLM quota — be cautious about permissions and public access. [3]
References
[1] Datasette llm tool — Setup & API key management. (llm.datasette.io)
[2] datasette-llm-embed plugin docs (example metadata keys mapping). (datasette.io)
[3] datasette-llm-sql-writer README / PyPI (auth, env var config, warnings). (pypi.org)
[4] datasette-query-assistant plugin docs (model and key_env_var config). (datasette.io)
[5] datasette-extract plugin docs (requirements: async models, discovery of configured keys). (pypi.org)
If you want, tell me which Datasette plugin(s) you plan to use and whether you’re deploying locally or in a container, and I’ll give exact metadata.yml and environment-variable examples.
Citations:
- 1: https://llm.datasette.io/en/stable/setup.html?utm_source=openai
- 2: https://datasette.io/plugins/datasette-llm-embed?utm_source=openai
- 3: https://pypi.org/project/datasette-llm-sql-writer/?utm_source=openai
- 4: https://datasette.io/plugins/datasette-query-assistant?utm_source=openai
- 5: https://pypi.org/project/datasette-extract/?utm_source=openai
Add secure storage guidance for llm API keys.
The llm tool requires API keys for LLM providers (OpenAI, Anthropic, etc.). Add a note directing developers to store credentials in ~/.config/aidevops/mcp-env.sh per project standards.
🔒 Suggested doc addition
# Install llm
pip install llm
+
+# If API keys are required, store them in ~/.config/aidevops/mcp-env.sh (600 perms)
+# Avoid placing secrets in repos or working directories.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## LLM Commit Messages | |
| Worktrunk integrates with [llm](https://llm.datasette.io/) for AI-generated commit messages: | |
| ```bash | |
| # Install llm | |
| pip install llm | |
| # Configure (uses your default LLM) | |
| wt config set llm_commits true | |
| # Now commits auto-generate messages from diffs | |
| git add . | |
| wt commit # Generates message via LLM | |
| ``` | |
| ## LLM Commit Messages | |
| Worktrunk integrates with [llm](https://llm.datasette.io/) for AI-generated commit messages: | |
🤖 Prompt for AI Agents
In @.agent/tools/git/worktrunk.md around lines 168 - 182, Update the "LLM Commit
Messages" section to include a short security note instructing developers to
store llm API keys in the project-standard credentials file
(~/.config/aidevops/mcp-env.sh) and reference any environment variable names
used by llm; mention this applies when enabling llm commits (e.g., wt config set
llm_commits true) and give a one-line reminder to keep the file permissions
restricted.
| Shell integration not installed: | ||
| ```bash | ||
| wt config shell install | ||
| source ~/.zshrc # or ~/.bashrc | ||
| ``` |
There was a problem hiding this comment.
Fix markdownlint MD031 (blank lines around fences).
Add blank lines before/after the fenced blocks in Troubleshooting to keep linting clean.
🧹 Proposed fix
Shell integration not installed:
+
```bash
wt config shell install
source ~/.zshrc # or ~/.bashrc"Branch already checked out"
@@
Each branch can only be in one worktree:
+
wt list # Find where branch is checked out
wt remove feature/auth # Remove if not needed@@
On Windows, wt is aliased to Windows Terminal. Use git-wt instead:
+
git-wt switch feature/auth</details>
Also applies to: 243-247, 251-254
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.18.1)</summary>
236-236: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
In @.agent/tools/git/worktrunk.md around lines 235 - 239, Add a blank line both
immediately before and immediately after each fenced code block in the
Troubleshooting sections (e.g., the block under the "Shell integration not
installed:" paragraph containing "wt config shell install" / "source ~/.zshrc",
the block under the "Branch already checked out" section with "wt list" / "wt
remove feature/auth", and the Windows note with "git-wt switch feature/auth") so
that each ```bash fence is separated by a blank line from surrounding text to
satisfy markdownlint MD031.
</details>
<!-- fingerprinting:phantom:poseidon:eagle -->
<!-- This is an auto-generated comment by CodeRabbit -->
| # Check if shell integration is installed | ||
| local shell_name | ||
| shell_name=$(basename "${SHELL:-/bin/bash}") | ||
| local shell_rc="" | ||
| case "$shell_name" in | ||
| zsh) shell_rc="$HOME/.zshrc" ;; | ||
| bash) | ||
| if [[ "$(uname)" == "Darwin" ]]; then | ||
| shell_rc="$HOME/.bash_profile" | ||
| else | ||
| shell_rc="$HOME/.bashrc" | ||
| fi | ||
| ;; | ||
| esac | ||
|
|
||
| if [[ -n "$shell_rc" ]] && [[ -f "$shell_rc" ]]; then | ||
| if ! grep -q "worktrunk" "$shell_rc" 2>/dev/null; then | ||
| print_info "Shell integration not detected" | ||
| read -r -p "Install Worktrunk shell integration (enables 'wt switch' to change directories)? (y/n): " install_shell | ||
| if [[ "$install_shell" == "y" ]]; then | ||
| if wt config shell install 2>/dev/null; then | ||
| print_success "Shell integration installed" | ||
| print_info "Restart your terminal or run: source $shell_rc" | ||
| else | ||
| print_warning "Shell integration failed - run manually: wt config shell install" | ||
| fi | ||
| fi | ||
| else | ||
| print_success "Shell integration already configured" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Worktrunk wt config shell install marker documentation
💡 Result:
Summary — shell integration and branch markers for Worktrunk (wt)
-
Install shell integration (enables wt switch to cd):
wt config shell install
or run wt config shell init <bash|zsh|fish|...> and add the printed eval/source line to your shell rc. [1][3] -
Files changed by install:
Bash: adds to ~/.bashrc
Zsh: adds to ~/.zshrc (or $ZDOTDIR/.zshrc)
Fish: creates ~/.config/fish/conf.d/wt.fish and completions. (Support for many shells listed.) [2][3] -
Uninstall:
wt config shell uninstall (or remove the line/file added). [2] -
Branch "marker" state (custom status text/emoji shown in wt list):
Commands: wt config state marker get|set|clear (use --branch to target others).
Markers are stored in git config as worktrunk.state..marker (also accessible via wt config state commands). Example: git config worktrunk.state.feature.marker '{"marker":"🚧","set_at":0}'. [1]
Sources: Worktrunk config & state docs; FAQ; crate docs. [1][2][3]
References
[1] https://worktrunk.dev/config/
[2] https://worktrunk.dev/faq/
[3] https://docs.rs/crate/worktrunk/0.1.1
🌐 Web query:
Worktrunk shell integration status check command
💡 Result:
There isn’t a single built-in “shell integration status” command. Use the init output + a quick grep to check your shell config. For example (Bash):
-
Print the snippet Worktrunk would add:
wt config shell init bash. [1] -
Check your rc file for that snippet:
grep -F 'wt init' ~/.bashrc
Or for Zsh:
- wt config shell init zsh
- grep -F 'wt init' ~/.zshrc
You can (un)install with:
- wt config shell install
- wt config shell uninstall. [1][2]
Sources: Worktrunk config and FAQ. [1][2]
References
[1] wt config — Worktrunk docs.
[2] Worktrunk FAQ — Shell integration.
🏁 Script executed:
grep -n "worktrunk\|wt init\|wt config shell" setup.sh | head -20Repository: marcusquinn/aidevops
Length of output: 1501
🏁 Script executed:
# Check if there's any documentation or marker string definition in setup.sh
grep -B5 -A5 "grep -q.*worktrunk" setup.shRepository: marcusquinn/aidevops
Length of output: 632
Fix shell integration detection to use the correct marker pattern.
The grep pattern "worktrunk" does not match the actual marker that wt config shell install adds to shell rc files. According to Worktrunk documentation, the correct marker to check for is "wt init". This causes the detection to fail, re-prompting users even after successful installation. Change line 591 to:
if ! grep -q "wt init" "$shell_rc" 2>/dev/null; then
Also apply the same fix to the equivalent checks at lines 632 and 664.
🤖 Prompt for AI Agents
In `@setup.sh` around lines 575 - 603, The shell integration detection is using
the wrong marker "worktrunk" so it fails to recognize installed integration;
update the grep checks that reference the shell rc detection (the condition that
inspects "$shell_rc" and the other equivalent checks) to look for the actual
marker "wt init" instead, so change the grep pattern used in the conditional
that guards shell integration prompting (the block around shell_rc and the other
two equivalent checks) to grep -q "wt init" "$shell_rc" 2>/dev/null; keep the
rest of the flow (print_info, wt config shell install call, and success/warning
messages) unchanged.
1 participant
Summary
wt) as the recommended git worktree management toolworktree-helper.shas a dependency-free fallbackChanges
setup.sh
setup_worktrunk()function that:cdsupporttool-version-check.sh
New: tools/git/worktrunk.md
workflows/worktree.md
.agent/AGENTS.md
AGENTS.md (root)
Why Worktrunk?
wt)wt list)wt merge(squash/rebase)Testing
./setup.sh --interactive- verify worktrunk setup step appearswt --versionafter installwt config shell installfor shell integrationSummary by CodeRabbit
Release Notes
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.