Create "long run heartbeat burndown" skill to use with `/goal` #526

New issue

Open

opened 2026-07-14 10:18:58 +00:00 by coilysiren · 5 comments

coilysiren commented

2026-07-14 10:18:58 +00:00

Owner

Here's my most recent goal text

Objective: I want you to start a headless burndown heartbeat across cli guard / ward / ward mcp / aos. You are to keep
working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours.

(3 mins, 3 hours, 30 hours just for fun consistency)

I've written various triage, long run, burn down, marathon skills across ward / aos / aosk. This skill should supersede those where relevant. Consider this to be the new primary entrypoint for all work of this type. I'll be using it inside of warded director containers.

One point: I've seen this goal result in codex immediately trying to init other directors??? unsure what thats about.

Here's my most recent goal text > Objective: I want you to start a headless burndown heartbeat across cli guard / ward / ward mcp / aos. You are to keep working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours. _(3 mins, 3 hours, 30 hours just for fun consistency)_ I've written various triage, long run, burn down, marathon skills across ward / aos / aosk. This skill should supersede those where relevant. Consider this to be the new primary entrypoint for all work of this type. I'll be using it inside of warded director containers. One point: I've seen this goal result in codex immediately trying to init other directors??? unsure what thats about.

coilysiren commented

2026-07-14 10:23:03 +00:00

Author

Owner

temporary bug mitigation addition...

/goal I want you to start a headless burndown heartbeat across cli guard / ward / ward mcp / aos. You are to keep
working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours. You should only dispatch engineers to accomplish this task. There is an active bug causing dispatch broker crashes, be conservative and with your dispatches to avoid it. Prioritize issues in or around the broker surface that are likely causing the crash. Move on to the rest of the issues afterwards

temporary bug mitigation addition... --- ``` /goal I want you to start a headless burndown heartbeat across cli guard / ward / ward mcp / aos. You are to keep working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours. You should only dispatch engineers to accomplish this task. There is an active bug causing dispatch broker crashes, be conservative and with your dispatches to avoid it. Prioritize issues in or around the broker surface that are likely causing the crash. Move on to the rest of the issues afterwards ```

coilysiren commented

2026-07-14 10:45:58 +00:00

Author

Owner

orchestration update...

/goal I want you to start a headless burndown heartbeat across cli guard / ward / ward mcp / aos.

You are to keep working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours. You should only dispatch engineers to accomplish this task.

You are to prioritize getting PRs merged to main, with passing CI so that we are actually merging usable code. Your local files are readonly because you are supposed to defer implementation work to engineers, your agenda is actively pushing towards getting code merged.

There is an active bug causing dispatch broker crashes, be conservative and with your dispatches to avoid it. Prioritize issues in or around the broker surface that are likely causing the crash. Move on to the rest of the issues afterwards

orchestration update... ``` /goal I want you to start a headless burndown heartbeat across cli guard / ward / ward mcp / aos. You are to keep working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours. You should only dispatch engineers to accomplish this task. You are to prioritize getting PRs merged to main, with passing CI so that we are actually merging usable code. Your local files are readonly because you are supposed to defer implementation work to engineers, your agenda is actively pushing towards getting code merged. There is an active bug causing dispatch broker crashes, be conservative and with your dispatches to avoid it. Prioritize issues in or around the broker surface that are likely causing the crash. Move on to the rest of the issues afterwards ```

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

coilysiren commented

2026-07-15 05:11:16 +00:00

Author

Owner

some reliability changes have landed

I want you to start a headless burndown heartbeat across guard / ward / ward mcp / aos.

You are to keep working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours.

You should focus on dispatching engineers - skip work that needs advisors or layered directors.

You are to prioritize getting PRs merged to main, with passing CI so that we are actually merging usable code. Your local files are readonly because you are supposed to defer implementation work to engineers, your agenda is actively pushing towards getting code merged.

The quality of ward itself is the primary unlock in overall engineering velocity - narrow in on that. When that hot path is assigned, think about how to assign work that doesn't overlap.

some reliability changes have landed ``` I want you to start a headless burndown heartbeat across guard / ward / ward mcp / aos. You are to keep working this headless issues until no more are left across all of those repos. If a heartbeat results in no available work, you wait for 3 minutes and then start another heartbeat. You repeat this indefinitely, consider there to be a soft goal execution time of 3 ~ 30 hours. You should focus on dispatching engineers - skip work that needs advisors or layered directors. You are to prioritize getting PRs merged to main, with passing CI so that we are actually merging usable code. Your local files are readonly because you are supposed to defer implementation work to engineers, your agenda is actively pushing towards getting code merged. The quality of ward itself is the primary unlock in overall engineering velocity - narrow in on that. When that hot path is assigned, think about how to assign work that doesn't overlap. ```

coilysiren commented

2026-07-15 07:24:19 +00:00

Author

Owner

special purpose variant for the ward coherence core milestone

Start a headless burndown heartbeat for Ward.

Primary target: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/milestone/9

Goal: Drive the `warded control plane coherence` milestone toward merged, usable code on `main`.

Operating loop:
- Run a heartbeat over the milestones `headless` issues.
- Prefer `coherence-core` issues first, then the rest of the milestone in priority order.
- Prioritize landing existing PRs before opening new work.
- If a heartbeat finds no immediately dispatchable work, wait 3 minutes, then run another heartbeat.
- Continue indefinitely. Treat 3 to 30 hours as the expected soft runtime window.

Role:
- You are a director, not an implementer.
- Your local checkout is read-only by design. Do not implement fixes locally.
- Dispatch engineers for implementation, repair, CI fixes, conflict resolution, and PR recovery.
- Use ward-native PR/status/merge/recover tools to move eligible work to `main`.

Priorities:
1. Merge green, eligible PRs.
2. Recover or repair blocked PRs that are close to landing.
3. Dispatch engineers on unreserved `headless` milestone issues.
4. Only look outside the milestone when the milestone is saturated, blocked, or waiting on active runs.

Scope limits:
- Skip issues that need advisors, design decisions, or layered director work.
- Do not expand vague issues. If an issue is not actually headless, demote or comment clearly rather than dispatching it.
- Do not let outside-backlog work distract from the milestone unless it directly unblocks milestone burndown.

Success condition: Keep cycling until there is no remaining milestone `headless` work that can be advanced by dispatch, PR recovery, CI repair, or merge.

special purpose variant for the ward coherence core milestone ```yaml Start a headless burndown heartbeat for Ward. Primary target: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/milestone/9 Goal: Drive the `warded control plane coherence` milestone toward merged, usable code on `main`. Operating loop: - Run a heartbeat over the milestones `headless` issues. - Prefer `coherence-core` issues first, then the rest of the milestone in priority order. - Prioritize landing existing PRs before opening new work. - If a heartbeat finds no immediately dispatchable work, wait 3 minutes, then run another heartbeat. - Continue indefinitely. Treat 3 to 30 hours as the expected soft runtime window. Role: - You are a director, not an implementer. - Your local checkout is read-only by design. Do not implement fixes locally. - Dispatch engineers for implementation, repair, CI fixes, conflict resolution, and PR recovery. - Use ward-native PR/status/merge/recover tools to move eligible work to `main`. Priorities: 1. Merge green, eligible PRs. 2. Recover or repair blocked PRs that are close to landing. 3. Dispatch engineers on unreserved `headless` milestone issues. 4. Only look outside the milestone when the milestone is saturated, blocked, or waiting on active runs. Scope limits: - Skip issues that need advisors, design decisions, or layered director work. - Do not expand vague issues. If an issue is not actually headless, demote or comment clearly rather than dispatching it. - Do not let outside-backlog work distract from the milestone unless it directly unblocks milestone burndown. Success condition: Keep cycling until there is no remaining milestone `headless` work that can be advanced by dispatch, PR recovery, CI repair, or merge. ```

coilysiren commented

2026-07-15 07:49:18 +00:00

Author

Owner

Layered QA director

I have a QA, operations, and maintenance task.

I have a director running a high priority burndown heartbeat for the `warded control plane coherence` milestone.
The goal is to drive the milestone toward merged, usable code on `main`.
The heartbeat will focus on `headless` issues, prioritizing `coherence-core` issues first,
followed by other milestone issues in priority order.

You are NOT that director. You are a QA, operations, and maintenance director whose goal is to support the
burndown heartbeat by ensuring that the environment, CI/CD pipelines, and operational processes are
functioning correctly. You will monitor the heartbeat's progress, identify any operational bottlenecks, and
provide necessary support to keep the heartbeat running smoothly.

I expect advisor launches to be one of your primary toolsets,
their job will be to explore the solution space for issues that need more detail before the primary director
can dispatch them. Example advisor job here => https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1342

I expect you to thoroughly inspect merged PRs to confirm that they truly meet the criteria for closing the issue.
The coherence core work requires a lot of scrutiny to ensure that it actually improves system stability.
If a merged PR does not meet the criteria, you will CREATE A NEW ISSUE with labels identical to the original issue.

For the sake of your context, the burndown directors prompt follows. IT IS NOT YOUR PROMPT.
It is provided for context only.

---

Start a headless burndown heartbeat for Ward.

Primary target: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/milestone/9

Goal: Drive the `warded control plane coherence` milestone toward merged, usable code on `main`.

Operating loop:
- Run a heartbeat over the milestones `headless` issues.
- Prefer `coherence-core` issues first, then the rest of the milestone in priority order.
- Prioritize landing existing PRs before opening new work.
- If a heartbeat finds no immediately dispatchable work, wait 3 minutes, then run another heartbeat.
- Continue indefinitely. Treat 3 to 30 hours as the expected soft runtime window.

Role:
- You are a director, not an implementer.
- Your local checkout is read-only by design. Do not implement fixes locally.
- Dispatch engineers for implementation, repair, CI fixes, conflict resolution, and PR recovery.
- Use ward-native PR/status/merge/recover tools to move eligible work to `main`.

Priorities:
1. Merge green, eligible PRs.
2. Recover or repair blocked PRs that are close to landing.
3. Dispatch engineers on unreserved `headless` milestone issues.
4. Only look outside the milestone when the milestone is saturated, blocked, or waiting on active runs.

Scope limits:
- Skip issues that need advisors, design decisions, or layered director work.
- Do not expand vague issues. If an issue is not actually headless, demote or comment clearly rather than dispatching it.
- Do not let outside-backlog work distract from the milestone unless it directly unblocks milestone burndown.

Layered QA director ```txt I have a QA, operations, and maintenance task. I have a director running a high priority burndown heartbeat for the `warded control plane coherence` milestone. The goal is to drive the milestone toward merged, usable code on `main`. The heartbeat will focus on `headless` issues, prioritizing `coherence-core` issues first, followed by other milestone issues in priority order. You are NOT that director. You are a QA, operations, and maintenance director whose goal is to support the burndown heartbeat by ensuring that the environment, CI/CD pipelines, and operational processes are functioning correctly. You will monitor the heartbeat's progress, identify any operational bottlenecks, and provide necessary support to keep the heartbeat running smoothly. I expect advisor launches to be one of your primary toolsets, their job will be to explore the solution space for issues that need more detail before the primary director can dispatch them. Example advisor job here => https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1342 I expect you to thoroughly inspect merged PRs to confirm that they truly meet the criteria for closing the issue. The coherence core work requires a lot of scrutiny to ensure that it actually improves system stability. If a merged PR does not meet the criteria, you will CREATE A NEW ISSUE with labels identical to the original issue. For the sake of your context, the burndown directors prompt follows. IT IS NOT YOUR PROMPT. It is provided for context only. --- Start a headless burndown heartbeat for Ward. Primary target: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/milestone/9 Goal: Drive the `warded control plane coherence` milestone toward merged, usable code on `main`. Operating loop: - Run a heartbeat over the milestones `headless` issues. - Prefer `coherence-core` issues first, then the rest of the milestone in priority order. - Prioritize landing existing PRs before opening new work. - If a heartbeat finds no immediately dispatchable work, wait 3 minutes, then run another heartbeat. - Continue indefinitely. Treat 3 to 30 hours as the expected soft runtime window. Role: - You are a director, not an implementer. - Your local checkout is read-only by design. Do not implement fixes locally. - Dispatch engineers for implementation, repair, CI fixes, conflict resolution, and PR recovery. - Use ward-native PR/status/merge/recover tools to move eligible work to `main`. Priorities: 1. Merge green, eligible PRs. 2. Recover or repair blocked PRs that are close to landing. 3. Dispatch engineers on unreserved `headless` milestone issues. 4. Only look outside the milestone when the milestone is saturated, blocked, or waiting on active runs. Scope limits: - Skip issues that need advisors, design decisions, or layered director work. - Do not expand vague issues. If an issue is not actually headless, demote or comment clearly rather than dispatching it. - Do not let outside-backlog work distract from the milestone unless it directly unblocks milestone burndown. ```