chore: rolling promotion dev -> main#564
Merged
Merged
Conversation
Contributor
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 represents an automated rolling promotion from the 'dev' branch to 'main'. Its primary purpose is to propagate the latest 'genie' plugin version ('3.260314.9') to the main branch, ensuring that the production environment receives the most recent stable updates. This process is designed to be largely automated, with human approval required for the final merge to production. 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
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughBumps plugin/package versions to 3.260315.1, adds a new built-in "leader" role, introduces persistent team status (in_progress/done/blocked) with CLI commands to set it, expands many SKILL docs (templates, auto-invocations, state/team flows), rewrites install/orchestration doc, and removes the onboarding SKILL.md. Changes
Sequence Diagram(s)sequenceDiagram
participant User as User
participant CLI as "genie CLI"
participant Leader as "Leader (built-in role)"
participant Worker as "Worker Agent(s)"
participant State as "Team Manager / State Store"
User->>CLI: genie team create / genie spawn (may include wish)
CLI->>Leader: spawn/hire leader (with context)
Leader->>Worker: hire/spawn workers and assign groups
Worker->>Leader: report progress / request review
Leader->>State: update team status (in_progress/done/blocked)
CLI->>State: query status (team ls)
State-->>CLI: return status
CLI->>User: display aggregated status/results
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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}
Contributor
There was a problem hiding this comment.
Code Review
This pull request contains automated version bumps as part of a rolling promotion from the dev branch to main. The version is consistently updated across all relevant JSON configuration files. I have one suggestion to improve the robustness of the automation script responsible for these updates, detailed in a specific comment. Otherwise, the changes are correct.
| { | ||
| "name": "genie", | ||
| "version": "3.260314.8", | ||
| "version": "3.260314.9", |
Contributor
There was a problem hiding this comment.
The versioning script (scripts/version.ts) that generates this change appears to be brittle. It assumes the genie plugin is always the first entry in the plugins array of this file by updating json.plugins[0].
To make it more robust, the script should be updated to locate the plugin by its name before updating the version. For example:
// In scripts/version.ts
const geniePlugin = json.plugins?.find(p => p.name === 'genie');
if (geniePlugin) {
geniePlugin.version = version;
}This will prevent accidental version updates to the wrong plugin if other plugins are added or the order of plugins changes in the future.
…arn+brain Group 1 — Orchestration Rules Rewrite: - Rewrite ORCHESTRATION_PROMPT in smart-install.js and install.sh with current CLI commands (spawn, kill, stop, ls, team create/hire/fire/disband, send, broadcast, chat, done, status, reset) - Add skill auto-invocation chain, team lifecycle, and rules sections - Remove stale genie agent spawn, genie team ensure, genie agent dashboard refs - Both files have identical orchestration content Group 2 — Kill Onboarding + Inline References: - Delete skills/onboarding/ directory entirely - Inline prompt optimizer content into skills/refine/SKILL.md - Inline design template into skills/brainstorm/SKILL.md - Inline wish template into skills/wish/SKILL.md - Remove all references/ file paths from SKILL.md files Group 5 — Learn Rewrite + Brain Update: - Rewrite skills/learn/SKILL.md: primary trigger is user correction, diagnoses which behavioral surface needs change (CLAUDE.md, AGENTS.md, SOUL.md, rules/, memory/, hooks, configs). Remove BOOTSTRAP.md ref. Connect to Claude native memory. - Update skills/brain/SKILL.md: add brain vs memory distinction (brain=context graph, memory=behavioral learnings). Add auto-install: detect notesmd-cli, offer install from https://github.com/Yakitrak/notesmd-cli
Group 3 — Core Chain Skills: - brainstorm: remove genie brainstorm crystallize, auto-invoke /review at WRS=100, suggest /council when Decisions stuck after 2+ exchanges - wish: fuzzy gate check auto-triggers /brainstorm, step 7 declares depends-on, handoff auto-invokes /review instead of suggesting /work - work: clarify as implementor skill via genie work dispatch, add local /review per group, genie send signaling, leader uses genie done (not worker), remove "no state management" confusion - review: add SHIP next-steps per context (plan→wish/work, execution→PR, PR→merge), auto-invoke /fix on FIX-FIRST, /trace for unclear root cause Group 4 — Support Skills: - council: add auto-invocation triggers (review arch decisions, brainstorm stuck decisions), document genie team hire council, add 2min timeout for full spawn, clarify lightweight=simulate vs full spawn=real agents - trace: add genie send for reporting findings, clarify spawned agent IS the tracer, /review can invoke /trace - report: document agent-browser as genie dependency, add wish criteria linking during QA, add QA failure auto-invocation chain - docs: add doc types (README, CLAUDE.md, API, architecture, JSDoc), CLAUDE.md as first-class surface, post-work suggestion - refine: verified inlined content, no remaining references/ paths Group 6 — Dream Lifecycle: - Phase 1: use genie work dispatch per group (state tracking for free), genie status/done/reset for monitoring - Phase 2: leader creates PR, reads bot comments critically, /fix valid issues, CI green required (poll, don't sleep) - Phase 3: merge to dev, spawn tester, QA loop until all criteria proven, each fix = new PR to dev - Phase 4: DREAM-REPORT.md with per-wish QA status - Remove Status: SHIPPED and sleep 5 references - Add full team lifecycle: create→execute→review→merge→QA→disband
- Change genie agent history/read/answer to genie history/read/answer (top-level commands, not under agent namespace) in both install.sh and smart-install.js - Fix escaped backticks in wish SKILL.md template (remove backslashes) - Add --repo <path> to genie team create in both orchestration prompts (--repo is required)
fix(skills): refresh all skills + orchestration rules rewrite
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
install.sh (1)
857-857:⚠️ Potential issue | 🟡 MinorDrop the removed
/onboardingrecommendation.The PR removes the onboarding skill, but both success paths still tell first-time users Genie will suggest
/onboarding. After merge, that points users at a nonexistent skill.Also applies to: 1126-1126
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@install.sh` at line 857, Update the user-facing message that still references the removed "/onboarding" skill: find the string "First time? Genie will suggest /onboarding to set up your workspace." (and the duplicate at the other location) in install.sh and remove or replace the "/onboarding" recommendation with an existing alternative (e.g., a generic "check /help" or "visit the onboarding page in settings") so the message doesn't point to a nonexistent skill.skills/council/SKILL.md (1)
61-64:⚠️ Potential issue | 🟠 MajorUse the documented
genie chatsyntax here.
src/term-commands/msg.ts:1-50documentsgenie chat '<msg>' [--team <name>]andgenie chat read .... There is nochat postform in the referenced CLI, so this step can direct agents to a nonexistent command.Suggested fix
- genie chat post --team <team> "COUNCIL TOPIC: <topic>\n\nContext: <relevant context>\n\nPlease review and vote: APPROVE, REJECT, or MODIFY with rationale." + genie chat "COUNCIL TOPIC: <topic>\n\nContext: <relevant context>\n\nPlease review and vote: APPROVE, REJECT, or MODIFY with rationale." --team <team>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@skills/council/SKILL.md` around lines 61 - 64, The example in SKILL.md uses a nonexistent `genie chat post --team ...` form; update the command to the documented CLI syntax from src/term-commands/msg.ts (see genie chat '<msg>' [--team <name>] and genie chat read) by replacing the example with the single-argument form and the team flag (e.g., use genie chat '<message>' --team <team>), ensuring the message content matches the original "COUNCIL TOPIC: <topic>..." text and keeping the --team flag for targeting the team.
♻️ Duplicate comments (1)
skills/dream/SKILL.md (1)
86-100:⚠️ Potential issue | 🟠 MajorWorker Contract conflicts with /work's orchestration model.
This Worker Contract describes autonomous workers that self-execute: read WISH.md, refine, implement, review, CI, PR, and report. But skills/work/SKILL.md lines 60-65 describe an orchestration model where the /work skill IS the orchestrator that dispatches subagents and manages state.
The conflict is the same as noted in the /work review: these are two different execution models. If
genie work <agent> <slug>#<group>dispatches a worker, does that worker:
- Run the /work orchestration flow (which then dispatches sub-subagents)?
- Execute the task directly as an implementor (bypassing /work's orchestration)?
The Worker Contract here (lines 86-100) reads like autonomous implementors, but /work reads like an orchestrator. Reconcile these contracts or clarify the layering.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@skills/dream/SKILL.md` around lines 86 - 100, The Worker Contract currently describes autonomous implementors (reading WISH.md, running /refine, creating PRs, reporting via genie send) which conflicts with the orchestration model in /work; reconcile by explicitly choosing one layering and updating the contract: either (A) make workers lightweight implementors that only perform execution groups dispatched by /work (remove steps for orchestration: checkout/CI/retry/gh pr create/genie send and instead state they accept tasks from /work and return results/status to /work), or (B) declare workers as full autonomous agents (keep WISH.md, /refine, /review, CI, gh pr create, genie send) and update /work to be a dispatcher that does not duplicate orchestration; reference the Worker Contract section, the /work orchestration description, and the genie work <agent> <slug>#<group> invocation so the text clarifies whether a dispatched worker should run the /work flow or only implement a group and report back.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@install.sh`:
- Around line 689-696: The install.sh help text incorrectly documents "genie
chat" as an interactive 1:1 chat; update the Messaging section so "genie chat"
is documented as team chat and include the read subcommand: change the "genie
chat [args...]" line to show "genie chat '<text>' [--team <name>]" (post to team
chat channel) and add "genie chat read [--team <name>] [--since <ts>]" (read
team channel), and ensure the "genie broadcast" line clarifies it broadcasts to
all team members; this aligns docs with src/term-commands/msg.ts (genie chat
'<msg>' [--team <name>] and genie chat read ...) and makes the /council read
workflow discoverable.
In `@skills/refine/SKILL.md`:
- Line 18: Delete the now-unused prompt-optimizer reference file
(plugins/genie/references/prompt-optimizer.md) from the repo since its content
has been inlined into skills/refine/SKILL.md; ensure no other components import
or reference prompt-optimizer.md and remove the file from the repository and any
build/package lists to avoid confusion.
In `@skills/report/SKILL.md`:
- Around line 17-20: The Dependencies entry referencing "Phase 3" is a forward
reference; update the bullet for the literal string "- **`agent-browser`**" to
remove the phase number and instead state that agent-browser is required for
browser-based evidence capture (screenshots, console logs, network requests) and
that it must be on PATH for later phases to work or that Phase 3 uses it—e.g.,
rephrase to "required for browser-based evidence capture...; must be on PATH for
browser evidence capture to work" so the document no longer refers to an
undefined "Phase 3".
- Around line 21-32: Phase 5 (Compile Report) currently lacks a placeholder to
include wish acceptance-criteria mappings; add a new section between "Actual
Behavior" and "Root Cause Analysis" titled something like "Linked Acceptance
Criteria" (or "Criterion: ...") and update the Phase 5 report template so each
QA failure entry includes the criterion text and status (e.g., Criterion:
"<criterion text>" — FAIL); ensure the doc references where to source criteria
by reading .genie/wishes/<slug>/WISH.md and map each failure to the specific
criterion in the report output.
- Around line 29-32: Update the QA Loop Integration docs to define how the slug
is passed to /report (e.g., as a required request parameter named "slug" in the
/report API payload, as a context field injected by the orchestrator, or as an
environment variable referenced by the tester) and include an explicit example
of invoking /report (for example: POST /report with JSON { "slug": "<slug>" } or
invocation via .genie/wishes/<slug>/WISH.md). Also document the retest mechanism
that closes the loop: specify who/what triggers retest (e.g., /fix emits a
"retest_requested" event or calls POST /report after successful fix; include the
escalation rule that /fix escalates after 2 failed loops), show the sequence
(e.g., /fix -> emit event or call -> /report) and mention how /work should
reference retest if relevant so the chain QA failure → /report → /trace → /fix →
retest is fully described with concrete invocation examples and the escalation
behavior.
- Around line 21-28: Update the "QA Loop Integration" instructions to explicitly
state which wish-level to map QA failures to: read both the document-level
"Success Criteria" and the execution-group-level "**Acceptance criteria:**" from
.genie/wishes/<slug>/WISH.md, prefer mapping failures to the execution-group
"Acceptance criteria" (which include validation commands) and include the
acceptance criterion text in the report as `Criterion: "<criterion text>" —
FAIL`; if no acceptance criteria exist, fall back to mapping against the
document-level "Success Criteria" and clearly note in the report which level was
used.
In `@skills/trace/SKILL.md`:
- Around line 21-23: The step using the CLI invocation `genie send '<diagnosis
summary>' --to <leader>` must send the complete structured diagnosis (root
cause, evidence, recommended correction, affected scope) in the message body
instead of a short summary; update the instruction for the `genie send` command
so it transmits the full structured report to the leader and preserves the exact
fields required for the subsequent `/fix` handoff.
In `@skills/wish/SKILL.md`:
- Line 49: The markdown example block in SKILL.md uses a triple-backtick outer
fence labeled "```markdown" and contains an inner "```bash" fence which
prematurely closes the outer fence; change the outer fence to a four-backtick
fence (e.g., "````markdown") or otherwise ensure the inner "```bash" is nested
safely so the example renders fully, and apply the same fix to the other
occurrences around the example (the blocks near the current 90-93 and 103 lines)
so all nested code fences use a safe outer fence or are escaped consistently.
- Around line 52-58: The SKILL.md template currently hardcodes a brainstorm
artifact link to DESIGN.md which breaks direct /wish runs; update the template
in SKILL.md to not require or hardcode the brainstorm path (the Slug/Design
fields), e.g., remove or mark the DESIGN.md entry as optional so direct /wish
entries don’t include a broken ../../brainstorms/<slug>/DESIGN.md link; ensure
references to the slug/Design are conditional or replaced with a neutral
placeholder so /wish can proceed without a brainstorm artifact.
- Around line 79-103: The template lacks wish-level dependency fields
(depends-on/blocks/repo slug) and only supports per-group depends-on; update the
SKILL.md template's "Execution Groups" section to include a top-level
"Wish-level dependencies" block (or a "depends-on / blocks / repo" subsection
above the groups) that accepts cross-wish dependency entries and repo/slug
identifiers, and keep per-group "depends-on" for intra-wish ordering; ensure the
new fields use the same YAML-like bullet format as group depends-on so
downstream parsers can pick up wish-level depends-on/blocks and repo/slug
references.
In `@skills/work/SKILL.md`:
- Line 24: The local review step in SKILL.md currently sets "On FIX-FIRST,
dispatch fix subagent (max 2 loops)" while the quality review step sets "max 1
loop", causing inconsistency; update the SKILL.md content by either (A) making
the limits consistent (e.g., change the local review's "max 2 loops" to "max 1
loop" to match the quality review) or (B) add a brief clarifying justification
next to the "max 2 loops" phrase stating why FIX-FIRST needs two loops versus
the quality review's one loop so implementors understand the asymmetry
(mentioning FIX-FIRST and quality review explicitly to locate the text).
---
Outside diff comments:
In `@install.sh`:
- Line 857: Update the user-facing message that still references the removed
"/onboarding" skill: find the string "First time? Genie will suggest /onboarding
to set up your workspace." (and the duplicate at the other location) in
install.sh and remove or replace the "/onboarding" recommendation with an
existing alternative (e.g., a generic "check /help" or "visit the onboarding
page in settings") so the message doesn't point to a nonexistent skill.
In `@skills/council/SKILL.md`:
- Around line 61-64: The example in SKILL.md uses a nonexistent `genie chat post
--team ...` form; update the command to the documented CLI syntax from
src/term-commands/msg.ts (see genie chat '<msg>' [--team <name>] and genie chat
read) by replacing the example with the single-argument form and the team flag
(e.g., use genie chat '<message>' --team <team>), ensuring the message content
matches the original "COUNCIL TOPIC: <topic>..." text and keeping the --team
flag for targeting the team.
---
Duplicate comments:
In `@skills/dream/SKILL.md`:
- Around line 86-100: The Worker Contract currently describes autonomous
implementors (reading WISH.md, running /refine, creating PRs, reporting via
genie send) which conflicts with the orchestration model in /work; reconcile by
explicitly choosing one layering and updating the contract: either (A) make
workers lightweight implementors that only perform execution groups dispatched
by /work (remove steps for orchestration: checkout/CI/retry/gh pr create/genie
send and instead state they accept tasks from /work and return results/status to
/work), or (B) declare workers as full autonomous agents (keep WISH.md, /refine,
/review, CI, gh pr create, genie send) and update /work to be a dispatcher that
does not duplicate orchestration; reference the Worker Contract section, the
/work orchestration description, and the genie work <agent> <slug>#<group>
invocation so the text clarifies whether a dispatched worker should run the
/work flow or only implement a group and report back.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 85b0654c-b415-4216-9956-1efdfe9332d8
⛔ Files ignored due to path filters (1)
plugins/genie/scripts/smart-install.jsis excluded by!plugins/genie/scripts/**
📒 Files selected for processing (14)
install.shskills/brain/SKILL.mdskills/brainstorm/SKILL.mdskills/council/SKILL.mdskills/docs/SKILL.mdskills/dream/SKILL.mdskills/learn/SKILL.mdskills/onboarding/SKILL.mdskills/refine/SKILL.mdskills/report/SKILL.mdskills/review/SKILL.mdskills/trace/SKILL.mdskills/wish/SKILL.mdskills/work/SKILL.md
💤 Files with no reviewable changes (1)
- skills/onboarding/SKILL.md
Comment on lines
689
to
696
| ### Messaging | ||
|
|
||
| ```bash | ||
| # Send message to an agent (ALWAYS use this instead of SendMessage) | ||
| genie send '<text>' --to <agent> # Send to specific agent | ||
| genie inbox <agent> # View agent inbox | ||
| genie inbox <agent> --unread # Unread only | ||
| genie send '<text>' --to <agent> # Send message to agent | ||
| genie broadcast '<text>' # Broadcast to all agents | ||
| genie chat [args...] # Interactive chat with agent | ||
| genie inbox [agent] # View message inbox | ||
| ``` |
There was a problem hiding this comment.
Document genie chat as team chat, not 1:1 chat.
src/term-commands/msg.ts:1-50 defines genie chat '<msg>' [--team <name>] for posting to the team channel and genie chat read ... for reads. The injected prompt currently describes it as “Interactive chat with agent”, which steers agents to the wrong workflow and hides the read path used by /council.
Suggested fix
### Messaging
```bash
genie send '<text>' --to <agent> # Send message to agent
-genie broadcast '<text>' # Broadcast to all agents
-genie chat [args...] # Interactive chat with agent
+genie broadcast '<text>' # Broadcast to all team members
+genie chat '<text>' [--team <name>] # Post to team chat channel
+genie chat read [--team <name>] [--since <ts>] # Read team chat channel
genie inbox [agent] # View message inbox</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against the current code and only fix it if needed.
In @install.sh around lines 689 - 696, The install.sh help text incorrectly
documents "genie chat" as an interactive 1:1 chat; update the Messaging section
so "genie chat" is documented as team chat and include the read subcommand:
change the "genie chat [args...]" line to show "genie chat '' [--team
]" (post to team chat channel) and add "genie chat read [--team ]
[--since ]" (read team channel), and ensure the "genie broadcast" line
clarifies it broadcasts to all team members; this aligns docs with
src/term-commands/msg.ts (genie chat '' [--team ] and genie chat read
...) and makes the /council read workflow discoverable.
</details>
<!-- fingerprinting:phantom:medusa:grasshopper -->
<!-- This is an auto-generated comment by CodeRabbit -->
| 1. **Detect mode:** argument starts with `@` -> file mode; otherwise -> text mode. | ||
| 2. **Read input:** file mode reads the target file; text mode uses the raw argument. | ||
| 3. **Spawn refiner subagent:** system prompt = contents of `references/prompt-optimizer.md`. Send input as the user message. | ||
| 3. **Spawn refiner subagent:** system prompt = the Prompt Optimizer System Prompt below. Send input as the user message. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify if references/prompt-optimizer.md still exists and check for other references to it
fd -t f "prompt-optimizer.md"
# Search for references to this file across the codebase
rg -n "references/prompt-optimizer" --type mdRepository: automagik-dev/genie
Length of output: 107
🏁 Script executed:
#!/bin/bash
# Search for references to prompt-optimizer in ALL file types (not just markdown)
rg -n "prompt-optimizer" --exclude-dir=node_modules --exclude-dir=.git
# Also check the file itself to see what's in it
echo "=== Content of the prompt-optimizer.md file ==="
cat "plugins/genie/references/prompt-optimizer.md" 2>/dev/null || echo "File not readable or not found"Repository: automagik-dev/genie
Length of output: 26470
🏁 Script executed:
#!/bin/bash
# Search for all references to prompt-optimizer in the codebase (all file types)
echo "=== Searching for 'prompt-optimizer' references ==="
rg "prompt-optimizer" -i
echo ""
echo "=== Checking if SKILL.md references the old file path ==="
rg "references/prompt-optimizer" -iRepository: automagik-dev/genie
Length of output: 323
Remove the now-unused plugins/genie/references/prompt-optimizer.md file.
The inlined prompt content (lines 59–77) successfully eliminates the external dependency. However, the original plugins/genie/references/prompt-optimizer.md file still exists in the repository and is not referenced by any component. It should be deleted to avoid confusion and maintain clarity.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/refine/SKILL.md` at line 18, Delete the now-unused prompt-optimizer
reference file (plugins/genie/references/prompt-optimizer.md) from the repo
since its content has been inlined into skills/refine/SKILL.md; ensure no other
components import or reference prompt-optimizer.md and remove the file from the
repository and any build/package lists to avoid confusion.
Comment on lines
+17
to
+20
| ## Dependencies | ||
|
|
||
| - **`agent-browser`** — required for browser-based evidence capture (screenshots, console logs, network requests). Install separately: `agent-browser` must be on PATH for Phase 3 to work. If unavailable, Phase 3 degrades gracefully. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Forward reference to undefined Phase 3.
The Dependencies section references "Phase 3" before it's defined (Phase 3 starts at line 62). Consider rephrasing to avoid the forward reference, e.g., "required for browser-based evidence capture" without mentioning the phase number.
📝 Suggested rewording
-## Dependencies
-
-- **`agent-browser`** — required for browser-based evidence capture (screenshots, console logs, network requests). Install separately: `agent-browser` must be on PATH for Phase 3 to work. If unavailable, Phase 3 degrades gracefully.
+## Dependencies
+
+- **`agent-browser`** — required for browser-based evidence capture (screenshots, console logs, network requests). Install separately: `agent-browser` must be on PATH. If unavailable, browser investigation degrades gracefully.📝 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.
Suggested change
| ## Dependencies | |
| - **`agent-browser`** — required for browser-based evidence capture (screenshots, console logs, network requests). Install separately: `agent-browser` must be on PATH for Phase 3 to work. If unavailable, Phase 3 degrades gracefully. | |
| ## Dependencies | |
| - **`agent-browser`** — required for browser-based evidence capture (screenshots, console logs, network requests). Install separately: `agent-browser` must be on PATH. If unavailable, browser investigation degrades gracefully. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/report/SKILL.md` around lines 17 - 20, The Dependencies entry
referencing "Phase 3" is a forward reference; update the bullet for the literal
string "- **`agent-browser`**" to remove the phase number and instead state that
agent-browser is required for browser-based evidence capture (screenshots,
console logs, network requests) and that it must be on PATH for later phases to
work or that Phase 3 uses it—e.g., rephrase to "required for browser-based
evidence capture...; must be on PATH for browser evidence capture to work" so
the document no longer refers to an undefined "Phase 3".
Comment on lines
+21
to
+32
| ## QA Loop Integration | ||
|
|
||
| When invoked during the QA loop (after merge to dev), link findings to wish acceptance criteria: | ||
|
|
||
| 1. Read the wish's success criteria from `.genie/wishes/<slug>/WISH.md`. | ||
| 2. For each QA failure, map it to the specific acceptance criterion it violates. | ||
| 3. Include the criterion reference in the report: `Criterion: "<criterion text>" — FAIL`. | ||
|
|
||
| **Auto-invocation chain for QA failures:** | ||
| ``` | ||
| QA failure → /report (investigate + document) → /trace (root cause) → /fix (correct) → retest | ||
| ``` |
There was a problem hiding this comment.
QA loop integration not reflected in Phase 5.
The QA Loop Integration section describes mapping failures to wish criteria, but Phase 5 (Compile Report, lines 111-169) doesn't show WHERE or HOW to include the criterion reference in the report template. The report template has no placeholder for wish criteria mappings.
🔧 Suggested integration into Phase 5 template
Add a new section to the report template after "Actual Behavior" and before "Root Cause Analysis":
### Actual Behavior
<what happens instead>
+### Wish Criteria Mapping
+<if invoked during QA loop>
+**Wish:** `.genie/wishes/<slug>/WISH.md`
+**Failed criterion:** "<criterion text>" — FAIL
+
### Root Cause Analysis🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/report/SKILL.md` around lines 21 - 32, Phase 5 (Compile Report)
currently lacks a placeholder to include wish acceptance-criteria mappings; add
a new section between "Actual Behavior" and "Root Cause Analysis" titled
something like "Linked Acceptance Criteria" (or "Criterion: ...") and update the
Phase 5 report template so each QA failure entry includes the criterion text and
status (e.g., Criterion: "<criterion text>" — FAIL); ensure the doc references
where to source criteria by reading .genie/wishes/<slug>/WISH.md and map each
failure to the specific criterion in the report output.
Comment on lines
+21
to
+28
| ## QA Loop Integration | ||
|
|
||
| When invoked during the QA loop (after merge to dev), link findings to wish acceptance criteria: | ||
|
|
||
| 1. Read the wish's success criteria from `.genie/wishes/<slug>/WISH.md`. | ||
| 2. For each QA failure, map it to the specific acceptance criterion it violates. | ||
| 3. Include the criterion reference in the report: `Criterion: "<criterion text>" — FAIL`. | ||
|
|
There was a problem hiding this comment.
Clarify which criteria level to map against.
Lines 25-27 mix terminology: "success criteria" (line 25) vs "acceptance criterion" (line 26-27). The wish schema defines TWO distinct levels:
- Success Criteria — document-level checkboxes without validation commands
- Acceptance criteria — execution group-level checkboxes WITH validation commands
Which level should QA failures map to? Both? The mapping procedure needs to specify which criteria structure to use.
Run the following script to examine both criteria structures in existing wish files:
#!/bin/bash
# Description: Show examples of both Success Criteria and Acceptance criteria from wish files
# Find wish files and show both criteria sections
fd -e md WISH.md .genie/wishes -x sh -c '
echo "=== File: {} ==="
echo "--- Success Criteria (document-level) ---"
rg -nA5 "^## Success Criteria" {} || echo "Not found"
echo ""
echo "--- Acceptance criteria (group-level) ---"
rg -nA5 "^\*\*Acceptance criteria:\*\*" {} || echo "Not found"
echo ""
'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/report/SKILL.md` around lines 21 - 28, Update the "QA Loop
Integration" instructions to explicitly state which wish-level to map QA
failures to: read both the document-level "Success Criteria" and the
execution-group-level "**Acceptance criteria:**" from
.genie/wishes/<slug>/WISH.md, prefer mapping failures to the execution-group
"Acceptance criteria" (which include validation commands) and include the
acceptance criterion text in the report as `Criterion: "<criterion text>" —
FAIL`; if no acceptance criteria exist, fall back to mapping against the
document-level "Success Criteria" and clearly note in the report which level was
used.
Comment on lines
+21
to
+23
| 4. **Signal findings:** tracer reports findings back to the leader via `genie send '<diagnosis summary>' --to <leader>`. | ||
| 5. **Receive report:** structured diagnosis with root cause, evidence, recommended correction, and affected scope. | ||
| 6. **Hand off:** pass the report to `/fix` or escalate to the orchestrator. |
There was a problem hiding this comment.
Send the full structured diagnosis, not a summary.
Line 21 currently asks for a summary, but Lines 22-23 require a structured report for /fix. This creates a lossy handoff risk. Update the step to send the complete structured report in the message body.
Proposed doc fix
-4. **Signal findings:** tracer reports findings back to the leader via `genie send '<diagnosis summary>' --to <leader>`.
-5. **Receive report:** structured diagnosis with root cause, evidence, recommended correction, and affected scope.
+4. **Signal findings:** tracer sends the full structured diagnosis to the leader via `genie send '<full diagnosis report>' --to <leader>`.
+5. **Receive report:** leader receives the complete diagnosis (root cause, evidence, causal chain, recommended correction, affected scope, confidence).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/trace/SKILL.md` around lines 21 - 23, The step using the CLI
invocation `genie send '<diagnosis summary>' --to <leader>` must send the
complete structured diagnosis (root cause, evidence, recommended correction,
affected scope) in the message body instead of a short summary; update the
instruction for the `genie send` command so it transmits the full structured
report to the leader and preserves the exact fields required for the subsequent
`/fix` handoff.
|
|
||
| Use this structure when writing `WISH.md`: | ||
|
|
||
| ```markdown |
There was a problem hiding this comment.
Fix the nested fence in the template example.
The inner ```bash closes the outer ```markdown fence, so the example renders truncated.
Suggested fix
-```markdown
+````markdown
# Wish: <Title>
...
**Validation:**
```bash
# Command that exits 0 on success
```
...
-```
+````Also applies to: 90-93, 103-103
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/wish/SKILL.md` at line 49, The markdown example block in SKILL.md uses
a triple-backtick outer fence labeled "```markdown" and contains an inner
"```bash" fence which prematurely closes the outer fence; change the outer fence
to a four-backtick fence (e.g., "````markdown") or otherwise ensure the inner
"```bash" is nested safely so the example renders fully, and apply the same fix
to the other occurrences around the example (the blocks near the current 90-93
and 103 lines) so all nested code fences use a safe outer fence or are escaped
consistently.
Comment on lines
+52
to
+58
| | Field | Value | | ||
| |-------|-------| | ||
| | **Status** | DRAFT | | ||
| | **Slug** | `<slug>` | | ||
| | **Date** | YYYY-MM-DD | | ||
| | **Design** | [DESIGN.md](../../brainstorms/<slug>/DESIGN.md) | | ||
|
|
There was a problem hiding this comment.
Don't require DESIGN.md for direct /wish entry.
Line 23 still lets /wish proceed once the request is already clear, but this template hardcodes a brainstorm artifact. That leaves direct /wish runs with a broken link unless /brainstorm is mandatory for every wish.
Suggested fix
| **Status** | DRAFT |
| **Slug** | `<slug>` |
| **Date** | YYYY-MM-DD |
-| **Design** | [DESIGN.md](../../brainstorms/<slug>/DESIGN.md) |
+| **Design** | [DESIGN.md](../../brainstorms/<slug>/DESIGN.md) *(optional; omit or use `N/A` for direct `/wish` entry)* |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/wish/SKILL.md` around lines 52 - 58, The SKILL.md template currently
hardcodes a brainstorm artifact link to DESIGN.md which breaks direct /wish
runs; update the template in SKILL.md to not require or hardcode the brainstorm
path (the Slug/Design fields), e.g., remove or mark the DESIGN.md entry as
optional so direct /wish entries don’t include a broken
../../brainstorms/<slug>/DESIGN.md link; ensure references to the slug/Design
are conditional or replaced with a neutral placeholder so /wish can proceed
without a brainstorm artifact.
Comment on lines
+79
to
+103
| ## Execution Groups | ||
|
|
||
| ### Group 1: <Name> | ||
| **Goal:** One sentence. | ||
| **Deliverables:** | ||
| 1. Deliverable with acceptance criteria | ||
| 2. Deliverable with acceptance criteria | ||
|
|
||
| **Acceptance criteria:** | ||
| - Criterion with validation command | ||
|
|
||
| **Validation:** | ||
| ```bash | ||
| # Command that exits 0 on success | ||
| ``` | ||
|
|
||
| **depends-on:** none | Group N | ||
|
|
||
| --- | ||
|
|
||
| ## Assumptions / Risks | ||
| | Risk | Severity | Mitigation | | ||
| |------|----------|------------| | ||
| | Risk 1 | Low/Medium/High | How to handle | | ||
| ``` |
There was a problem hiding this comment.
The template drops wish-level dependency fields.
Line 29 now requires cross-wish dependencies, and skills/brainstorm/SKILL.md:75-99 says those become depends-on / blocks fields in the wish. This template only keeps a per-group depends-on, so there is nowhere to record wish-level blocks or repo/slug dependencies.
Suggested fix
**depends-on:** none | Group N
---
+## Dependencies
+- depends-on: <slug> | <repo>/<slug>
+- blocks: <slug> | <repo>/<slug>
+
## Assumptions / Risks
| Risk | Severity | Mitigation |
|------|----------|------------|
| Risk 1 | Low/Medium/High | How to handle |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/wish/SKILL.md` around lines 79 - 103, The template lacks wish-level
dependency fields (depends-on/blocks/repo slug) and only supports per-group
depends-on; update the SKILL.md template's "Execution Groups" section to include
a top-level "Wish-level dependencies" block (or a "depends-on / blocks / repo"
subsection above the groups) that accepts cross-wish dependency entries and
repo/slug identifiers, and keep per-group "depends-on" for intra-wish ordering;
ensure the new fields use the same YAML-like bullet format as group depends-on
so downstream parsers can pick up wish-level depends-on/blocks and repo/slug
references.
| 3. **Self-refine:** dispatch `/refine` on the task prompt (text mode) with WISH.md as context anchor. Read output from `/tmp/prompts/<slug>.md`. Fallback: proceed with original prompt if refiner fails (non-blocking). | ||
| 4. **Dispatch worker:** send the task to a fresh subagent session (see Dispatch). | ||
| 5. **Spec review:** dispatch review subagent to check acceptance criteria. On FIX-FIRST, dispatch fix subagent (max 2 loops). | ||
| 5. **Local review:** run `/review` against the wish spec for this group's acceptance criteria before signaling done. On FIX-FIRST, dispatch fix subagent (max 2 loops). |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Local review gate added - verify loop limit consistency.
This line specifies "max 2 loops" for fix on FIX-FIRST during local review. Line 26 specifies "max 1 loop" for quality review. Ensure these different loop limits are intentional and clearly justified, as the asymmetry may confuse implementors.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@skills/work/SKILL.md` at line 24, The local review step in SKILL.md currently
sets "On FIX-FIRST, dispatch fix subagent (max 2 loops)" while the quality
review step sets "max 1 loop", causing inconsistency; update the SKILL.md
content by either (A) making the limits consistent (e.g., change the local
review's "max 2 loops" to "max 1 loop" to match the quality review) or (B) add a
brief clarifying justification next to the "max 2 loops" phrase stating why
FIX-FIRST needs two loops versus the quality review's one loop so implementors
understand the asymmetry (mentioning FIX-FIRST and quality review explicitly to
locate the text).
- Add "leader" built-in role with full orchestration system prompt - Add --wish <slug> flag to "genie team create" for auto-spawning leaders - Add team status tracking (in_progress/done/blocked) with setTeamStatus() - Add "genie team done" and "genie team blocked" CLI commands - Add autoMergeDev config option to GenieConfigSchema - Update "genie team ls" to show team status column
- Add file lock to setTeamStatus to prevent concurrent read-modify-write races
- Replace require("node:path").resolve with ESM import in team.ts
- Validate wish file exists before createTeam to avoid orphaned teams
- Add --team flag to all genie team commands in leader prompt since GENIE_TEAM won't be set
Co-Authored-By: Paperclip <noreply@paperclip.ing>
feat: task leader role — autonomous wish lifecycle orchestration
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/lib/team-manager.ts (1)
199-202:⚠️ Potential issue | 🟠 MajorBackfill
statusfor existing team config files before returning.The idempotent path returns legacy JSON unchanged; older teams can come back without
statuseven thoughTeamConfignow requires it. Normalize on read (and optionally persist) to avoid runtime/schema drift.Suggested fix
if (existsSync(filePath)) { const content = await readFile(filePath, 'utf-8'); - return JSON.parse(content); + const existing = JSON.parse(content) as Partial<TeamConfig>; + if (!existing.status) { + existing.status = 'in_progress'; + await writeFile(filePath, JSON.stringify(existing, null, 2)); + } + return existing as TeamConfig; }As per coding guidelines:
src/**: Core CLI source. Check for breaking changes to exported types.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/team-manager.ts` around lines 199 - 202, The code path that reads legacy team JSON (the existsSync/readFile -> JSON.parse return) must normalize returned objects to include the required TeamConfig.status field; after parsing, if parsed.status is missing, set parsed.status = 'active' (or the canonical default used by TeamConfig) and return the updated object (optionally write it back to disk to persist the backfill). Update the branch that currently returns JSON.parse(content) to perform this check/assignment so callers (and the TeamConfig type) always get a status property.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/lib/team-manager.test.ts`:
- Around line 263-286: Add a test that ensures legacy TeamConfig objects missing
the required status field are normalized to 'in_progress': create a legacy JSON
object for a team (omit the status property) and persist it using the same
storage layer the team manager uses, then call getTeam('feat/legacy-status') and
assert config!.status === 'in_progress'; also add a second assertion that
calling createTeam('feat/legacy-status', ...) against an existing legacy file
upgrades/returns a TeamConfig with status 'in_progress'. Reference the
TeamConfig shape and the existing createTeam and getTeam helpers to locate the
code paths to exercise and normalize the missing status.
In `@src/lib/team-manager.ts`:
- Around line 385-395: setTeamStatus currently acquires a lock but other
mutating functions (hireAgent, fireAgent, and any other writers that call
getTeam and writeFile) do not, causing lost updates; fix by adopting the same
lock discipline for all mutations: either wrap each mutating function
(hireAgent, fireAgent, etc.) with acquireLock(teamFilePath(teamName)) / release
in a try/finally around read-modify-write, or better, extract a single helper
(e.g., updateTeamAtomic or withTeamLock) that takes a teamName and a mutator
callback, performs acquireLock(filePath), reads config via getTeam, applies the
mutator, writes JSON with writeFile, and always releases in finally; update all
mutating callers to use that helper so all writes use the same locking
semantics.
In `@src/term-commands/team.ts`:
- Around line 33-37: The code uses options.wish directly in path joins (see
options.wish, wishPath, resolve, join, existsSync) which allows path traversal;
normalize and validate the slug before using it by resolving the base wishes
directory (e.g. resolve(options.repo) + '.genie/wishes'), then build the
candidate path with path.resolve(baseWishesDir, options.wish, 'WISH.md'),
compute path.relative(baseWishesDir, candidatePath) and ensure it does not start
with '..' (or that candidatePath startsWith the base dir) before calling
existsSync or reading the file; apply the same validation logic to the other
occurrences around lines 201-211.
---
Outside diff comments:
In `@src/lib/team-manager.ts`:
- Around line 199-202: The code path that reads legacy team JSON (the
existsSync/readFile -> JSON.parse return) must normalize returned objects to
include the required TeamConfig.status field; after parsing, if parsed.status is
missing, set parsed.status = 'active' (or the canonical default used by
TeamConfig) and return the updated object (optionally write it back to disk to
persist the backfill). Update the branch that currently returns
JSON.parse(content) to perform this check/assignment so callers (and the
TeamConfig type) always get a status property.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 81641664-ed07-42a7-8686-1d6e321456c8
📒 Files selected for processing (7)
src/lib/builtin-agents.test.tssrc/lib/builtin-agents.tssrc/lib/team-manager.test.tssrc/lib/team-manager.tssrc/term-commands/team.test.tssrc/term-commands/team.tssrc/types/genie-config.ts
Comment on lines
+263
to
+286
| describe('team status', () => { | ||
| test('new team has in_progress status', async () => { | ||
| const config = await createTeam('feat/status-default', TEST_REPO, 'dev'); | ||
| expect(config.status).toBe('in_progress'); | ||
| }); | ||
|
|
||
| test('setTeamStatus sets status to done', async () => { | ||
| await createTeam('feat/status-done', TEST_REPO, 'dev'); | ||
| await setTeamStatus('feat/status-done', 'done'); | ||
| const config = await getTeam('feat/status-done'); | ||
| expect(config!.status).toBe('done'); | ||
| }); | ||
|
|
||
| test('setTeamStatus sets status to blocked', async () => { | ||
| await createTeam('feat/status-blocked', TEST_REPO, 'dev'); | ||
| await setTeamStatus('feat/status-blocked', 'blocked'); | ||
| const config = await getTeam('feat/status-blocked'); | ||
| expect(config!.status).toBe('blocked'); | ||
| }); | ||
|
|
||
| test('setTeamStatus throws for non-existent team', async () => { | ||
| expect(setTeamStatus('nonexistent', 'done')).rejects.toThrow('not found'); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add a regression test for legacy team JSON without status.
Given TeamConfig.status is now required, add one test that writes an older config shape (missing status) and verifies read/create paths normalize it to in_progress.
As per coding guidelines: src/**: Core CLI source. Check for breaking changes to exported types.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/lib/team-manager.test.ts` around lines 263 - 286, Add a test that ensures
legacy TeamConfig objects missing the required status field are normalized to
'in_progress': create a legacy JSON object for a team (omit the status property)
and persist it using the same storage layer the team manager uses, then call
getTeam('feat/legacy-status') and assert config!.status === 'in_progress'; also
add a second assertion that calling createTeam('feat/legacy-status', ...)
against an existing legacy file upgrades/returns a TeamConfig with status
'in_progress'. Reference the TeamConfig shape and the existing createTeam and
getTeam helpers to locate the code paths to exercise and normalize the missing
status.
Comment on lines
+385
to
+395
| export async function setTeamStatus(teamName: string, status: TeamStatus): Promise<void> { | ||
| const filePath = teamFilePath(teamName); | ||
| const release = await acquireLock(filePath); | ||
| try { | ||
| const config = await getTeam(teamName); | ||
| if (!config) { | ||
| throw new Error(`Team "${teamName}" not found.`); | ||
| } | ||
| config.status = status; | ||
| await writeFile(filePath, JSON.stringify(config, null, 2)); | ||
| } finally { |
There was a problem hiding this comment.
Locking only setTeamStatus still allows lost updates.
setTeamStatus acquires a lock, but hireAgent, fireAgent, and other writers update the same file without that lock. Concurrent writes can overwrite each other (e.g., status update dropping member changes). Use the same lock discipline across all mutating team-config writes.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/lib/team-manager.ts` around lines 385 - 395, setTeamStatus currently
acquires a lock but other mutating functions (hireAgent, fireAgent, and any
other writers that call getTeam and writeFile) do not, causing lost updates; fix
by adopting the same lock discipline for all mutations: either wrap each
mutating function (hireAgent, fireAgent, etc.) with
acquireLock(teamFilePath(teamName)) / release in a try/finally around
read-modify-write, or better, extract a single helper (e.g., updateTeamAtomic or
withTeamLock) that takes a teamName and a mutator callback, performs
acquireLock(filePath), reads config via getTeam, applies the mutator, writes
JSON with writeFile, and always releases in finally; update all mutating callers
to use that helper so all writes use the same locking semantics.
Comment on lines
+33
to
+37
| if (options.wish) { | ||
| const resolvedRepo = resolve(options.repo); | ||
| const wishPath = join(resolvedRepo, '.genie', 'wishes', options.wish, 'WISH.md'); | ||
| if (!existsSync(wishPath)) { | ||
| console.error(`Error: Wish not found at ${wishPath}`); |
There was a problem hiding this comment.
Validate wish slug to block path traversal.
options.wish/slug is used directly in filesystem joins. Values like ../... can escape .genie/wishes and read/write unintended paths. Normalize and enforce root-prefix before using paths.
Suggested fix
-import { join, resolve } from 'node:path';
+import { join, resolve, sep } from 'node:path';
@@
+function resolveWishFilePath(repoPath: string, slug: string): string {
+ const root = resolve(repoPath, '.genie', 'wishes');
+ const wishFile = resolve(root, slug, 'WISH.md');
+ if (!wishFile.startsWith(`${root}${sep}`)) {
+ throw new Error(`Invalid wish slug: ${slug}`);
+ }
+ return wishFile;
+}
@@
- const wishPath = join(resolvedRepo, '.genie', 'wishes', options.wish, 'WISH.md');
+ const wishPath = resolveWishFilePath(resolvedRepo, options.wish);
@@
- const sourceWishPath = join(resolvedRepo, '.genie', 'wishes', slug, 'WISH.md');
+ const sourceWishPath = resolveWishFilePath(resolvedRepo, slug);Also applies to: 201-211
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/term-commands/team.ts` around lines 33 - 37, The code uses options.wish
directly in path joins (see options.wish, wishPath, resolve, join, existsSync)
which allows path traversal; normalize and validate the slug before using it by
resolving the base wishes directory (e.g. resolve(options.repo) +
'.genie/wishes'), then build the candidate path with path.resolve(baseWishesDir,
options.wish, 'WISH.md'), compute path.relative(baseWishesDir, candidatePath)
and ensure it does not start with '..' (or that candidatePath startsWith the
base dir) before calling existsSync or reading the file; apply the same
validation logic to the other occurrences around lines 201-211.
…rompts Inline --append-system-prompt and --system-prompt flags broke when passed through tmux send-keys with multi-line prompts containing code blocks. All system prompts are now written to temp files at /tmp/genie-prompts/ and passed via --append-system-prompt-file or --system-prompt-file. When both systemPrompt and systemPromptFile are set, they are merged into a single temp file. Extra --append-system-prompt-file args are also merged. Closes #568
fix: eliminate inline system prompts — all prompts via temp files (#568)
- Add initialPrompt field to SpawnParams/SpawnOptions, appended as Claude Code positional [prompt] arg in buildClaudeCommand() - spawnLeaderWithWish() now passes a kickoff prompt so the leader begins working immediately — no manual genie send needed - Audit and update orchestration rules in smart-install.js and install.sh: add team done/blocked, dir commands, update --next/ --stable, task leader workflow, autoMergeDev config - Both install scripts now have identical orchestration content
feat: auto-kickoff leader on wish spawn + orchestration rules audit
Group 1 — Orchestration Rules: - Create plugins/genie/rules/genie-orchestration.md (~15 lines) - Remove hardcoded ORCHESTRATION_PROMPT from smart-install.js - Update install.sh to copy from package file with fallback - Both installers log where the rule was created - Add removal of ~/.claude/rules/genie-orchestration.md to uninstall Group 2 — Agent Consolidation: - Rename implementor → engineer - Merge spec-reviewer + quality-reviewer → reviewer (SHIP/FIX-FIRST) - Merge tests → qa (writes tests + validates on dev) - Delete old agent files - Update builtin-agents.ts, skills, and all references Group 4 — Session Fixes: - getAgentsSystemPrompt() → getAgentsFilePath() (returns path not content) - team-lead-command.ts: accept systemPromptFile, delete PROMPTS_DIR copy - --agent-name uses basename(cwd) instead of hardcoded "team-lead" - launchTmuxSpawn: use send-keys for first agent in team window
…gistry Group 3 of fix-orchestration-rules wish: - Convert every agent .md into folder/<name>/AGENTS.md with symlinks - Create team-lead/ with AGENTS.md + SOUL.md + HEARTBEAT.md - Create pm/ with AGENTS.md + SOUL.md + HEARTBEAT.md - Add SOUL.md for all council members with real-person philosophy - Add @SOUL.md import to council AGENTS.md files - Rewrite builtin-agents.ts: scan plugins/genie/agents/*/ for discovery, parse CC frontmatter, no inline systemPrompt strings - Add resolveBuiltinAgentPath(name) for file-based resolution - Update agents.ts: use agentPath as systemPromptFile, no inline prompts - Update tests for new folder structure and naming (council-- double dash)
session.ts hardcoded 'team-lead' as the agent name in ensureNativeTeamForLeader, findLastSessionId calls, and console.log messages. Since team-lead-command.ts derives agent name from basename(cwd), session.ts must match to avoid session resume mismatches and incorrect native team registration. Also simplify install.sh orchestration rules lookup to use the already-resolved PKG_DIR instead of scanning hardcoded candidate paths.
feat: orchestration rules overhaul + agent folder structure + session fixes
import.meta.dir returns CWD in compiled bundles, not the module's directory. Use the actual script path (process.argv[1]) resolved via realpathSync to find the package root and discover agent folders.
fix: inline SOUL+HEARTBEAT in team-lead, pre-hire team, force cache bust
fix: team-lead uses genie work directly + wish template QA section
fix: set GENIE_TEAM env var on agent spawn
fix: kickoff message — genie work spawns automatically
Agent directory now defaults to project scope (<repo>/.genie/agents.json)
with fallback to global (~/.genie/agent-directory.json) then built-ins.
- add/rm/edit default to project scope, accept { global: true } option
- resolve() checks project → global → built-in roles → built-in council
- ls() returns entries from all scopes with scope label
- dir CLI commands accept --global flag
- dir ls shows SCOPE column
Closes #578
feat: project-scoped agent directory — multiple engineers across projects
fix(update): delete bun lockfile before install
#593) * fix(reset): clean up all team dirs on --reset, not just current window When `genie --reset` was called, handleReset() killed the entire tmux session but only deleted one native team directory (the current windowName). Any other windows in the session left their team configs behind in ~/.claude/teams/. Fix: collect all window names via listWindows() before killing the session, then delete each window's team directory. Closes #545 * fix: use session ID instead of name in tmux calls to prevent injection Gemini review flagged potential command injection when sessionName is passed to tmux.listWindows/killSession. If a session name contains single quotes it could break shell quoting in executeTmux. Fix: use existing.id (system-assigned identifier) instead of sessionName for the tmux calls. Session name still used for the log message (cosmetic only). --------- Co-authored-by: Felipe Rosa <felipe@namastex.ai>
…chTmuxSpawn (#595) Extract helper functions to bring both functions under the biome complexity limit of 15: - buildClaudeCommand (27→~12): extract appendSystemPromptFlags() - launchTmuxSpawn (22→~8): extract createTmuxPane() and applySpawnLayout() Closes #594 Co-authored-by: Test User <test@test.com>
…596) - Fix JSON formatting in package.json, openclaw.plugin.json, plugin.json - Fix noAssignInExpressions in dispatch.ts (refactor while loop) - Reduce complexity in performUninstall (21→≤15): extract tryRemoveStep() - Reduce complexity in autoSpawn (25→≤15): extract buildSearchNames(), buildSpawnArgs() - Reduce complexity in executeBlockingChain (18→≤15): extract runHandler() - Reduce complexity in syncPlugin (16→≤15): extract updatePluginRegistry() - Reduce complexity in chat action (17→≤15): extract resolveTeamName() Biome now reports zero errors and zero warnings. Co-authored-by: Test User <test@test.com>
Delete scale.test.ts and file-lock-concurrency.test.ts — these are environment-dependent stress tests that cause CI failures due to shared /tmp state and concurrent file lock race conditions. They belong in a separate CI job, not the main test suite. Co-authored-by: Test User <test@test.com>
* feat(worktree): move default worktree path to ~/.genie/worktrees/<project>/ Worktrees currently default to <repo>/.worktrees/ which causes accidental git commits and bloated npm publishes. Change the default to ~/.genie/worktrees/<project-name>/ when no explicit worktreeBase is set. - Make worktreeBase optional in config schema (undefined = new default) - Update getWorktreeBase() to derive project name from basename(repoPath) - Update setup wizard to show new default path * feat(worktree): add auto-prune, fix gitignore, remove dead code - Add pruneStaleWorktrees() to clean up team configs for non-existent worktree paths and run git worktree prune - Call pruneStaleWorktrees() from disbandTeam() after cleanup - Update .gitignore: add .worktrees/, remove dead .genie/worktrees/ - Untrack committed .worktrees/ directory from git - Delete dead worktree-manager.ts and its test (unused legacy code) --------- Co-authored-by: Test User <test@test.com>
Remove files that should never have been tracked: - .worktrees/ — Claude Code worktree metadata - .genie/agents.json — local agent directory - .genie/teams/ — local team configs - .genie/brainstorms/ — local brainstorm drafts - .genie/wishes/ — local wish plans These are local runtime state, not part of the published package. Files remain on disk (git rm --cached), only removed from tracking. Co-authored-by: Test User <test@test.com>
This was referenced Mar 16, 2026
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rolling Promotion PR
Auto-maintained rolling promotion PR from
devtomain.Process:
ready-to-mergeadded when all checks passSummary by CodeRabbit
Chores
New Features
Documentation
Tests