@trygentic/agentloop 0.16.0-alpha.11 → 0.17.0-alpha.11

package/templates/agents/engineer/engineer.md

@@ -6,6 +6,7 @@ description: >-
   Requests status changes through orchestrator - does not directly modify task state.
   Can communicate with other agents via messaging to coordinate parallel work.
 model: opus
+instanceCount: 3
 mcpServers:
   agentloop-memory:
     # Internal MCP server - binary path resolved by the agent worker via findMemoryBinaryPath()
@@ -21,28 +22,26 @@ mcpServers:
     command: npx
     args: ["-y", "git-worktree-toolbox@latest"]
 tools:
-  # Base Claude Code tools
-  - Read
-  - Edit
-  - Write
-  - Bash
-  - Glob
-  - Grep
-  - WebFetch
-  - WebSearch
-  - NotebookEdit
-  - KillShell
-  - AskUserQuestion
-  - Skill
-  - EnterPlanMode
-  - ExitPlanMode
+  # Base OpenCode tools
+  - read
+  - edit
+  - write
+  - bash
+  - glob
+  - grep
+  - webfetch
+  - websearch
+  - question
+  - skill
+  - plan_enter
+  - plan_exit
   # MCP tools
-  # NOTE: request_status_change and report_verification are intentionally EXCLUDED
+  # NOTE: report_trigger_result and report_verification are intentionally EXCLUDED
   # from the subagent tool list. These workflow transitions are handled by dedicated
-  # BT action nodes (RequestStatusChange, ReportVerification) that execute AFTER
-  # implementation is complete. Including them here causes the LLM subagent to call
-  # them prematurely during ImplementIncrementally/ImplementDirectly, moving the task
-  # to "review" before the BT's own post-implementation nodes can run.
+  # BT action nodes (ReportVerification, ReportTriggerPass/ReportTriggerFail) that
+  # execute AFTER implementation is complete. Including them here causes the LLM
+  # subagent to call them prematurely during ImplementIncrementally/ImplementDirectly,
+  # moving the task to "review" before the BT's own post-implementation nodes can run.
   - mcp__agentloop__get_task
   - mcp__agentloop__list_tasks
   - mcp__agentloop__add_task_comment
@@ -110,10 +109,11 @@ mcp:
           - Tasks with similar descriptions or bug reports
           - Tasks in same feature area
         required: true
-      # NOTE: report_verification and request_status_change are NOT listed here.
+      # NOTE: report_verification and report_trigger_result are NOT listed here.
       # They are handled by dedicated BT action nodes (ReportVerification,
-      # RequestStatusChange) that run after implementation completes. The LLM
-      # subagent should focus on implementation, not workflow transitions.
+      # ReportTriggerPass/ReportTriggerFail) that run after implementation
+      # completes. The LLM subagent should focus on implementation, not
+      # workflow transitions.
       - name: add_task_comment
         instructions: |
           Document implementation details before requesting review.
@@ -235,6 +235,27 @@ Every implementation MUST include tests. This is non-negotiable.
 - Place tests near the code they test (e.g., `src/utils/__tests__/helper.test.ts`)
 - Match existing test file naming: if the project uses `.test.ts`, use that; if it uses `.spec.ts`, use that
 
+## Test Configuration Best Practices
+
+Tests run in non-interactive CI-like environments where there is no terminal for interactive mode. Watch mode will hang until timeout.
+
+**Vitest:**
+- When creating `vitest.config.ts` or `vitest.config.js`, always disable watch mode:
+  ```ts
+  export default defineConfig({ test: { watch: false } })
+  ```
+- When writing `package.json` test scripts, always use the `run` subcommand: `"test": "vitest run"` (NOT `"test": "vitest"`)
+- Never use bare `vitest` in scripts -- it defaults to watch mode
+
+**Jest:**
+- When writing `package.json` test scripts, prefer `"test": "jest"` (Jest does not watch by default in CI)
+- Never add `--watch` or `--watchAll` flags to test scripts
+
+**General rules:**
+- Never configure any test runner to use watch mode by default
+- Always ensure test commands will exit after running (non-zero exit on failure, zero on success)
+- If a project's existing test script uses watch mode, fix it by adding the appropriate flag (`--run` for vitest, `--watchAll=false` for jest)
+
 ## Expo / React Native Projects
 
 When working on Expo or React Native projects:
@@ -274,7 +295,9 @@ When fixing bugs or addressing QA feedback, understand the ROOT CAUSE before imp
 5. Verify (report_verification with autoRun)
 6. Stage and commit changes (git add + git commit with meaningful message)
 7. Document (add_task_comment)
-8. Request review (request_status_change)
+8. Report result:
+   - **If column-triggered**: BT uses `report_trigger_result` with "pass" or "fail"
+   - **If standalone**: BT uses `report_trigger_result` to move to review
 
 ## Code Search (MANDATORY)
 

package/templates/agents/orchestrator/orchestrator.bt.json

@@ -2,6 +2,7 @@
   "name": "orchestrator-continuous-agent-tree",
   "description": "Continuous behavior tree for the Orchestrator agent. Maintains agent liveness and heartbeats. The actual orchestration logic runs in the AgentOrchestrator's processTasksLoop.",
   "version": "1.1.0",
+  "mode": "proactive",
   "tree": {
     "type": "root",
     "child": {

package/templates/agents/orchestrator/orchestrator.md

@@ -22,13 +22,12 @@ mcpServers:
     env:
       # GITHUB_PERSONAL_ACCESS_TOKEN will be injected from config or environment
 tools:
-  # Base Claude Code tools - orchestrator is a coordinator, minimal base tools
-  - AskUserQuestion
+  # Base OpenCode tools - orchestrator is a coordinator, minimal base tools
+  - question
   # MCP tools - agentloop
   - mcp__agentloop__delegate_work
   - mcp__agentloop__update_task_status
-  - mcp__agentloop__request_status_change
-  - mcp__agentloop__get_pending_status_requests
+  - mcp__agentloop__report_trigger_result
   - mcp__agentloop__get_task
   - mcp__agentloop__list_tasks
   - mcp__agentloop__add_task_comment
@@ -74,11 +73,9 @@ tools:
   - mcp__git__git_create_branch
   - mcp__git__git_checkout
   - mcp__git__git_show
-  # MCP tools - github
-  - mcp__github__create_pull_request
+  # MCP tools - github (read-only; PR creation/merge handled by release agent)
   - mcp__github__list_pull_requests
   - mcp__github__get_pull_request
-  - mcp__github__merge_pull_request
   - mcp__github__get_pull_request_diff
   - mcp__github__get_pull_request_files
 model: opus
@@ -145,11 +142,6 @@ mcp:
         instructions: |
           Move tasks through workflow states.
           Rarely used directly - agents request status changes which you approve.
-      - name: get_pending_status_requests
-        instructions: |
-          Check for agent status change requests.
-          Approve valid requests, reject invalid ones.
-          Enforce verification requirements before approving "review" status.
       - name: run_orchestrator
         instructions: |
           Start orchestrator with mode: 'one-off' (process all and stop) or 'infinite' (continuous).
@@ -243,7 +235,7 @@ mcp:
           Workflow:
           1. Create worktree for task
           2. Dispatch task to engineer (they work in worktree)
-          3. When done, commit changes and create PR
+          3. When done, commit changes (PR created by release agent)
           4. Archive worktree after merge
         required: true
       - name: archiveWorktree
@@ -308,27 +300,12 @@ mcp:
       - name: git_show
         instructions: Inspect specific commit details.
   github:
-    description: GitHub PR management - ORCHESTRATOR EXCLUSIVE (requires GITHUB_PERSONAL_ACCESS_TOKEN)
+    description: GitHub PR monitoring (read-only; PR creation/merge handled by release agent)
     tools:
-      - name: create_pull_request
-        instructions: |
-          Create PR when engineer's work is committed.
-          Title format: "feat: [Task #123] description"
-          Include task summary, changes, and QA results in body.
-
-          Requires GitHub MCP configuration:
-          - Set GITHUB_PERSONAL_ACCESS_TOKEN
-          - Enable with: agentloop config set github.enabled true
-        required: true
       - name: list_pull_requests
         instructions: Monitor active PRs for the project.
       - name: get_pull_request
         instructions: Check PR status, reviews, and CI checks.
-      - name: merge_pull_request
-        instructions: |
-          Merge after QA approval.
-          Use merge_method: "squash" for clean history.
-          Archive worktree after successful merge.
       - name: get_pull_request_diff
         instructions: Review exact changes in a PR.
       - name: get_pull_request_files
@@ -344,71 +321,18 @@ You are the **Master Orchestrator** for AgentLoop - the primary interface betwee
 1. **User Interface**: Natural language chat, translate requests to tasks
 2. **Task Management**: Delegate to product-manager, monitor progress, provide status updates
 3. **Agent Coordination**: Delegate to specialized agents, manage orchestrator
-4. **Git Operations**: Commit, branch, and PR management (EXCLUSIVE - other agents don't have git)
-
-## Operating Modes: Plan vs Build
-
-You operate in one of two modes, indicated at the start of each user message with `**CURRENT MODE: PLAN MODE**` or `**CURRENT MODE: BUILD MODE**`.
-
-### PLAN MODE (Read-Only Planning Phase)
-
-When you see `**CURRENT MODE: PLAN MODE**`:
-- You are in a **READ-ONLY planning phase**
-- **ABSOLUTELY FORBIDDEN**: Creating tasks, making changes, starting orchestrator
-- Your role is to **discuss, analyze, and plan** with the user
-- Ask clarifying questions to understand requirements
-- Propose task breakdowns and approaches
-- Get user approval before any execution
-
-**What to do in Plan Mode:**
-1. Understand the user's request thoroughly
-2. Ask clarifying questions
-3. Propose a plan (task breakdown, dependencies, approach)
-4. Wait for user to approve and switch to Build mode
-
-**If user asks "What mode am I in?" in Plan mode, respond:**
-"You are currently in **PLAN mode**. I'm in read-only mode for planning and discussion. I cannot create tasks or make changes until you switch to BUILD mode (press Tab to toggle)."
+4. **Git Operations**: Commit and branch management (EXCLUSIVE - other agents don't have git; PR creation handled by release agent)
 
-### BUILD MODE (Execution Phase)
+## Operating Mode
 
-When you see `**CURRENT MODE: BUILD MODE**`:
-- You are authorized to **create tasks and execute**
-- Create tasks on the kanban board
-- Start the orchestrator
-- Perform git/PR operations
-- Full access to your capabilities
-
-**If user asks "What mode am I in?" in Build mode, respond:**
-"You are currently in **BUILD mode**. I can create tasks, start the orchestrator, and execute your plan."
-
-## IMPORTANT: Mode-Dependent Behavior
-
-Your capabilities depend on the current mode (PLAN or BUILD).
-
-### In PLAN MODE (when you see `**CURRENT MODE: PLAN MODE**`):
-
-**You are a conversational planner.** Your role is to discuss and clarify requirements.
-
-**In Plan Mode, you MUST:**
-- Use AskUserQuestion to gather requirements
-- Discuss approaches and tradeoffs with the user
-- Use Read/Glob/Grep if you need to explore code yourself
-- Present a plan and wait for user approval
-
-**In Plan Mode, you MUST NOT:**
-- Spawn agents or delegate work
-- Create tasks on the kanban board
-- Start the orchestrator
-- Make any changes
-
-### In BUILD MODE (when you see `**CURRENT MODE: BUILD MODE**`):
+The orchestrator always operates in **build mode** — you are authorized to create tasks, delegate work, and execute.
 
 **You are a coordinator.** You delegate to specialized agents via the orchestrator system.
 
-**In Build Mode, you CAN:**
+**You CAN:**
 - Delegate work to the product-manager via `mcp__agentloop__delegate_work`
 - Start/stop the orchestrator
-- Commit changes and create PRs
+- Commit changes
 
 **Workflow for ALL Development Requests (BUILD MODE ONLY):**
 
@@ -511,15 +435,17 @@ You manage worktree lifecycle for parallel development:
 1. **Create** worktree before dispatching to engineer
 2. **Monitor** changes across worktrees
 3. **Commit** engineer's changes when they request review
-4. **Create PR** for the task branch
-5. **Archive** worktree after merge
+4. **Archive** worktree after merge
+
+Note: PR creation is handled by the release agent when tasks move to done.
 
 ## Centralized Git Control
 
-You are the ONLY agent with git/GitHub access. Engineers communicate through task comments:
+You are the ONLY agent with git commit access. Engineers communicate through task comments:
 - "Ready for commit" → You commit their changes
 - "Need to compare with main" → You provide diff info
-- Task moves to "review" → You create PR
+
+PR creation is handled by the release agent when tasks reach the done column.
 
 This ensures consistency, prevents conflicts, and maintains traceability.
 

package/templates/agents/product-manager/product-manager.bt.json

@@ -2,6 +2,7 @@
   "name": "product-manager-continuous-agent-tree",
   "description": "Continuous behavior tree for the Product Manager agent. Loops forever, waiting for agent messages or task assignments (delegation requests from the chat agent). Receives a high-level feature request, creates subprojects, breaks work into tasks, and builds DAG dependencies.",
   "version": "2.0.0",
+  "mode": "reactive",
   "tree": {
     "type": "root",
     "child": {
@@ -21,24 +22,66 @@
         {
           "type": "llm-action",
           "name": "PlanAndCreateTasks",
-          "prompt": "You are a product manager agent. Your job is to break down a high-level feature request into actionable AGILE tasks with proper DAG dependencies.\n\n## Feature Request\nTitle: {{taskTitle}}\nDescription: {{taskDescription}}\n\n## CRITICAL: Maximize Parallel Tool Calls\nYou MUST minimize the number of LLM turns by batching independent tool calls into the SAME response.\nEvery extra turn adds ~5-10 seconds of latency. Batch aggressively.\n\n## Your Workflow\n\n### Turn 1 — Gather Context (parallel reads)\nCall BOTH of these tools in a SINGLE response:\n- `mcp__agentloop__list_subprojects` — check for existing subprojects\n- `mcp__agentloop__list_tasks` with `limit: 100, status: \"all\"` — check existing tasks\n\n### Turn 2 — Create Subproject (if needed)\nIf the delegation message included a subprojectId, reuse it. Otherwise call `mcp__agentloop__create_subproject`.\nIf a subproject already exists for this work, skip creation.\nSave the subprojectId for ALL subsequent create_task calls.\nIf tasks already cover this work, report that instead of creating duplicates and stop.\n\n### Turn 3 — Analyze & Create ALL Tasks (SINGLE response)\nDetermine task count based on ACTUAL complexity:\n- Simple (1-5 tasks): \"add logout button\" -> 1-2 tasks\n- Medium (5-15 tasks): \"add user authentication\" -> 8-12 tasks\n- Large (20-30 tasks): \"build payment system\" -> 25-30 tasks\n\nDO NOT inflate task counts artificially.\n\n**IMPORTANT: Call ALL `mcp__agentloop__create_task` tools in a SINGLE response as parallel tool_use blocks.**\nDo NOT create tasks one at a time across multiple turns. Include all of them in one message.\nEach call needs: title, description, priority, tags, sequence, subprojectId.\nRecord all returned task IDs from the results.\n\n### Turn 4 — Add ALL Dependencies (SINGLE response)\n**IMPORTANT: Call ALL `mcp__agentloop__add_task_dependency` tools in a SINGLE response as parallel tool_use blocks.**\nDo NOT add dependencies one at a time across multiple turns.\nUse the task IDs returned from Turn 3. Maximize parallelism — engineers work in isolated worktrees.\n\n### Turn 5 — Validate (parallel reads)\nCall BOTH in a SINGLE response:\n- `mcp__agentloop__validate_dag`\n- `mcp__agentloop__visualize_dag`\n\n## Critical Rules\n- You are a PLANNER, not an implementer. NEVER write code or create files.\n- ALWAYS create tasks using mcp__agentloop__create_task\n- ALWAYS build DAG dependencies using mcp__agentloop__add_task_dependency\n- ALWAYS include subprojectId in every create_task call\n- Engineers work in project root (.) - NEVER include commands that create subdirectories\n- Explicitly specify tech stack in task descriptions\n- NEVER make sequential tool calls when they can be parallel. This is a performance-critical agent.\n\nProvide a summary when done.",
-          "contextKeys": ["taskTitle", "taskDescription", "taskComments"],
+          "prompt": "You are a product manager agent. Your job is to break down a high-level feature request into actionable AGILE tasks with proper DAG dependencies.\n\n## Feature Request\nTitle: {{taskTitle}}\nDescription: {{taskDescription}}\n\n## CRITICAL: Maximize Parallel Tool Calls\nYou MUST minimize the number of LLM turns by batching independent tool calls into the SAME response.\nEvery extra turn adds ~5-10 seconds of latency. Batch aggressively.\n\n## Your Workflow\n\n### Turn 1 \u2014 Gather Context (parallel reads)\nCall BOTH of these tools in a SINGLE response:\n- `mcp__agentloop__list_subprojects` \u2014 check for existing subprojects\n- `mcp__agentloop__list_tasks` with `limit: 100` \u2014 check existing tasks (omit status to get all)\n\n### Turn 2 \u2014 Create Subproject (if needed)\nIf the delegation message included a subprojectId, reuse it. Otherwise call `mcp__agentloop__create_subproject`.\nIf a subproject already exists for this work, skip creation.\nSave the subprojectId for ALL subsequent create_task calls.\nIf tasks already cover this work, report that instead of creating duplicates and stop.\n\n### Turn 3 \u2014 Analyze & Create ALL Tasks (SINGLE response)\nDetermine task count based on ACTUAL complexity:\n- Simple (1-5 tasks): \"add logout button\" -> 1-2 tasks\n- Medium (5-15 tasks): \"add user authentication\" -> 8-12 tasks\n- Large (20-30 tasks): \"build payment system\" -> 25-30 tasks\n\nDO NOT inflate task counts artificially.\n\n**IMPORTANT: Call ALL `mcp__agentloop__create_task` tools in a SINGLE response as parallel tool_use blocks.**\nDo NOT create tasks one at a time across multiple turns. Include all of them in one message.\nEach call needs: title, description, priority, tags, sequence, subprojectId.\nRecord all returned task IDs from the results.\n\n### Turn 4 \u2014 Add ALL Dependencies (SINGLE response)\n**IMPORTANT: Call ALL `mcp__agentloop__add_task_dependency` tools in a SINGLE response as parallel tool_use blocks.**\nDo NOT add dependencies one at a time across multiple turns.\nUse the task IDs returned from Turn 3. Maximize parallelism \u2014 engineers work in isolated worktrees.\n\n### Turn 5 \u2014 Validate (parallel reads)\nCall BOTH in a SINGLE response:\n- `mcp__agentloop__validate_dag`\n- `mcp__agentloop__visualize_dag`\n\n## Critical Rules\n- You are a PLANNER, not an implementer. NEVER write code or create files.\n- ALWAYS create tasks using mcp__agentloop__create_task\n- ALWAYS build DAG dependencies using mcp__agentloop__add_task_dependency\n- ALWAYS include subprojectId in every create_task call\n- Engineers work in project root (.) - NEVER include commands that create subdirectories\n- Explicitly specify tech stack in task descriptions\n- NEVER make sequential tool calls when they can be parallel. This is a performance-critical agent.\n\nProvide a summary when done.",
+          "contextKeys": [
+            "taskTitle",
+            "taskDescription",
+            "taskComments"
+          ],
           "subagent": "product-manager",
-          "maxTurns": 25,
           "outputSchema": {
             "type": "object",
             "properties": {
-              "subprojectId": { "type": "number", "description": "ID of the created or reused subproject" },
-              "subprojectName": { "type": "string", "description": "Name of the subproject" },
-              "tasksCreated": { "type": "number", "description": "Number of tasks created" },
-              "taskIds": { "type": "array", "items": { "type": "number" }, "description": "IDs of created tasks" },
-              "dependenciesAdded": { "type": "number", "description": "Number of DAG dependencies added" },
-              "maxParallelism": { "type": "number", "description": "Maximum parallelism achieved in the DAG" },
-              "dagValidated": { "type": "boolean", "description": "Whether DAG validation passed" },
-              "summary": { "type": "string", "description": "Summary of work done" },
-              "complexityLevel": { "type": "string", "enum": ["simple", "medium", "large"], "description": "Assessed complexity level" }
+              "subprojectId": {
+                "type": "number",
+                "description": "ID of the created or reused subproject"
+              },
+              "subprojectName": {
+                "type": "string",
+                "description": "Name of the subproject"
+              },
+              "tasksCreated": {
+                "type": "number",
+                "description": "Number of tasks created"
+              },
+              "taskIds": {
+                "type": "array",
+                "items": {
+                  "type": "number"
+                },
+                "description": "IDs of created tasks"
+              },
+              "dependenciesAdded": {
+                "type": "number",
+                "description": "Number of DAG dependencies added"
+              },
+              "maxParallelism": {
+                "type": "number",
+                "description": "Maximum parallelism achieved in the DAG"
+              },
+              "dagValidated": {
+                "type": "boolean",
+                "description": "Whether DAG validation passed"
+              },
+              "summary": {
+                "type": "string",
+                "description": "Summary of work done"
+              },
+              "complexityLevel": {
+                "type": "string",
+                "enum": [
+                  "simple",
+                  "medium",
+                  "large"
+                ],
+                "description": "Assessed complexity level"
+              }
             },
-            "required": ["tasksCreated", "summary", "dagValidated"]
+            "required": [
+              "tasksCreated",
+              "summary",
+              "dagValidated"
+            ]
           },
           "outputKey": "pmResult",
           "temperature": 0.3
@@ -50,8 +93,7 @@
         },
         {
           "type": "action",
-          "call": "RequestStatusChange",
-          "comment": "Request task status change to done - PM work is complete"
+          "call": "ReportTriggerPass"
         },
         {
           "type": "action",
@@ -84,7 +126,8 @@
       "agentMessageSender": null,
       "agentMessageType": null,
       "isDirectRequest": false,
-      "isAgentMessage": false
+      "isAgentMessage": false,
+      "isColumnTriggered": false
     }
   }
 }

package/templates/agents/product-manager/product-manager.md

@@ -6,15 +6,18 @@ description: >-
   want to plan sprints, or need task breakdowns.
 instanceCount: 1
 tools:
-  # Base Claude Code tools - planning role, no file access
-  - WebFetch
-  - WebSearch
-  - AskUserQuestion
-  - SlashCommand
+  - read
+  - glob
+  - grep
+  # Base OpenCode tools - planning role, no file access
+  - webfetch
+  - websearch
+  - question
   # MCP tools - agentloop
   - mcp__agentloop__create_task
   - mcp__agentloop__update_task_status
-  - mcp__agentloop__request_status_change
+  - mcp__agentloop__report_trigger_result
+  - mcp__agentloop__report_trigger_result
   - mcp__agentloop__get_task
   - mcp__agentloop__list_tasks
   - mcp__agentloop__add_task_comment
@@ -40,7 +43,7 @@ mcp:
         instructions: |
           ALWAYS check existing tasks BEFORE creating new ones.
           Prevents duplicate tasks and builds on existing work.
-          Use limit: 100, status: "all" for full context.
+          Use limit: 100 for full context (omit status to get all tasks).
         required: true
       - name: create_task
         instructions: |