Conversation
Summary of ChangesHello, 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 introduces a new agent skill designed to systematically and safely clean up local development virtual machines. The primary goal is to address common issues like orphaned processes, stale development servers, and unused git worktrees that can accumulate over time, ensuring a cleaner and more efficient development environment without disrupting active work. The skill is designed with a strong emphasis on safety and requires explicit user command to prevent unintended data loss or interruption. 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. Footnotes
|
![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 a new clean-vm skill, providing comprehensive guidelines and safety rules for cleaning up stale local development environments. This includes identifying and removing inactive loop runs, agent processes, Next.js/Storybook servers, browser windows, and git worktrees. Feedback from the review suggests improving the find command's maxdepth for better efficiency and refining a grep pattern to prevent false positives when identifying processes.
| ```bash | ||
| tmux ls 2>/dev/null | ||
| tmux list-panes -a -F '#{session_name} #{pane_dead} #{pane_current_command} #{pane_current_path}' 2>/dev/null | ||
| find ~/.loop/runs -maxdepth 5 -name manifest.json 2>/dev/null |
There was a problem hiding this comment.
The -maxdepth for find seems too large. Based on the project structure in src/loop/run-state.ts, manifests are located at ~/.loop/runs/<repoId>/<runId>/manifest.json. When searching from ~/.loop/runs, the manifest files are at depth 3 relative to the starting directory. A maxdepth of 3 would be more precise and efficient.
| find ~/.loop/runs -maxdepth 5 -name manifest.json 2>/dev/null | |
| find ~/.loop/runs -maxdepth 3 -name manifest.json 2>/dev/null |
| Inspect listening processes and map them back to a cwd before killing them. | ||
|
|
||
| ```bash | ||
| lsof -nP -iTCP -sTCP:LISTEN | grep -E 'node|next|storybook' |
There was a problem hiding this comment.
The grep pattern node is a bit broad and could match other command names containing "node" (e.g., anode). Using the -w flag with grep would make the match more specific to the node command itself, reducing potential false positives during the detection phase.
| lsof -nP -iTCP -sTCP:LISTEN | grep -E 'node|next|storybook' | |
| lsof -nP -iTCP -sTCP:LISTEN | grep -w -E 'node|next|storybook' |
1 participant
Summary
Verification