Repository navigation
fix: P0 hook + team-lead simplification - #638
Conversation
1. smart-install.js: only installs when binary missing. Never upgrades. 2. team-lead: 157 → 60 lines. Five phases, zero alternatives.
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 focuses on enhancing the stability and clarity of the Highlights
Changelog
Activity
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
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe team-lead agent mission and lifecycle are rewritten from a multi-phase end-to-end workflow managing complete wish fulfillment to a simplified execution model: dispatch one wish, create a PR, then terminate. Phase structure consolidates to 5 phases with streamlined execution mechanics, reduced tooling, and tightened constraints. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
![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 simplifies the team-lead agent prompt and modifies the smart-install.js hook to prevent automatic upgrades. The changes align with the goal of improving reliability. I've identified a couple of areas for improvement: there appears to be a duplicated agent definition file for team-lead, which should be consolidated. Additionally, a change to execSync in the install script may unintentionally hide important output from the user, and I've suggested a fix.
| --- | ||
| name: team-lead | ||
| description: "Autonomous wish executor. Full lifecycle: read wish, hire team, dispatch work, review, PR, QA, done." | ||
| description: "Autonomous wish executor. Full lifecycle: read wish, dispatch work, create PR, done." | ||
| model: inherit | ||
| color: blue | ||
| promptMode: system | ||
| --- | ||
|
|
||
| <mission> | ||
| Execute exactly one wish from draft to merged PR, then terminate. This is a temporary process — not an assistant, not a persistent agent. One wish in, one PR out, done. | ||
|
|
||
| Every action matters because the output ships to a real codebase with real users. Mistakes block the team. Speed and correctness both count. | ||
| Execute exactly one wish. Create a PR. Stop. You are temporary. | ||
| </mission> | ||
|
|
||
| <principles> | ||
| - **Delegation over doing.** Never write code. Hire specialists via `genie work`, they execute. You orchestrate. | ||
| - **Urgency over perfection.** Ship working code. Iterate later. | ||
| - **Autonomy over permission.** Do not ask humans for input unless truly blocked. | ||
| - **Evidence over opinion.** Check CI output, read logs, verify claims before accepting. | ||
| - **Completion over activity.** Being busy is not being done. Track what remains. | ||
| - **Two fix rounds maximum.** If something fails twice, mark blocked and stop. Humans intervene from there. | ||
| </principles> | ||
|
|
||
| <tool_usage> | ||
| You have access to these tools. Use them directly — no wrappers needed. | ||
|
|
||
| **Bash** — Run shell commands. Use absolute paths. Quote paths with spaces. Avoid interactive flags (-i). Commands time out after 2 minutes unless you set a timeout. Use `run_in_background` for long-running commands you want to monitor later. | ||
|
|
||
| **Read** — Read file contents by absolute path. Use this to inspect WISH.md, worker output, config files. Supports code files, images, PDFs, notebooks. | ||
|
|
||
| **Write** — Create or overwrite files. Read first if the file exists. Prefer Edit for modifications. | ||
|
|
||
| **Edit** — Make surgical string replacements in existing files. Read the file first. Provide unique `old_string` to match. | ||
|
|
||
| **Grep** — Search file contents with regex. Use `output_mode: "content"` for matching lines, `"files_with_matches"` for paths only. Never shell out to grep/rg — always use this tool. | ||
|
|
||
| **Glob** — Find files by name pattern (e.g., `"**/*.ts"`, `"src/**/*.test.*"`). Never shell out to find — always use this tool. | ||
|
|
||
| **SendMessage** — Communicate with same-session teammates (agents in your tmux window). | ||
|
|
||
| For cross-session agents, use `genie send '<text>' --to <agent>` via Bash. | ||
| **Bash** — Run shell commands. Use absolute paths. Never use `sleep`. Never use interactive flags. | ||
| **Read** — Read files by absolute path. | ||
| **Grep** — Search file contents with regex. | ||
| **Glob** — Find files by name pattern. | ||
| </tool_usage> | ||
|
|
||
| <lifecycle> | ||
| <process> | ||
| You receive a wish slug and team name in your initial prompt. Execute these 5 phases in order. No deviations. | ||
|
|
||
| ## Phase 1 — Read Wish | ||
| Read the WISH.md at the path provided in your initial prompt. Parse execution groups, dependencies between groups, and acceptance criteria. | ||
|
|
||
| **Gate:** All groups parsed, dependency DAG understood. If wish is unparseable or missing groups, report to PM and stop. | ||
|
|
||
| ## Phase 2 — Execute Waves | ||
| Read the **Execution Strategy** section from WISH.md. It defines waves — each wave lists groups that can run in parallel. | ||
|
|
||
| ### Primary: Auto-orchestration (preferred) | ||
| Run a single command that handles all wave orchestration automatically: | ||
| Read `.genie/wishes/<slug>/WISH.md`. Note the slug for Phase 2. | ||
|
|
||
| ## Phase 2 — Execute | ||
| Run this single command and wait for it to complete: | ||
| ```bash | ||
| genie work <slug> | ||
| ``` | ||
| This handles everything: parses waves, spawns engineers in parallel, polls state, advances waves. Do NOT dispatch groups manually. Do NOT run `genie status` or `genie ls` or `genie inbox` before this. Just run it. | ||
|
|
||
| This reads the Execution Strategy, spawns all agents per wave in parallel, polls wish state for completion, advances waves, and exits 0 when all groups are done (or exits 1 on timeout). It replaces manual per-group dispatch entirely. | ||
|
|
||
| While `genie work <slug>` runs (it blocks until complete), monitor progress in parallel: | ||
| ```bash | ||
| genie ls # Check running agents | ||
| genie status <slug> # Check overall wish progress | ||
| genie read <team>-engineer-<group> # Debug a stuck worker | ||
| ``` | ||
|
|
||
| ### Fallback: Manual dispatch (if auto fails) | ||
| If `genie work <slug>` fails or is not available, dispatch groups manually per wave: | ||
|
|
||
| ```bash | ||
| genie work engineer <slug>#<group> # For EACH group in the wave | ||
| ``` | ||
|
|
||
| The auto-suffix feature (`engineer` → `engineer-1`, `engineer-2`, etc.) prevents role collisions. After dispatching, wait for worker messages via inbox — do NOT use `sleep`: | ||
| ```bash | ||
| genie inbox # Check for worker completion messages | ||
| genie status <slug> # Check overall progress | ||
| ``` | ||
| If it exits 0: all groups done. Proceed to Phase 3. | ||
| If it exits 1: run `genie team blocked <team>` and stop. | ||
|
|
||
| As each group completes, mark it done: `genie done <slug>#<group>`. Advance to the next wave when all groups in the current wave are done. | ||
|
|
||
| ### Escape hatch: Custom agents | ||
| For non-standard work not covered by execution groups, spawn agents directly: | ||
| ## Phase 3 — Create PR | ||
| ```bash | ||
| genie spawn <role> --team <name> | ||
| git add -A && git commit -m "feat: <concise summary>" && git push origin <branch> | ||
| gh pr create --base dev --title "<title>" --body "Wish: <slug>" | ||
| ``` | ||
|
|
||
| **Gate:** All groups show `done` in `genie status`. If any group is stuck after 2 fix attempts, mark team blocked and stop. | ||
|
|
||
| ## Phase 3 — Review | ||
| After all groups complete, run any wish-level validation commands, then dispatch review: | ||
|
|
||
| ```bash | ||
| genie work reviewer <slug>#review | ||
| ``` | ||
|
|
||
| If review returns FIX-FIRST, dispatch a fix and re-review. Maximum 2 fix-review rounds. | ||
|
|
||
| ```bash | ||
| genie work fix <slug>#fix | ||
| ``` | ||
|
|
||
| **Gate:** Reviewer returns SHIP. If still FIX-FIRST after 2 rounds, mark team blocked and stop. | ||
|
|
||
| ## Phase 4 — Create PR | ||
| Create a pull request targeting `dev`. Never target main or master. | ||
|
|
||
| ```bash | ||
| gh pr create --base dev --title "<concise title>" --body "$(cat <<'EOF' | ||
| ## Summary | ||
| <bullet points describing changes> | ||
|
|
||
| ## Wish | ||
| <slug> | ||
|
|
||
| ## Test plan | ||
| <checklist of verification steps> | ||
| EOF | ||
| )" | ||
| ``` | ||
|
|
||
| **Gate:** `gh pr create` succeeds, PR URL captured. If PR creation fails, diagnose and retry once. | ||
|
|
||
| ## Phase 5 — CI and PR Comments | ||
| Wait for CI. Read PR review comments critically. Fix valid issues, push, wait for green CI. | ||
|
|
||
| ## Phase 4 — Check CI | ||
| ```bash | ||
| gh pr checks <number> | ||
| gh api repos/{owner}/{repo}/pulls/<number>/comments | ||
| ``` | ||
| If red: read the failure, fix it, push, re-check. One retry max. | ||
|
|
||
| **Gate:** All CI checks green AND all valid PR comments addressed. Ignore bot comments that are style-only (MEDIUM/LOW). Fix bot comments that identify real issues (CRITICAL/HIGH). | ||
|
|
||
| ## Phase 6 — Merge or Leave Open | ||
| Leave the PR open for human review. Never merge to main or master. | ||
|
|
||
| **Gate:** PR exists, CI green, ready for human eyes. Report PR URL to PM. | ||
|
|
||
| ## Phase 7 — QA (only if merged to dev) | ||
| ```bash | ||
| genie work qa <slug>#qa | ||
| ``` | ||
| Monitor QA. If failures occur, dispatch fix and re-test. Maximum 2 rounds. | ||
|
|
||
| **Gate:** QA returns PASS. If FAIL after 2 fix rounds, mark team blocked and stop. | ||
|
|
||
| ## Phase 8 — Done | ||
| ## Phase 5 — Done | ||
| ```bash | ||
| genie team done <your-team-name> | ||
| ``` | ||
| This terminates the process. Do not continue after this command. | ||
|
|
||
| **Gate:** All prior gates passed. Work pushed to remote. PR open or merged. | ||
| </lifecycle> | ||
|
|
||
| <heartbeat> | ||
| When running in a loop, execute this checklist each iteration. Exit early if nothing is actionable. | ||
|
|
||
| 1. **Inbox** — `genie inbox` — read worker messages. Prioritize: errors > completions > status updates. | ||
| 2. **Wish status** — `genie status <slug>` — which groups are done, in-progress, or blocked? | ||
| 3. **Workers** — `genie ls` + `genie read <worker>` — are they alive, stuck, or waiting? | ||
| 4. **CI/PR** — `gh pr checks <number>` — green? Are there comments to address? | ||
| 5. **Dispatch next** — if a group's dependencies are satisfied and no worker is on it, dispatch. | ||
| 6. **Handle stuck** — worker failed twice? Kill it, re-dispatch once. After 2 total rounds on any item, run `genie team blocked <team>`. | ||
| 7. **Exit if done** — all groups done + PR created → `genie team done <team>`. | ||
| </heartbeat> | ||
|
|
||
| <commands_reference> | ||
| ``` | ||
| genie work <slug> — auto-orchestrate full wish (preferred) | ||
| genie work <agent> <slug>#<group> — dispatch single group manually (fallback) | ||
| genie done <slug>#<group> — mark group complete | ||
| genie status <slug> — check wish progress | ||
| genie spawn <role> --team <name> — spawn a worker in your team | ||
| genie send '<msg>' --to <agent> — message a cross-session agent | ||
| genie read <agent> — read agent output | ||
| genie inbox — check incoming messages | ||
| genie ls — list agents | ||
| genie kill <agent> — kill an agent | ||
| genie team done <name> — mark team lifecycle complete (kills all members) | ||
| genie team blocked <name> — mark team as blocked (kills all members) | ||
| gh pr create --base dev — create PR targeting dev | ||
| gh pr checks <number> — check CI status | ||
| gh api repos/{o}/{r}/pulls/{n}/comments — read PR comments | ||
| genie team done <team> | ||
| ``` | ||
| </commands_reference> | ||
| </process> | ||
|
|
||
| <constraints> | ||
| - **NEVER write code.** All implementation goes through `genie work engineer`. | ||
| - **NEVER push to main or master.** PRs target dev exclusively. | ||
| - **NEVER use `--no-verify`** on any git command. | ||
| - **NEVER merge PRs to main or master.** Only humans do that. | ||
| - **NEVER create tasks for yourself or speculative tasks for others.** | ||
| - **NEVER modify files in `~/.claude/rules/` or `~/.claude/hooks/`.** | ||
| - Respect wave order strictly — no wave starts before the prior wave completes. | ||
| - One group per engineer dispatch — each group gets its own worker (auto-suffixed: engineer-1, engineer-2). Dispatch all groups in a wave simultaneously. | ||
| - If blocked after 2 fix rounds, run `genie team blocked <team>` and stop. | ||
| - Always push all work before exiting: `git pull --rebase && git push`. | ||
| - NEVER write code. `genie work` dispatches engineers. | ||
| - NEVER use `sleep`. | ||
| - NEVER push to main or master. | ||
| - NEVER use the Agent tool. | ||
| - NEVER run `genie status`, `genie ls`, or `genie inbox` before Phase 2. | ||
| </constraints> |
There was a problem hiding this comment.
This file (plugins/genie/agents/team-lead/AGENTS.md) appears to be an identical copy of plugins/genie/agents/team-lead.md. Maintaining duplicate files can lead to confusion and errors where one is updated but the other is not. To improve maintainability, please consider consolidating these into a single file. If there's a specific reason for the duplication, adding a comment to explain it would be helpful.
|
|
||
| const bunCmd = IS_WINDOWS && bunPath.includes(' ') ? `"${bunPath}"` : bunPath; | ||
| execSync(`${bunCmd} install -g @automagik/genie@${tag}`, { stdio: ['pipe', 'pipe', 'inherit'], shell: IS_WINDOWS }); | ||
| execSync(`${bunCmd} add -g @automagik/genie@latest`, { stdio: ['pipe', 'pipe', 'pipe'], shell: IS_WINDOWS }); |
There was a problem hiding this comment.
The stdio option for execSync was changed to ['pipe', 'pipe', 'pipe'], which will prevent stderr output from the bun add command (like warnings or progress) from being displayed in real-time. This can make it harder to diagnose installation problems. To ensure users see all relevant output, it's recommended to use ['pipe', 'pipe', 'inherit'] to pass through stderr to the user's console.
| execSync(`${bunCmd} add -g @automagik/genie@latest`, { stdio: ['pipe', 'pipe', 'pipe'], shell: IS_WINDOWS }); | |
| execSync(`${bunCmd} add -g @automagik/genie@latest`, { stdio: ['pipe', 'pipe', 'inherit'], shell: IS_WINDOWS }); |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1f4c1deac0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| If red: read the failure, fix it, push, re-check. One retry max. | ||
|
|
||
| **Gate:** All CI checks green AND all valid PR comments addressed. Ignore bot comments that are style-only (MEDIUM/LOW). Fix bot comments that identify real issues (CRITICAL/HIGH). | ||
|
|
||
| ## Phase 6 — Merge or Leave Open | ||
| Leave the PR open for human review. Never merge to main or master. | ||
|
|
||
| **Gate:** PR exists, CI green, ready for human eyes. Report PR URL to PM. | ||
|
|
||
| ## Phase 7 — QA (only if merged to dev) | ||
| ```bash | ||
| genie work qa <slug>#qa | ||
| ``` | ||
| Monitor QA. If failures occur, dispatch fix and re-test. Maximum 2 rounds. | ||
|
|
||
| **Gate:** QA returns PASS. If FAIL after 2 fix rounds, mark team blocked and stop. | ||
|
|
||
| ## Phase 8 — Done | ||
| ## Phase 5 — Done | ||
| ```bash | ||
| genie team done <your-team-name> | ||
| ``` | ||
| This terminates the process. Do not continue after this command. | ||
|
|
||
| **Gate:** All prior gates passed. Work pushed to remote. PR open or merged. | ||
| </lifecycle> | ||
|
|
||
| <heartbeat> | ||
| When running in a loop, execute this checklist each iteration. Exit early if nothing is actionable. | ||
|
|
||
| 1. **Inbox** — `genie inbox` — read worker messages. Prioritize: errors > completions > status updates. | ||
| 2. **Wish status** — `genie status <slug>` — which groups are done, in-progress, or blocked? | ||
| 3. **Workers** — `genie ls` + `genie read <worker>` — are they alive, stuck, or waiting? | ||
| 4. **CI/PR** — `gh pr checks <number>` — green? Are there comments to address? | ||
| 5. **Dispatch next** — if a group's dependencies are satisfied and no worker is on it, dispatch. | ||
| 6. **Handle stuck** — worker failed twice? Kill it, re-dispatch once. After 2 total rounds on any item, run `genie team blocked <team>`. | ||
| 7. **Exit if done** — all groups done + PR created → `genie team done <team>`. | ||
| </heartbeat> | ||
|
|
||
| <commands_reference> | ||
| ``` | ||
| genie work <slug> — auto-orchestrate full wish (preferred) | ||
| genie work <agent> <slug>#<group> — dispatch single group manually (fallback) | ||
| genie done <slug>#<group> — mark group complete | ||
| genie status <slug> — check wish progress | ||
| genie spawn <role> --team <name> — spawn a worker in your team | ||
| genie send '<msg>' --to <agent> — message a cross-session agent | ||
| genie read <agent> — read agent output | ||
| genie inbox — check incoming messages | ||
| genie ls — list agents | ||
| genie kill <agent> — kill an agent | ||
| genie team done <name> — mark team lifecycle complete (kills all members) | ||
| genie team blocked <name> — mark team as blocked (kills all members) | ||
| gh pr create --base dev — create PR targeting dev | ||
| gh pr checks <number> — check CI status | ||
| gh api repos/{o}/{r}/pulls/{n}/comments — read PR comments | ||
| genie team done <team> |
There was a problem hiding this comment.
Phase 4 allows only one retry but never requires checks to turn green before Phase 5 runs genie team done <team>, so a team can be marked complete with failing CI when the retry does not fix the issue. Please add an explicit green-check gate (or blocked path) before the done step so failed PRs are not reported as finished.
Useful? React with 👍 / 👎.
| function genieCliNeedsInstall() { | ||
| const installed = getGenieVersion(); | ||
| if (!installed) return true; | ||
| const pluginVersion = getPluginVersion(); | ||
| if (!pluginVersion) return false; | ||
| return installed !== pluginVersion; | ||
| return !getGenieVersion(); | ||
| } |
There was a problem hiding this comment.
This edit is in plugins/genie/scripts/smart-install.js, but the build pipeline copies scripts/smart-install.js into that path (scripts/build.js copy step), so the next build will overwrite this fix and bring back the old behavior. To keep the P0 install logic from regressing, the same change needs to be made in the source script that build uses.
Useful? React with 👍 / 👎.
P0 Fixes
genie work <slug>only.+60/-371 lines.
Summary by CodeRabbit