build: the supervisor and primary agent now use a script to mroe effeciently wait
This commit is contained in:
@@ -93,16 +93,16 @@ Startup steps:
|
||||
1. Parse and validate prompt parameters
|
||||
2. Fallback to environment variables, and fetch needed variables, for any missing settings
|
||||
3. If any required parameters are still missing or malformed, exit immediately and report the error
|
||||
4. For each supervisor in the managed list, check whether a session with its tag already exists using `async-agent-util`:
|
||||
- If no session exists → launch a new one (see "Launching a supervisor" below)
|
||||
- If a session exists and is healthy → log that it is already running, take no action
|
||||
- If a session exists but is unhealthy → stop it via `async-agent-util` and launch a fresh one
|
||||
5. Start the main loop (see section "Main loop"), which must run forever until this process is killed
|
||||
4. For each supervisor in the managed list, check whether a session with its tag already exists using `async-agent-util` and stop it if its busy, then delete the session, again using `async-agent-util` to carry this out.
|
||||
5. For each supervisor in the managed list, bring up the agent via `async-agent-util`.
|
||||
|
||||
|
||||
**CRITICAL:** After the startup sequence above completes successfully immediately start the main loop (see section "Main loop"), which must run forever until this process is killed. Do **not** under any circumstances stop to summerize or pause for further instructions, and do not ask questions.
|
||||
|
||||
### Main loop
|
||||
|
||||
1. Call `bash("sleep 300", timeout=360000)` — wait 5 minutes
|
||||
2. For each supervisor in the managed list, perform a health check cycle (see "Health check cycle" below)
|
||||
1. Load the skill `auto-agents-system` and run, via the bash tool, the script named `session_wait_till_supervisor_idle` from the one of the launched supervisors to become idle. Ensure when calling `session_wait_till_supervisor_idle` that you set the `--expected-supervisors` argument to the number of supervisors in the managed list, and `--timeout` to `{idle_interval}`.
|
||||
2. For each supervisor in the managed list, perform a health check cycle (see "Health check cycle" below), ensure before moving on all supervisors have busy sessions and are in a healthy state.
|
||||
3. Go to step 1
|
||||
|
||||
### Health check cycle
|
||||
|
||||
@@ -191,13 +191,17 @@ Invoke the `supervisor` subagent as a blocking call via the Task tool, passing i
|
||||
|
||||
##### Prompt construction
|
||||
|
||||
Build the supervisor prompt by writing it to `/tmp/imp-supervisor-prompt.txt` using the Write tool. This eliminates variable substitution errors. Construct the file with the following content, substituting your ACTUAL resolved values for each credential line at the top, and the literal static text below unchanged:
|
||||
|
||||
The supervisor reads ALL credentials (Forgejo PAT, URL, owner, repo, git identity) directly from environment variables at startup. Do NOT include credential lines in the prompt — they will be resolved by the supervisor itself.
|
||||
Build the supervisor prompt by writing it to `/tmp/imp-supervisor-prompt.txt` using the Write tool. This eliminates variable substitution errors. Construct the file with the following content, substituting your **actual** resolved values for each line that has a variable substitution (of the form `{variable}`), using the template below replacing **only** the values marked as `{variable}` leaving all text as literal, non-summarized text.
|
||||
|
||||
Use the following prompt template to construct your your prompt for the `supervisor` subagent, being sure to substitute `{variable}` with the variables value:
|
||||
|
||||
```
|
||||
Repository base url: `{forgejo_url}`
|
||||
Repository owner: `{forgejo_owner}`
|
||||
Repository name: `{forgejo_repo}`
|
||||
forgejo pat: `{forgejo_pat}`
|
||||
forgejo username: `{forgejo_username}`
|
||||
forgejo password: `{forgejo_password}`
|
||||
tag prefix: `{tag_prefix}`
|
||||
worker tag fetch algorithm:
|
||||
1. Start by copying the worker tag prefix to the new variable for the worker tag called `worker_tag`
|
||||
@@ -213,7 +217,6 @@ worker parameters:
|
||||
- `work_number`: The PR or issue number to handle
|
||||
- `work_title`: The title of the PR or issue
|
||||
- `escalation_tier`: Always pass `1` — the worker determines the actual tier itself
|
||||
- `tier_agent`: Always pass `tier-haiku` — the worker determines the actual tier itself
|
||||
- `is_first_attempt`: Always pass `true` — the worker determines this itself by reading comments
|
||||
|
||||
worker parameter fetch algorithms:
|
||||
@@ -221,18 +224,15 @@ worker parameter fetch algorithms:
|
||||
- `work_number`: Taken directly from the task item (PR or issue number)
|
||||
- `work_title`: Taken directly from the task item (PR or issue title)
|
||||
- `escalation_tier`: Always `1` (the worker's dispatcher mode reads comments and adjusts the tier before forwarding)
|
||||
- `tier_agent`: Always `tier-haiku` (the worker's dispatcher mode may override this based on estimator results)
|
||||
- `is_first_attempt`: Always `true` (the worker's dispatcher mode determines the actual value)
|
||||
|
||||
task groups in priority order: `failing_ci_pr`, `request_changes_pr`, `new_issue`
|
||||
|
||||
each task group's fetch algorithm:
|
||||
PR scripts are invoked using credentials the supervisor resolved from env vars at startup: `npx --yes tsx .opencode/skills/auto-agents-system/scripts/<SCRIPT>.ts --url $FORGEJO_URL --pat $FORGEJO_PAT --owner $FORGEJO_OWNER --repo $FORGEJO_REPO`
|
||||
(The supervisor must substitute the actual env var values it read during startup — do NOT pass literal `$FORGEJO_URL` strings to the script.)
|
||||
CRITICAL: Always pipe through jq to keep output compact. Without jq the raw JSON will overflow your context window.
|
||||
- `failing_ci_pr`: script = `list_prs_ci_failing`, jq filter: `| jq '[.[] | {number, title, branch: .head.ref, head_sha: .head.sha, ci_status, stale_state, approvals_count}]'`
|
||||
- `request_changes_pr`: script = `list_prs_changes_requested`, jq filter: `| jq '[.[] | {number, title, branch: .head.ref, head_sha: .head.sha, ci_status, stale_state, approvals_count}]'`
|
||||
- `new_issue`: script = `list_issues`, jq filter: `| jq '[.[] | {number, title, priority_rank, priority_label, milestone_due: .milestone_due_sort}]'`
|
||||
CRITICAL: Always pipe through jq to keep output compact. Without jq the raw JSON will overflow your context window. For example: `| jq '[.[] | {number, title, branch: .head.ref, head_sha: .head.sha, ci_status, stale_state, approvals_count}]`
|
||||
- `failing_ci_pr`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_ci_failing` from the skill to list the PRs for this task group.
|
||||
- `request_changes_pr`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_changes_requested` from the skill to list the PRs for this task group.
|
||||
- `new_issue`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_issues` from the skill to list the issues for this task group.
|
||||
|
||||
The prompt body to pass to workers you spawn:
|
||||
```
|
||||
|
||||
@@ -190,13 +190,17 @@ Invoke the `supervisor` subagent as a blocking call via the Task tool, passing i
|
||||
|
||||
##### Prompt construction
|
||||
|
||||
Build the supervisor prompt by writing it to `/tmp/prmrg-supervisor-prompt.txt` using the Write tool. This eliminates variable substitution errors. Construct the file with the following content, substituting your ACTUAL resolved values for each credential line at the top, and the literal static text below unchanged:
|
||||
|
||||
The supervisor reads ALL credentials (Forgejo PAT, URL, owner, repo, git identity) directly from environment variables at startup. Do NOT include credential lines in the prompt — they will be resolved by the supervisor itself.
|
||||
Build the supervisor prompt by writing it to `/tmp/merg-supervisor-prompt.txt` using the Write tool. This eliminates variable substitution errors. Construct the file with the following content, substituting your ACTUAL resolved values for each line that has a variable substitution (of the form `{variable}`), using the template below replacing **only** the values marked as `{variable}` leaving all text as literal, non-summarized text.
|
||||
|
||||
Use the following prompt template to construct your your prompt for the `supervisor` subagent, being sure to substitute `{variable}` with the variables value:
|
||||
|
||||
```
|
||||
Repository base url: `{forgejo_url}`
|
||||
Repository owner: `{forgejo_owner}`
|
||||
Repository name: `{forgejo_repo}`
|
||||
forgejo pat: `{forgejo_pat}`
|
||||
forgejo username: `{forgejo_username}`
|
||||
forgejo password: `{forgejo_password}`
|
||||
tag prefix: `{tag_prefix}`
|
||||
worker tag fetch algorithm:
|
||||
1. Start by copying the tag prefix to the new variable for the worker tag called `worker_tag`
|
||||
@@ -229,14 +233,12 @@ worker parameter fetch algorithms:
|
||||
task groups in priority order: `ready_to_merge`, `stale_no_conflicts_approved`, `stale_has_conflicts_approved`, `stale_no_conflicts_not_approved`, `stale_has_conflicts_not_approved`
|
||||
|
||||
each task group's fetch algorithm:
|
||||
ALL scripts are invoked using credentials the supervisor resolved from env vars at startup: `npx --yes tsx .opencode/skills/auto-agents-system/scripts/<SCRIPT>.ts --url $FORGEJO_URL --pat $FORGEJO_PAT --owner $FORGEJO_OWNER --repo $FORGEJO_REPO`
|
||||
(The supervisor must substitute the actual env var values it read during startup — do NOT pass literal `$FORGEJO_URL` strings to the script.)
|
||||
CRITICAL: Always pipe through jq to keep output compact: `| jq '[.[] | {number, title, branch: .head.ref, head_sha: .head.sha, base_ref: .base.ref, merge_base, mergeable, stale_state, ci_status, approvals_count, priority_rank}]'`
|
||||
- `ready_to_merge`: script = `list_prs_ready_to_merge`
|
||||
- `stale_no_conflicts_approved`: script = `list_prs_stale_clean`
|
||||
- `stale_has_conflicts_approved`: script = `list_prs_stale_conflicts`
|
||||
- `stale_no_conflicts_not_approved`: script = `list_prs_needs_review_not_stale`
|
||||
- `stale_has_conflicts_not_approved`: script = `list_prs_needs_review_stale_conflicts`
|
||||
- `ready_to_merge`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_ready_to_merge` from the skill to list the PRs for this task group.
|
||||
- `stale_no_conflicts_approved`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_stale_clean` from the skill to list the PRs for this task group.
|
||||
- `stale_has_conflicts_approved`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_stale_conflicts` from the skill to list the PRs for this task group.
|
||||
- `stale_no_conflicts_not_approved`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_needs_review_not_stale` from the skill to list the PRs for this task group.
|
||||
- `stale_has_conflicts_not_approved`: Load the skill `auto-agents-system` and run, via the bash tool, the script named `list_prs_needs_review_stale_conflicts` from the skill to list the PRs for this task group.
|
||||
|
||||
The prompt body to pass to workers you spawn:
|
||||
```
|
||||
|
||||
@@ -253,9 +253,11 @@ Invoke the `git-isolator-util` subagent via the Task tool, passing it repository
|
||||
Repository base url: `{forgejo_url}`
|
||||
Repository owner: `{forgejo_owner}`
|
||||
Repository name: `{forgejo_repo}`
|
||||
forgejo pat: `{forgejo_pat}`
|
||||
forgejo username: `{forgejo_username}`
|
||||
forgejo password: `{forgejo_password}`
|
||||
agent name: `pr-merge-worker`
|
||||
create branch: yes
|
||||
forgejo pat: `{forgejo_pat}`
|
||||
Branch to clone: `{branch_name}`
|
||||
|
||||
Create an isolated git clone given the above parameters.
|
||||
|
||||
@@ -104,7 +104,7 @@ Startup steps:
|
||||
3. If no task groups have any pending tasks, meaning `fetched_tasks` would be empty, so call the bash tool as `bash("sleep {idle_interval}", timeout=360000)` then go to step 8. Do **not** under any circumstances give a status report or return here, execute the bash command then immediately continue.
|
||||
4. Determine how many active worker agents we have by asking the subagent `async-agent-util` to find sessions by prefix `{tag_prefix}` with `--exclude-supervisor` and counting the results. We will call this value `busy_slots`.
|
||||
5. Determine how many worker slots are available by computing: `available_slots` = `{max_pool} - {busy_slots}`. If `{availible_slots}` is a negative number then just set it to `0` instead.
|
||||
6. If no worker slots are available, in other words `{availible_slots}` is equal to or less than `0` then call the bash tool as `bash("sleep {idle_interval}", timeout=360000)`, then go to step 8. Do **not** under any circumstances give a status report or return here, execute the bash command then immediately continue.
|
||||
6. If no worker slots are available, in other words `{availible_slots}` is equal to or less than `0` then Load the skill `auto-agents-system` and run, via the bash tool, the script named `session_wait_till_worker_idle` from the skill to wait for availible slots. Ensure when calling `session_wait_till_worker_idle` that you set the `--tag-prefix` argument to `{tag_prefix}`, and `--pool-size` to `{max_pool}` and `--timeout` to `{idle_interval}`. Once the script call returns go to step 8
|
||||
7. For each available slot make a corresponding call to `async-agent-util` to launch the `{worker_subagent_name}` subagent, and ensure it is tasked with completing one of the tasks from the `fetched_tasks` list, ensuring each subagent gets a unique task to work on from the list. Make these calls in parallel, one for each fetched task from the `fetched_tasks` list without launching more than `{availible_slots}` number of subagents. Make the Task tool call NOW — do not describe it, do not plan it, just call it. After all the calls to `async-agent-util` return, proceed to the next step.
|
||||
8. Monitor all running workers — see the section below titled "Workers" and specifically subsection "How to monitor".
|
||||
9. If `{status_interval}` seconds have elapsed since the last status update was generated, generate a new status update now
|
||||
|
||||
Reference in New Issue
Block a user