@bastani/atomic 0.9.12 → 0.9.13-alpha.2

package/dist/builtin/subagents/agents/worker.md

@@ -26,7 +26,7 @@ Do not end with a question requiring the supervisor to choose before work can co
 
 ## Work and validation
 
-Use the provided tools directly. Use `bash` for inspection and appropriate non-destructive validation. Keep `progress.md` accurate when requested. If chain instructions specify files to read, progress tracking, or an output artifact, follow them.
+Use the provided tools directly. Use `bash` for inspection and appropriate non-destructive validation. Keep `progress.md` accurate when requested. If instructions specify files to read, progress tracking, or an output artifact, follow them.
 
 If edits were required but none were made, do not claim success: make them, escalate a blocker, or explicitly report that no edits were made. Before reporting progress, audit each claim against a tool result from this session. Report only work you can point to evidence for; say so explicitly when something is unverified.
 

package/dist/builtin/subagents/package.json

@@ -1,8 +1,8 @@
 {
   "name": "@bastani/subagents",
-  "version": "0.9.12",
+  "version": "0.9.13-alpha.2",
   "private": true,
-  "description": "Atomic extension for delegating tasks to subagents with chains, parallel execution, and background runs. Fork of: https://github.com/nicobailon/pi-subagents",
+  "description": "Atomic extension for delegating tasks to subagents with parallel execution and background runs. Fork of: https://github.com/nicobailon/pi-subagents",
   "contributors": [
     "Norin Lavaee",
     "Alex Lavaee"
@@ -38,9 +38,9 @@
   },
   "peerDependencies": {
     "@bastani/atomic": "*",
-    "@earendil-works/pi-agent-core": "^0.83.0",
-    "@earendil-works/pi-ai": "^0.83.0",
-    "@earendil-works/pi-tui": "^0.83.0"
+    "@earendil-works/pi-agent-core": "^0.84.1",
+    "@earendil-works/pi-ai": "^0.84.1",
+    "@earendil-works/pi-tui": "^0.84.1"
   },
   "peerDependenciesMeta": {
     "@bastani/atomic": {

package/dist/builtin/subagents/prompts/parallel-context-build.md

@@ -12,14 +12,14 @@ $@
 
 ## Constraints and tools
 
-Use the `subagent` tool in chain mode with one parallel step so relative outputs stay under the temporary chain directory. Use `context: "fresh"` unless I explicitly request forked context. Give every task a distinct `output` path, `label`, and `as` name, such as:
+Use the `subagent` tool in top-level parallel mode. Use `context: "fresh"` unless I explicitly request forked context. Give every task a distinct `output` path, such as:
 
 - `context-build/where-it-lives.md`
 - `context-build/how-it-works.md`
 - `context-build/existing-patterns.md`
 - `context-build/prior-research.md`
 
-Use one phase such as `phase: "Context build"` so async status is readable. A synthesis step can cite `{outputs.requestScope}`, `{outputs.codebasePatterns}`, and `{outputs.validationRisks}` when available, using `{previous}` only for the whole fan-in. Do not persist context artifacts in the repository unless I explicitly request it.
+Do not persist context artifacts in the repository unless I explicitly request it.
 
 Read or fetch any supplied URL, issue link, file path, plan path, or freeform request before assigning angles, and pass that target into every specialist task. Choose two to four specialists according to the request:
 

package/dist/builtin/subagents/prompts/parallel-handoff-plan.md

@@ -12,17 +12,17 @@ $@
 
 ## Constraints and tools
 
-First read or fetch every URL, issue, PR, screenshot, plan, doc, or local file named in the request; these define primary scope. Use the `subagent` tool in chain mode with `context: "fresh"` unless I explicitly request forked context. Run one parallel discovery step, then synthesize parent-side rather than launching a synthesizer subagent.
+First read or fetch every URL, issue, PR, screenshot, plan, doc, or local file named in the request; these define primary scope. Use a top-level parallel call with `context: "fresh"` unless I explicitly request forked context, then synthesize parent-side rather than launching a synthesizer subagent.
 
 Choose specialists by evidence need:
 
-- Use `codebase-online-researcher` when external projects, libraries, docs, APIs, recent changes, or best practices could shape the plan. It should inspect linked projects, docs, issues, examples, source, or prompt guidance; identify behavior, APIs, implementation files, constraints, and transferable ideas; use `fetch_content` first, then `/llms.txt`, then `Accept: text/markdown`, and fall back to `browser` only for required JS or auth; persist high-value sources to `research/web/<YYYY-MM-DD>-<topic>.md`; and return links, repo paths, evidence, risks, and implementation implications.
+- Use `codebase-online-researcher` when external projects, libraries, docs, APIs, recent changes, or best practices could shape the plan. It should inspect linked projects, docs, issues, examples, source, or prompt guidance; identify behavior, APIs, implementation files, constraints, and transferable ideas; use `fetch_content` first, then `/llms.txt`, then `Accept: text/markdown`, and fall back to `playwright-cli` only for required JS or auth; persist high-value sources to `research/web/<YYYY-MM-DD>-<topic>.md`; and return links, repo paths, evidence, risks, and implementation implications.
 - Use `codebase-locator` for non-trivial code changes to map relevant local files, tests, fixtures, and configs by purpose.
 - Use `codebase-analyzer` when local behavior matters to trace the located implementation, control flow, transformations, and constraints with `file:line` citations. Locator and analyzer cover where the work lives and how it works without overlap.
 - Add `codebase-pattern-finder` when analogous implementations or conventions could shape the plan; include useful snippets with `file:line` references.
 - Add `codebase-research-locator` then `codebase-research-analyzer` when prior `research/` or `specs/` may apply. The locator finds relevant dated docs; the analyzer extracts current decisions, constraints, and lessons while flagging superseded guidance. Run them sequentially, or pair them in the parallel step with distinct outputs when the dependency is already resolved.
 
-Give tasks distinct `output` paths, `label` values, and `as` names under the chain directory, for example:
+Give tasks distinct `output` paths, for example:
 
 - `handoff/external-reference.md`
 - `handoff/local-files.md`
@@ -30,7 +30,7 @@ Give tasks distinct `output` paths, `label` values, and `as` names under the cha
 - `handoff/local-patterns.md`
 - `handoff/prior-research.md`
 
-Use phases such as `Research`, `Local context`, and `Synthesis` for readable async status. In synthesis, prefer `{outputs.externalReference}`, `{outputs.localContext}`, and `{outputs.implementationStrategy}` when available; use `{previous}` only for the whole parallel fan-in. Do not persist these artifacts in the repository unless I explicitly request it.
+In synthesis, use the saved task outputs when available. Do not persist these artifacts in the repository unless I explicitly request it.
 
 Delegate only independent work too large for a handful of tool calls; do not delegate auditing your own work, and prefer one subagent over several. Parallelize independent reads; stay sequential when one result determines the next; synthesize after retrieval. Keep work within the requested scope.
 

package/dist/builtin/subagents/prompts/review-loop.md

@@ -16,7 +16,7 @@ Use the `subagent` tool and specialist roles rather than a generic worker or rev
 
 Default to at most 3 review rounds unless I set another cap. A round is a fresh-context inspection of the current diff after a writer pass.
 
-If the invocation requests implementation, first launch one async writer for the approved scope: `debugger` for correctness-shaped work or `code-simplifier` for refinement-shaped work. If the current diff is already the target, begin with review. Launch a clear sequence up front as an async/background chain or continue with follow-up runs after each completion. For an initial chain, pass `async: true`; because launches are non-interactive, resolve questions with me first. Use one writer against the active worktree at a time unless I explicitly request isolated worktrees.
+If the invocation requests implementation, first launch one async writer for the approved scope: `debugger` for correctness-shaped work or `code-simplifier` for refinement-shaped work. If the current diff is already the target, begin with review. Launch the planned work as an async/background set of tasks or continue with follow-up runs after each completion. Because launches are non-interactive, resolve questions with me first. Use one writer against the active worktree at a time unless I explicitly request isolated worktrees.
 
 Each review round uses fresh context. Reviewers inspect repository instructions, relevant files, and the current diff directly, without main-conversation history, and cannot edit; explicitly put `debugger` in inspect-only mode. Choose angles from the change. Common angles are correctness/regressions, failure modes, and pattern fit; add external-spec or prior-decision coverage when applicable. Prefer three strong reviewers over many vague ones.
 

package/dist/builtin/subagents/skills/subagent/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: subagent
 description: |
-  Delegate work to builtin or custom subagents with single-agent, chain,
+  Delegate work to builtin or custom subagents with single-agent,
   parallel, selective async, forked-context, and intercom-coordinated runs.
   Use for bounded specialist delegation where a single parent agent stays in
   control while subagents contribute locate, analyze, pattern-find, research,
@@ -24,7 +24,7 @@ Use this skill when bounded specialist delegation adds value and the parent shou
 - **Adversarial review**: compose read-only specialists (`codebase-analyzer`, `codebase-pattern-finder`, `debugger` in inspect-only mode, `codebase-online-researcher`) into a parallel review pass — there is no generic `reviewer` agent.
 - **Long-running bounded delegation**: selectively launch async/background runs when the result is independently useful; otherwise use foreground execution.
 - **Subagent control**: watch needs-attention signals and soft-interrupt only when a delegated run is genuinely blocked.
-- **Agent authoring**: create, update, or override agents and chains for a project.
+- **Agent authoring**: create, update, or override agents for a project.
 
 ## Tool vs Slash Commands
 
@@ -32,9 +32,7 @@ Agents can use the `subagent(...)` tool directly for execution, management, stat
 Humans often use the slash-command layer instead:
 
 - `/run` — launch a single agent
-- `/chain` — launch a chain of steps
 - `/parallel` — launch top-level parallel tasks
-- `/run-chain` — launch a saved `.chain.md` or `.chain.json` workflow
 - `/subagents-doctor` — diagnose setup, discovery, async paths, and intercom bridge state
 
 Prefer the tool when you are writing agent logic. Prefer the slash commands when you are guiding a human through an interactive flow.
@@ -59,7 +57,7 @@ Use this when the user wants adversarial review of a diff, plan, issue, file, or
 
 ### Review-loop technique
 
-Use this when the user wants implementation or current diff review to continue until reviewers stop finding fixes worth doing now. Keep the loop in the parent session: one writer (`debugger` for correctness-shaped work, `code-simplifier` for refinement-shaped work), fresh-context specialist reviewers inspect the actual repo and diff, the parent synthesizes accepted fixes, and one writer applies them. Choose foreground or async for each bounded run based on whether the parent needs its result next or has independent useful work. The parent can express the sequence up front as a background chain when that is genuinely useful, or continue with explicit follow-up subagent runs after each completion. Programmatic runs are non-interactive, so resolve only material unanswered questions before launching. Treat a writer handoff as an intermediate state, not final completion, unless the user explicitly asked for writer-only work, review-only output, or to stop after implementation. Stop when reviewers find no blockers or fixes worth doing now, remaining feedback is optional or deferred, an unapproved product/scope/architecture decision appears, or the max review-round cap is reached. Default to 3 review rounds unless the user sets a different cap. Do not loop for optional polish, and do not let children launch subagents or decide the loop outcome.
+Use this when the user wants implementation or current diff review to continue until reviewers stop finding fixes worth doing now. Keep the loop in the parent session: one writer (`debugger` for correctness-shaped work or `code-simplifier` for refinement-shaped work), fresh-context specialist reviewers inspect the actual repo and diff, the parent synthesizes accepted fixes, and one writer applies them. Choose foreground or async for each bounded run based on whether the parent needs its result next or has independent useful work. The parent can express the sequence up front as a set of parallel tasks or continue with explicit follow-up runs after each completion. Programmatic runs are non-interactive, so resolve only material unanswered questions before launching. Treat a writer handoff as an intermediate state, not final completion, unless the user explicitly asked for writer-only work, review-only output, or to stop after implementation. Stop when reviewers find no blockers or fixes worth doing now, remaining feedback is optional or deferred, an unapproved product/scope/architecture decision appears, or the max review-round cap is reached. Default to 3 review rounds unless the user sets a different cap. Do not loop for optional polish, and do not let children launch subagents or decide the loop outcome.
 
 ### Parallel research technique
 
@@ -67,39 +65,35 @@ Use this when the question needs both external evidence and local implications.
 
 ### Parallel context-build technique
 
-Use this before planning or implementation when a stronger handoff is needed. Run a chain with one parallel step of codebase specialists rather than top-level parallel tasks, so relative output files live under the temporary chain directory. Give every task a distinct output path such as `context-build/where-it-lives.md`, `context-build/how-it-works.md`, `context-build/existing-patterns.md`, and `context-build/prior-research.md`. Choose two to four specialists by angle: `codebase-locator` for the file map, `codebase-analyzer` for current behavior, `codebase-pattern-finder` for conventions, and `codebase-research-locator` → `codebase-research-analyzer` for history when the topic has prior docs. The parent synthesizes the outputs into important context, a recommended next meta-prompt, open questions, assumptions, and artifact paths.
+Use this before planning or implementation when a stronger handoff is needed. Run one top-level parallel call with codebase specialists, giving each task a distinct output path such as `context-build/where-it-lives.md`, `context-build/how-it-works.md`, `context-build/existing-patterns.md`, and `context-build/prior-research.md`. Choose two to four specialists by angle: `codebase-locator` for the file map, `codebase-analyzer` for current behavior, `codebase-pattern-finder` for conventions, and `codebase-research-locator` plus `codebase-research-analyzer` for history. The parent reads the outputs and synthesizes the important context, a recommended next meta-prompt, open questions, assumptions, and artifact paths.
 
 Example shape:
 
 ```typescript
 subagent({
-  chain: [{
-    parallel: [
-      { agent: "codebase-locator", task: "Map files, tests, fixtures, and configs that touch: ...", output: "context-build/where-it-lives.md" },
-      { agent: "codebase-analyzer", task: "Trace how this currently works with file:line refs: ...", output: "context-build/how-it-works.md" },
-      { agent: "codebase-pattern-finder", task: "Surface analogous patterns to model after: ...", output: "context-build/existing-patterns.md" }
-    ]
-  }],
+  tasks: [
+    { agent: "codebase-locator", task: "Map files, tests, fixtures, and configs that touch: ...", output: "context-build/where-it-lives.md" },
+    { agent: "codebase-analyzer", task: "Trace how this currently works with file:line refs: ...", output: "context-build/how-it-works.md" },
+    { agent: "codebase-pattern-finder", task: "Surface analogous patterns to model after: ...", output: "context-build/existing-patterns.md" }
+  ],
   context: "fresh"
 })
 ```
 
 ### Parallel handoff-plan technique
 
-Use this when the user needs a solution brief or implementation-ready handoff from an external reference plus local code context, such as "study this library behavior, inspect our codebase, then produce a writer prompt." Run a chain with a single parallel discovery step; the parent synthesizes the final handoff itself afterward (there is no dedicated synthesizer agent). The discovery group usually includes `codebase-online-researcher` for external projects/docs/prompt guidance, `codebase-locator` + `codebase-analyzer` for local code, and optionally `codebase-pattern-finder` for transferable conventions and `codebase-research-*` for prior decisions. Use distinct output paths under `handoff/`, then write `handoff/final-handoff-plan.md` yourself with the recommended approach, likely files, constraints, non-goals, validation, risks, unresolved questions, and final compact implementation-ready meta-prompt.
+Use this when the user needs a solution brief or implementation-ready handoff from an external reference plus local code context. Run one top-level parallel discovery call; the parent synthesizes the final handoff afterward. The discovery group usually includes `codebase-online-researcher` for external projects/docs/prompt guidance, `codebase-locator` and `codebase-analyzer` for local code, and optionally `codebase-pattern-finder` and `codebase-research-*` for transferable conventions and prior decisions. Use distinct output paths under `handoff/`, then write `handoff/final-handoff-plan.md` yourself with the recommended approach, likely files, constraints, non-goals, validation, risks, unresolved questions, and final compact implementation-ready meta-prompt.
 
 Example shape:
 
 ```typescript
 subagent({
-  chain: [{
-    parallel: [
-      { agent: "codebase-online-researcher", task: "Research the external reference and transferable implementation ideas for: ...", output: "handoff/external-reference.md" },
-      { agent: "codebase-locator", task: "Map local files that would change for: ...", output: "handoff/local-files.md" },
-      { agent: "codebase-analyzer", task: "Trace current behavior of those files: ...", output: "handoff/local-flow.md" },
-      { agent: "codebase-pattern-finder", task: "Find analogous local patterns for: ...", output: "handoff/local-patterns.md" }
-    ]
-  }],
+  tasks: [
+    { agent: "codebase-online-researcher", task: "Research the external reference and transferable implementation ideas for: ...", output: "handoff/external-reference.md" },
+    { agent: "codebase-locator", task: "Map local files that would change for: ...", output: "handoff/local-files.md" },
+    { agent: "codebase-analyzer", task: "Trace current behavior of those files: ...", output: "handoff/local-flow.md" },
+    { agent: "codebase-pattern-finder", task: "Find analogous local patterns for: ...", output: "handoff/local-patterns.md" }
+  ],
   context: "fresh"
 })
 // Parent then writes handoff/final-handoff-plan.md from the outputs.
@@ -113,38 +107,6 @@ Use this when unresolved requirements and genuinely missing repository context j
 
 Use this after implementation when the user wants cleanup review or when a final pass would reduce AI-slop. Launch two fresh-context `codebase-analyzer` scouts with `output: false` and `progress: false`: one deslop pass and one verbosity pass. If the `deslop` or `verbosity-cleaner` skills are available, pass the relevant skill to that scout; otherwise inline the criteria. Both scouts are read-only and should flag concrete issues with severity, file/line references, and smallest safe fixes. Phrase the constraint as “Do not modify project/source files; returning findings through the configured output artifact is allowed” when you use `output` or `outputMode: "file-only"`. The parent decides what to apply and asks before making changes unless cleanup was already authorized. When the user opts to autofix, the parent launches one async `code-simplifier` writer with the synthesized fixes as its explicit scope.
 
-### Staged fix orchestration technique
-
-Use this when a broad diff has known reviewer findings across several items and the user wants the parent to coordinate a safe multi-stage fix. Keep the active worktree safe with a three-stage chain:
-
-1. A parallel read-only planning fanout, one specialist per issue cluster. Use `codebase-analyzer`, `debugger` in inspect-only mode, or `codebase-pattern-finder` based on the angle. Each child inspects the real diff and returns exact files, line refs, proposed fixes, and focused validation. They must not edit.
-2. One writer worker (`debugger` for correctness fixes or `code-simplifier` for cleanup fixes). It receives the planner summaries through `{previous}` or named `{outputs.name}` values, the parent’s accepted scope, stop rules, and verification contract. It is the only child allowed to edit the active worktree.
-3. A parallel read-only validation fanout. Validators inspect the worker diff from fresh context with distinct angles, report pass/fail, remaining blockers, and missing verification.
-
-Prefer `async: true`, `context: "fresh"` for planners/validators, `outputMode: "file-only"` for large summaries, and per-stage output names that will not collide. Add `phase` and `label` to make async status readable, and use `as` plus `{outputs.name}` when a later step needs a specific earlier result instead of the whole `{previous}` blob. Use this pattern instead of launching several writer workers into a dirty worktree. Include non-blocking suggestions in the writer prompt only when they are small, safe, and do not expand product scope; otherwise record them as deferred.
-
-When the first step can return a structured target list, prefer dynamic fanout instead of hand-authoring a static parallel group. Use `outputSchema` and `as` on the producer, then an `expand` step with `from: { output, path }`, an explicit `maxItems`, one `parallel` child template, and `collect.as`. Item templates may use `{item}` or a named item such as `{target.path}`. Do not use dynamic fanout for prose outputs, nested fanout, dynamic agent selection, reducers, `when` conditions, or arbitrary expressions; `.chain.md` does not support this syntax, so use direct JSON or a saved `.chain.json`.
-
-Example shape:
-
-```typescript
-subagent({
-  async: true,
-  context: "fresh",
-  chain: [
-    { parallel: [
-      { agent: "codebase-analyzer", phase: "Planning", label: "Deploy docs", as: "deployPlan", task: "Plan fixes for deploy docs/workflow. Inspect the current diff. Do not modify project/source files; returning findings via the configured output artifact is allowed.", output: "plans/deploy.md", outputMode: "file-only" },
-      { agent: "debugger", phase: "Planning", label: "Scheduler contract", as: "schedulerPlan", task: "Inspect-only plan for scheduler contract fixes. Do not edit. Return exact fixes and focused validation.", output: "plans/scheduler.md", outputMode: "file-only" },
-      { agent: "codebase-pattern-finder", phase: "Planning", label: "Sandbox patterns", as: "sandboxPlan", task: "Find existing patterns relevant to sandbox/security fixes. Do not edit.", output: "plans/sandbox.md", outputMode: "file-only" }
-    ], concurrency: 3 },
-    { agent: "debugger", phase: "Implementation", label: "Apply accepted fixes", as: "workerResult", task: "Apply only the accepted fixes from these planning summaries. You are the sole writer for the active worktree. Run focused validation and report changed files, commands, failures, and remaining issues.\n\nDeploy plan:\n{outputs.deployPlan}\n\nScheduler plan:\n{outputs.schedulerPlan}\n\nSandbox plan:\n{outputs.sandboxPlan}", output: "worker/fixes.md", outputMode: "file-only", progress: true },
-    { parallel: [
-      { agent: "codebase-analyzer", phase: "Validation", label: "Deploy/scheduler validation", task: "Validate the post-worker diff for deploy and scheduler fixes. Start from the worker result: {outputs.workerResult}. Do not modify project/source files; returning findings via the configured output artifact is allowed.", output: "validation/deploy-scheduler.md", outputMode: "file-only" },
-      { agent: "debugger", phase: "Validation", label: "Failure-mode validation", task: "Inspect-only failure-mode hunt on the post-worker diff. Start from the worker result: {outputs.workerResult}. Do not edit.", output: "validation/failure-modes.md", outputMode: "file-only" }
-    ], concurrency: 2 }
-  ]
-})
-```
 
 ## Builtin Agents
 
@@ -157,11 +119,12 @@ Builtin agents load at the lowest priority. Project agents override user agents,
 | `codebase-pattern-finder`    | Find similar implementations or conventions                       | `openai/gpt-5.4-mini` | low      | read, search, find, ls, bash                                                             | Read-only. Returns code snippets with `file:line` references.                                              |
 | `codebase-research-locator`  | Discover prior `research/` and `specs/` docs                      | `openai/gpt-5.4-mini` | low      | read, search, find, ls, bash                                                             | Read-only. Sorts by date, tiers by recency, flags supersession.                                            |
 | `codebase-research-analyzer` | Extract decisions and constraints from prior docs                 | `openai/gpt-5.5`      | low      | read, search, find, ls, bash                                                             | Read-only. Filters aggressively for what still applies today.                                              |
-| `codebase-online-researcher` | Web research with authoritative sources                           | `openai/gpt-5.5`      | low      | read, search, find, ls, bash, write, web_search, fetch_content, get_search_content       | Has the `browser` skill. Persists keepers to `research/web/`.                                       |
+| `codebase-online-researcher` | Web research with authoritative sources                           | `openai/gpt-5.5`      | low      | read, search, find, ls, bash, write, web_search, fetch_content, get_search_content       | Has the `playwright-cli` skill. Persists keepers to `research/web/`.                                       |
 | `code-simplifier`            | Clean up recently changed code without changing behavior          | `openai/gpt-5.5`      | low      | read, edit, write, search, find, ls, bash                                                | **Writer.** Scopes to recently modified code by default; preserves all observable behavior.                |
 | `debugger`                   | Reproduce, diagnose, and fix failing behavior                     | `openai-codex/gpt-5.6-sol:xhigh` | xhigh | read, edit, write, search, find, ls, bash, web_search, fetch_content, get_search_content, intercom, contact_supervisor, todo | **Writer.** Has the `tdd`, `playwright-cli`, and `tmux` skills. Can coordinate with the parent; inspect-only mode requires an explicit instruction. |
+| `worker`                     | Implement normal tasks and approved orchestrator handoffs         | `openai-codex/gpt-5.6-luna:max` | max | read, edit, write, search, find, ls, bash, web_search, fetch_content, get_search_content, intercom, contact_supervisor, todo | **Writer.** Has the `tdd`, `playwright-cli`, and `tmux` skills. Defaults to forked context; escalates unapproved decisions instead of guessing. |
 
-Each builtin declares an explicit `model` and `fallbackModels` chain (typically `github-copilot/<same>`, then `anthropic/claude-opus-4-8`, then `github-copilot/claude-opus-4.7`). The current user-selected model is automatically appended as the last fallback and de-duplicated. Override per run with inline config:
+Each builtin declares an explicit `model` and `fallbackModels` sequence (typically `github-copilot/<same>`, then `anthropic/claude-opus-4-8`, then `github-copilot/claude-opus-4.7`). The current user-selected model is automatically appended as the last fallback and de-duplicated. Override per run with inline config:
 
 ```text
 /run codebase-analyzer[model=anthropic/claude-sonnet-4] "Trace the auth flow"
@@ -185,7 +148,7 @@ A strong subagent prompt usually includes:
 - **Output**: the expected summary shape, artifact path, or finding format.
 - **Stop rules**: when to stop after enough evidence, and when not to keep searching.
 
-Avoid carrying over old prompt habits that over-specify every step. Use `must`, `always`, and `never` for real invariants; for judgment calls, give decision rules. For example, tell `codebase-analyzer` to trace the staged diff directly and report only evidence-backed findings, rather than prescribing every file or command. Tell `codebase-online-researcher` the retrieval budget: start with broad targeted searches, fetch the strongest sources via `fetch_content`, fall back to `browser` only when JS execution is required, and stop when the question is answered.
+Avoid carrying over old prompt habits that over-specify every step. Use `must`, `always`, and `never` for real invariants; for judgment calls, give decision rules. For example, tell `codebase-analyzer` to trace the staged diff directly and report only evidence-backed findings, rather than prescribing every file or command. Tell `codebase-online-researcher` the retrieval budget: start with broad targeted searches, fetch the strongest sources via `fetch_content`, fall back to `playwright-cli` only when JS execution is required, and stop when the question is answered.
 
 For implementation handoffs to `debugger` or `code-simplifier`, name the approved scope and success criteria more clearly than the process. Good prompts say what to change, what not to change, where the evidence lives, how to validate, and when to escalate. They should not ask the child to create another subagent plan or continue the parent conversation.
 
@@ -220,11 +183,7 @@ Agent files can live in:
 - `.atomic/agents/**/*.md` — canonical project scope
 - legacy `.agents/**/*.md` and `.pi/agents/**/*.md` — still read for compatibility, but `.atomic/agents/` wins on conflicts
 
-Chains live in:
-- `~/.atomic/agent/chains/**/*.chain.md` and `~/.atomic/agent/chains/**/*.chain.json` — user scope
-- `.atomic/chains/**/*.chain.md` and `.atomic/chains/**/*.chain.json` — project scope
-
-Discovery is recursive. `.chain.md` files do not define agents. Use `.chain.md` for simple saved chains and `.chain.json` for dynamic fanout or inline schema objects. Agents and chains can set optional frontmatter/package metadata; `name: codebase-analyzer` plus `package: code-analysis` registers as runtime name `code-analysis.codebase-analyzer` while serialization keeps `name` and `package` separate.
+Discovery is recursive. Agents can set optional frontmatter/package metadata; `name: codebase-analyzer` plus `package: code-analysis` registers as runtime name `code-analysis.codebase-analyzer` while serialization keeps `name` and `package` separate.
 
 Precedence is by parsed runtime name:
 
@@ -294,23 +253,10 @@ Avoid duplicate output paths in parallel tasks. Concurrent children should not w
 
 Concurrent writers conflict. `code-simplifier` and `debugger` change files. Do not run two writers in parallel against the same worktree unless you isolate them with `worktree: true`.
 
-### Chain execution
-
-```typescript
-subagent({
-  chain: [
-    { agent: "codebase-locator", task: "Map files relevant to the migration target" },
-    { agent: "codebase-analyzer", task: "Trace current behavior of the files in {previous}" },
-    { agent: "debugger", task: "Reproduce the failing case and patch it. Context: {previous}" }
-  ]
-})
-```
-
-Chain steps can use templated variables such as `{task}`, `{previous}`, `{chain_dir}`, and `{outputs.name}`. Use `as: "name"` on a successful step or parallel task to make that output available to later steps. Prefer named outputs when a later step needs one specific result; keep `{previous}` for simple linear handoffs or full fan-in summaries. Use `phase` and `label` for status readability. Use `outputSchema` when later steps need reliable structured data; the child must call `structured_output` with schema-valid JSON, or the step fails.
 
 ### Async/background
 
-Choose async/background mode selectively when delegated work is genuinely long-running or independently useful while the parent proceeds. Use foreground execution when the parent needs the result before the next step. This applies consistently to read-only specialists, writers, chains, and parallel groups; keep the write path single-threaded in either mode.
+Choose async/background mode selectively when delegated work is genuinely long-running or independently useful while the parent proceeds. Use foreground execution when the parent needs the result. This applies consistently to read-only specialists, writers, and parallel groups; keep the write path single-threaded in either mode.
 
 Async does not mean parallel writes. Do not edit the same active worktree while an async `debugger` or `code-simplifier` is changing it. Parent-side overlap should be reading, validation prep, synthesis, command planning, or review of unaffected context unless the writer is isolated in a separate worktree.
 
@@ -324,7 +270,7 @@ subagent({
 })
 ```
 
-File-only output mode also works for async single runs, top-level parallel task items, sequential chain steps, and chain parallel task items. In chains, `{previous}` receives the compact saved-file reference when the prior step used file-only mode.
+File-only output mode works for async single runs and top-level parallel task items. A compact saved-file reference is returned instead of the full saved content.
 
 For review fanout where the parent continues a local audit:
 
@@ -352,7 +298,7 @@ Resume behavior:
 - If an async child is still running and reachable, `resume` sends the follow-up to that live child over intercom (only when the child carries an intercom bridge target).
 - If an async child has completed, `resume` revives it by starting a new async child from the persisted child session file.
 - Multi-child async runs require `index` unless only one running child is selectable.
-- Completed foreground single, parallel, and chain runs can also be revived by `index` while their run metadata remains in extension state.
+- Completed foreground single and parallel runs can also be revived by `index` while their run metadata remains in extension state.
 - Revive starts a new child process from the old session context; it does not restart the same OS process.
 - If the chosen child has no persisted `.jsonl` session file, resume fails and reports that directly.
 
@@ -401,7 +347,7 @@ If the run already has an active intercom bridge target, needs-attention notific
 
 ## Non-Interactive Execution
 
-Every supported subagent launch starts immediately without a preview/editor prompt or terminal input. This applies to single, parallel, chain, foreground, background, fanout, prompt-template, and human-entered `/run`, `/chain`, `/parallel`, and `/run-chain` execution.
+Every supported subagent launch starts immediately without a preview/editor prompt or terminal input. This applies to single, parallel, foreground, background, fanout, prompt-template, and human-entered `/run` and `/parallel` execution.
 
 Resolve questions in the parent conversation before launching children. Use `interview` when the user must answer a question, then put the resolved scope and validation contract in the child task. Human slash commands retain their separate parsing and event-bridge path.
 
@@ -462,7 +408,7 @@ If intercom messages do not show up, run `subagent({ action: "doctor" })` or `/s
 
 The `subagent(...)` tool also supports management actions.
 
-### List available agents and chains
+### List available agents
 
 ```typescript
 subagent({ action: "list" })
@@ -505,7 +451,7 @@ subagent({ action: "delete", agent: "code-analysis.my-agent" })
 
 Use management actions when the system needs to create or edit subagents on demand without dropping into raw file editing.
 
-Management actions create or update user/project agent files. `config.name` is the local frontmatter name; optional `config.package` registers and looks up the runtime name as `{package}.{name}`. Use the dotted runtime name for `get`, `update`, `delete`, slash commands, and chain steps. For small builtin changes such as a model swap, prefer `subagents.agentOverrides` in settings.
+Management actions create or update user/project agent files. `config.name` is the local frontmatter name; optional `config.package` registers and looks up the runtime name as `{package}.{name}`. Use the dotted runtime name for `get`, `update`, and `delete`. For small builtin changes such as a model swap, prefer `subagents.agentOverrides` in settings.
 
 ## Creating and Editing Agents by File
 
@@ -598,16 +544,14 @@ Use `/name` so intercom targeting stays stable.
 
 ## Common Workflows
 
-### Locate → Analyze → Fix
+### Locate, analyze, fix
+
+Use explicit follow-up calls when each result should guide the next task:
 
 ```typescript
-subagent({
-  chain: [
-    { agent: "codebase-locator", task: "Map the auth files and tests relevant to: ..." },
-    { agent: "codebase-analyzer", task: "Trace current behavior of the files in {previous}" },
-    { agent: "debugger", task: "Reproduce the failure and patch the root cause. Context: {previous}" }
-  ]
-})
+const context = await subagent({ agent: "codebase-locator", task: "Map the auth files and tests relevant to: ..." });
+const analysis = await subagent({ agent: "codebase-analyzer", task: "Trace current behavior of the mapped files. Use the returned context: ..." });
+await subagent({ agent: "debugger", task: "Reproduce the failure and patch the root cause. Use the returned analysis: ..." });
 ```
 
 ### Clarify → Discover → Implement → Review (self-orchestrated workflow)
@@ -622,7 +566,7 @@ When the user approves launching a subagent to carry out a workflow, treat that
 - `/parallel-review` maps to: launch fresh-context specialist reviewers with distinct review angles; synthesize the feedback before applying anything.
 - `/review-loop` maps to: keep the parent in charge of writer → fresh specialist reviewers → synthesized fix writer cycles until no fixes worth doing now remain, an unapproved decision appears, or the review-round cap is reached.
 - `/parallel-research` maps to: combine local locator/analyzer/pattern-finder/research-analyzer context with external `codebase-online-researcher` evidence when current docs, ecosystem behavior, or API details matter.
-- `/parallel-context-build` maps to: run a chain-mode parallel group of codebase specialists with distinct temp output paths, then synthesize their context and meta-prompt sections.
+- `/parallel-context-build` maps to: run a top-level parallel group of codebase specialists with distinct output paths, then synthesize their context and meta-prompt sections.
 - `/parallel-handoff-plan` maps to: run external `codebase-online-researcher` plus local locator/analyzer/pattern-finder/research passes, then synthesize the final handoff plan and implementation-ready meta-prompt yourself.
 - `/parallel-cleanup` maps to: read-only `codebase-analyzer` scouts (deslop + verbosity) followed by an optional `code-simplifier` writer when the user authorizes autofix.
 
@@ -632,15 +576,15 @@ For feature work, use this sequence as scaffolding for parent-agent behavior:
 clarify when needed → validation contract → optional bounded discovery → one writer when delegated → fresh-context specialist review when warranted → one fix writer if needed → parent review
 ```
 
-The validation contract defines completion before code is written: expected behavior, checks, commands or user flows to exercise, and evidence the writer should return. Keep it lightweight for small tasks, but make it explicit enough that reviewers and validators are checking the intended outcome rather than the writer’s own assumptions. Subagent runs do not carry a structured `acceptance` field, infer acceptance policies, inject acceptance-report prompts, or run acceptance gates; put any evidence requirements directly in the task text. Do not set removed acceptance config fields on `subagent()` calls, chain steps, parallel task items, or agent frontmatter; move those requirements into the assigned task text instead.
+The validation contract defines completion before code is written: expected behavior, checks, commands or user flows to exercise, and evidence the writer should return. Keep it lightweight for small tasks, but make it explicit enough that reviewers and validators are checking the intended outcome rather than the writer’s own assumptions. Subagent runs do not carry a structured `acceptance` field, infer acceptance policies, inject acceptance-report prompts, or run acceptance gates; put any evidence requirements directly in the task text. Do not set removed acceptance config fields on `subagent()` calls, parallel task items, or agent frontmatter; move those requirements into the assigned task text instead.
 
-The first writer implements the approved change. When it runs in the background, the parent may continue independent inspection or validation prep, but not parallel edits to the same worktree. Treat the writer handoff as the transition into review, not as final completion, unless the user explicitly asked for writer-only work, review-only output, or to stop after implementation. Specialist reviewers inspect the resulting diff from fresh context when warranted. The final fix writer applies synthesized review fixes, then the parent looks over the final diff before completing. The parent may launch these steps as a background chain when useful or as foreground/follow-up runs. Ask only needed questions before a non-interactive launch.
+The first writer implements the approved change. When it runs in the background, the parent may continue independent inspection or validation prep, but not parallel edits to the same worktree. Treat the writer handoff as the transition into review, not as final completion, unless the user explicitly asked for writer-only work, review-only output, or to stop after implementation. Specialist reviewers inspect the resulting diff from fresh context when warranted. The final fix writer applies synthesized review fixes, then the parent looks over the final diff before completing. The parent may launch these steps as separate background or foreground runs. Ask only needed questions before a non-interactive launch.
 
 For complex or risky changes, increase review and validation fanout when user intent or correctness risk materially warrants it rather than automatically trusting one reviewer. Use distinct angles such as correctness/regressions (`codebase-analyzer`), failure-mode hunt (`debugger` inspect-only), pattern fit (`codebase-pattern-finder`), prior-decision conformance (`codebase-research-*`), and external-spec conformance (`codebase-online-researcher`). When reviewers find non-trivial issues or the fix writer touches many lines, consider another focused review round before final validation.
 
 For very large work, split into serial milestones instead of launching a swarm of writers. Each milestone gets one writer, a validation contract, fresh-context review, a fix pass, and parent approval before the next milestone starts. Use parallel subagents inside a milestone for read-only context, research, and review only.
 
-Keep orchestration authority in the parent session. Child subagents should not launch more subagents, read this skill, or run their own orchestration loops unless the parent intentionally selected an explicit fanout agent whose resolved builtin `tools` includes `subagent` for that assigned fanout. Spawned non-fanout subagents do not receive the `subagent` skill, parent-only status/control/slash messages, prior parent `subagent` tool-call/tool-result artifacts, or the `subagent` extension tool. Child context filtering also strips old hidden orchestration-instruction messages when they appear in inherited history. Every child also receives a boundary instruction that says the parent owns orchestration, the child must not propose or run subagents unless explicitly authorized for fanout, and writer children must call real edit/write tools instead of printing pseudo tool calls. Pass children concrete role-specific work instead.
+Keep orchestration authority in the parent session. Child subagents should not launch more subagents or run their own orchestration loops unless the parent intentionally selected an explicit fanout agent whose resolved builtin `tools` includes `subagent` for that assigned fanout. This skill is parent-only: it is stripped from every child prompt, including fanout-authorized children. A child may still have the `subagent` extension tool registered, because bundled extensions load through normal discovery; registration is not authority. Typed admission policy lets a non-fanout child use only `list`, `get`, `status`, and `doctor`, and refuses delegation, `resume`, and `interrupt`. Spawned children also do not receive parent-only status/control/slash messages or prior parent `subagent` tool-call/tool-result artifacts, and child context filtering strips old hidden orchestration-instruction messages when they appear in inherited history. Every child also receives a boundary instruction that says the parent owns orchestration, the child must not propose or run subagents unless explicitly authorized for fanout, and writer children must call real edit/write tools instead of printing pseudo tool calls. Pass children concrete role-specific work instead.
 
 1. Clarify only when needed. Use existing context first; gather missing code or research context selectively, then ask only unresolved questions that materially affect scope, completion criteria, constraints, or non-goals.
 2. Define the validation contract. State completion expectations before implementation: expected behavior, checks to run, user flows to exercise, and evidence required in the writer handoff. For UI, CLI, integration, or workflow changes, include at least one validator angle that uses the product the way a user would rather than only reading code.
@@ -691,7 +635,7 @@ subagent({
 
 When implementation review is part of the requested shape, do not treat the first review as the final step: synthesize findings against user scope and the validation contract, then launch one writer for accepted fixes when implementation is authorized.
 
-When a writer completes, treat its handoff as an intermediate state when review is part of the requested shape. The next parent action is bounded review, then synthesis, then a fix writer if reviewers found fixes worth doing now. This can be planned as a background chain when useful or continued as foreground/follow-up subagent runs.
+When a writer completes, treat its handoff as an intermediate state when review is part of the requested shape. The next parent action is bounded review, then synthesis, then a fix writer if reviewers found fixes worth doing now. This can be planned as separate background or foreground runs.
 
 For explicit review-loop requests, repeat writer → fresh-specialist-reviewers → synthesized-fix-writer cycles until reviewers find no blockers or fixes worth doing now, remaining feedback is optional or intentionally deferred, an unapproved product/scope/architecture decision needs the user, or the max review-round cap is reached. Default to 3 review rounds unless the user sets a different cap.
 
@@ -706,13 +650,6 @@ subagent({
 })
 ```
 
-### Saved chain
-
-```text
-/run-chain review-chain -- review this branch
-```
-
-Use saved `.chain.md` or `.chain.json` workflows when the user wants a repeatable multi-agent flow without rewriting the chain each time. Prefer `.chain.json` for dynamic fanout or inline `outputSchema` objects; `.chain.md` remains the simple sequential/static authoring format.
 
 ## Error Handling
 
@@ -720,7 +657,7 @@ Use saved `.chain.md` or `.chain.json` workflows when the user wants a repeatabl
 
 ```typescript
 subagent({ action: "list" })
-// Check available agents and chains, then confirm scope/precedence.
+// Check available agents, then confirm scope and precedence.
 ```
 
 **Setup, discovery, or intercom confusion**

package/dist/builtin/subagents/src/agents/agent-discovery.ts

@@ -2,7 +2,7 @@ import * as fs from "node:fs";
 import * as os from "node:os";
 import * as path from "node:path";
 import { getEnvValue } from "@bastani/atomic";
-import { loadAgentsFromDir, loadChainsFromDir } from "./agent-loaders.ts";
+import { loadAgentsFromDir } from "./agent-loaders.ts";
 import { applyBuiltinOverrides, readMergedSubagentSettings } from "./agent-overrides.ts";
 import {
 	BUILTIN_AGENTS_DIR,
@@ -11,18 +11,13 @@ import {
 	getUserAgentDirs,
 	getUserAgentSettingsPath,
 	getUserAgentSettingsPaths,
-	getUserChainDir,
-	getUserChainDirs,
 	resolveNearestProjectAgentDirs,
-	resolveNearestProjectChainDirs,
 } from "./agent-paths.ts";
 import { mergeAgentsForScope } from "./agent-selection.ts";
 import {
 	type AgentConfig,
 	type AgentDiscoveryResult,
 	type AgentScope,
-	type ChainConfig,
-	type ChainDiscoveryDiagnostic,
 	EMPTY_SUBAGENT_SETTINGS,
 } from "./agent-types.ts";
 
@@ -61,20 +56,14 @@ export function discoverAgentsAll(cwd: string): {
 	builtin: AgentConfig[];
 	user: AgentConfig[];
 	project: AgentConfig[];
-	chains: ChainConfig[];
-	chainDiagnostics: ChainDiscoveryDiagnostic[];
 	userDir: string;
 	projectDir: string | null;
-	userChainDir: string;
-	projectChainDir: string | null;
 	userSettingsPath: string;
 	projectSettingsPath: string | null;
 } {
 	const userDirOld = getUserAgentDirs();
 	const userDirNew = path.join(os.homedir(), ".agents");
-	const userChainDir = getUserChainDir();
 	const { readDirs: projectDirs, preferredDir: projectDir } = resolveNearestProjectAgentDirs(cwd);
-	const { readDirs: projectChainDirs, preferredDir: projectChainDir } = resolveNearestProjectChainDirs(cwd);
 	const userSettingsLoad = readMergedSubagentSettings(getUserAgentSettingsPaths());
 	const projectSettingsLoad = readMergedSubagentSettings(getProjectAgentSettingsPaths(cwd));
 	const userSettingsPath = userSettingsLoad.path ?? getUserAgentSettingsPath();
@@ -101,19 +90,6 @@ export function discoverAgentsAll(cwd: string): {
 	}
 	const project = Array.from(projectMap.values());
 
-	const chainMap = new Map<string, ChainConfig>();
-	const projectChainDiagnostics: ChainDiscoveryDiagnostic[] = [];
-	for (const dir of projectChainDirs) {
-		const loaded = loadChainsFromDir(dir, "project");
-		projectChainDiagnostics.push(...loaded.diagnostics);
-		for (const chain of loaded.chains) {
-			chainMap.set(chain.name, chain);
-		}
-	}
-	const userChainLoads = getUserChainDirs().map((dir) => loadChainsFromDir(dir, "user"));
-	const chains = [...userChainLoads.flatMap((loaded) => loaded.chains), ...Array.from(chainMap.values())];
-	const chainDiagnostics = [...userChainLoads.flatMap((loaded) => loaded.diagnostics), ...projectChainDiagnostics];
-
 	const legacyUserAgentDir = userDirOld[0]!;
 	// ATOMIC_CODING_AGENT_DIR is already applied by getUserAgentDirs(); prefer that resolved path over ~/.agents.
 	const userDir = getEnvValue("ATOMIC_CODING_AGENT_DIR")
@@ -126,12 +102,8 @@ export function discoverAgentsAll(cwd: string): {
 		builtin,
 		user,
 		project,
-		chains,
-		chainDiagnostics,
 		userDir,
 		projectDir,
-		userChainDir,
-		projectChainDir,
 		userSettingsPath,
 		projectSettingsPath,
 	};

package/dist/builtin/subagents/src/agents/agent-loaders.ts

@@ -6,13 +6,10 @@ import { shouldPreserveAgentExtraField } from "./agent-serializer.ts";
 import {
 	type AgentConfig,
 	type AgentSource,
-	type ChainConfig,
-	type ChainDiscoveryDiagnostic,
 	defaultInheritProjectContext,
 	defaultInheritSkills,
 	defaultSystemPromptMode,
 } from "./agent-types.ts";
-import { parseChain, parseJsonChain } from "./chain-serializer.ts";
 import { parseFrontmatter } from "./frontmatter.ts";
 import { buildRuntimeName, parsePackageName } from "./identity.ts";
 
@@ -51,10 +48,7 @@ function parseCommaSeparatedList(value: string | undefined): string[] | undefine
 export function loadAgentsFromDir(dir: string, source: AgentSource): AgentConfig[] {
 	const agents: AgentConfig[] = [];
 
-	for (const filePath of listFilesRecursive(
-		dir,
-		(fileName) => fileName.endsWith(".md") && !fileName.endsWith(".chain.md"),
-	)) {
+	for (const filePath of listFilesRecursive(dir, (fileName) => fileName.endsWith(".md"))) {
 		let content: string;
 		try {
 			content = fs.readFileSync(filePath, "utf-8");
@@ -152,36 +146,3 @@ export function loadAgentsFromDir(dir: string, source: AgentSource): AgentConfig
 
 	return agents;
 }
-
-export function loadChainsFromDir(
-	dir: string,
-	source: "user" | "project",
-): { chains: ChainConfig[]; diagnostics: ChainDiscoveryDiagnostic[] } {
-	const chains = new Map<string, ChainConfig>();
-	const diagnostics: ChainDiscoveryDiagnostic[] = [];
-
-	for (const filePath of listFilesRecursive(
-		dir,
-		(fileName) => fileName.endsWith(".chain.md") || fileName.endsWith(".chain.json"),
-	)) {
-		let content: string;
-		try {
-			content = fs.readFileSync(filePath, "utf-8");
-		} catch {
-			continue;
-		}
-
-		try {
-			const chain = filePath.endsWith(".chain.json")
-				? parseJsonChain(content, source, filePath)
-				: parseChain(content, source, filePath);
-			const existing = chains.get(chain.name);
-			if (existing?.filePath.endsWith(".chain.json") && filePath.endsWith(".chain.md")) continue;
-			chains.set(chain.name, chain);
-		} catch (error) {
-			diagnostics.push({ source, filePath, error: error instanceof Error ? error.message : String(error) });
-		}
-	}
-
-	return { chains: Array.from(chains.values()), diagnostics };
-}