From 7cbc77b7ddcab6ed3e489f4b2c870d0b41d35271 Mon Sep 17 00:00:00 2001 From: Andrea Zanenghi Date: Wed, 14 Oct 2026 11:05:01 +0200 Subject: [PATCH] feat(deliver): build each issue of a program in a fresh subagent --- .changeset/deliver-subagent-per-issue.md | 5 +++++ skills/audit/SKILL.md | 1 + skills/deliver/SKILL.md | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) create mode 100644 .changeset/deliver-subagent-per-issue.md diff --git a/.changeset/deliver-subagent-per-issue.md b/.changeset/deliver-subagent-per-issue.md new file mode 100644 index 0000000..2c39bb4 --- /dev/null +++ b/.changeset/deliver-subagent-per-issue.md @@ -0,0 +1,5 @@ +--- +'aplus': patch +--- + +deliver: build each issue of a program in a fresh subagent and keep only its output block, so long audit runs stay small diff --git a/skills/audit/SKILL.md b/skills/audit/SKILL.md index 68ea750..0668209 100644 --- a/skills/audit/SKILL.md +++ b/skills/audit/SKILL.md @@ -97,6 +97,7 @@ node --experimental-strip-types /scripts/new-audit.mts --sy Run the program's open change issues with [deliver](../deliver/SKILL.md). Within an audit: - Deliver's draft folder is the program's `issues/`, so its drafts share the `manifest.json`. +- Pass each issue's subagent its draft path and the audit entries its `audit` list names. Between issues, this context holds the `manifest.json` and each issue's output block. - Before building an issue, match it to its draft in `issues/` (`manifest.json` maps each draft key to its issue) and read the audit entries that draft's `audit` list names. They are the steps, and may change while building; the issue's acceptance is what must hold. - A finding that is a program of its own stays a decision draft; propose an audit for it at hand off. - Keep audit keys and audit dir paths out of branch names, titles and bodies. diff --git a/skills/deliver/SKILL.md b/skills/deliver/SKILL.md index f120ff5..4dc7735 100644 --- a/skills/deliver/SKILL.md +++ b/skills/deliver/SKILL.md @@ -20,7 +20,7 @@ Automatic from spec to PR, every gate included. It waits for the user only to re 1. **Start.** A ticket goes to [triage](../triage/SKILL.md): a `real bug` goes to step 3, a `request` to define. An idea goes to [define](../define/SKILL.md). An issue with acceptance criteria, or a program of them, goes to step 3. 2. **Review.** Ask define for the drafts with the spec: the spec's issue when the project needs one, every issue of a program, and the ticket edit for a ticket. Define's review is the run's one review; create the issues and publish the edit the user approves. -3. **Run each issue** through steps 4 to 8, in "blocked by" order, without asking between them unless the user asked for pauses. A decision issue, and the work it blocks, waits for a maintainer. An issue too big to review as one PR, such as one sized `outcome`, ships as a stack: its pass through steps 4 to 8 runs once per reviewable slice, each branch on the slice below ([stacks](../create-pr/references/stacks.md)). +3. **Run each issue** through steps 4 to 8, in "blocked by" order, without asking between them unless the user asked for pauses. In a program, hand each issue's pass to a fresh subagent briefed with the issue, its draft and the project instructions, and keep only its output block here, so context stays small. A decision issue, and the work it blocks, waits for a maintainer. An issue too big to review as one PR, such as one sized `outcome`, ships as a stack: its pass through steps 4 to 8 runs once per reviewable slice, each branch on the slice below ([stacks](../create-pr/references/stacks.md)). 4. **Branch** as [create-pr](../create-pr/SKILL.md) says. Set in progress as the host skill's board says. 5. **Build.** - A bug: its [Gherkin scenario](../gherkin/SKILL.md#a-bugs-scenario), in the PR body when the ticket has none, then [debug](../debug/SKILL.md).