@bastani/atomic 0.9.13-alpha.1 → 0.9.13-alpha.3

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.13-alpha.1",
+  "version": "0.9.13-alpha.3",
   "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. 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-cleanup.md

@@ -40,7 +40,7 @@ Both scouts are read-only; `codebase-analyzer` cannot edit. Their reports are re
 
 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.
 
-In **autofix** mode, an invocation containing the exact word `autofix` uses it as workflow control, not cleanup scope; remove it before identifying the target. After synthesis, launch one async `code-simplifier` writer with only the fixes-worth-doing-now list as scope. Validate and summarize. Do not apply optional improvements unless explicitly requested; if no fixes are worth doing now, do not edit.
+In **autofix** mode, an invocation containing the exact word `autofix` uses it as workflow control, not cleanup scope; remove it before identifying the target. After synthesis, launch one foreground `code-simplifier` writer with only the fixes-worth-doing-now list as scope. Validate and summarize. Do not apply optional improvements unless explicitly requested; if no fixes are worth doing now, do not edit.
 
 Without autofix mode, ask before applying fixes unless I already authorized addressing the cleanup feedback. End that request with a compact numbered menu, including when applicable:
 

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/parallel-review.md

@@ -26,7 +26,7 @@ Use `/parallel-cleanup` instead for simplicity, slop, or verbosity angles. Every
 
 Synthesize fixes worth doing now, optional improvements, and ignored or deferred feedback with a short reason; assess findings rather than applying them blindly. 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.
 
-In **autofix** mode, an invocation containing the exact word `autofix` uses it as workflow control, not review scope; remove it before identifying the target. After synthesis, launch one async writer—`debugger` for correctness/regression fixes or `code-simplifier` for cleanup-shaped feedback—with only the explicit fixes-worth-doing-now list as scope. Validate and summarize. Do not apply optional improvements unless explicitly requested; if no fixes are worth doing now, do not edit.
+In **autofix** mode, an invocation containing the exact word `autofix` uses it as workflow control, not review scope; remove it before identifying the target. After synthesis, launch one foreground writer—`debugger` for correctness/regression fixes or `code-simplifier` for cleanup-shaped feedback—with only the explicit fixes-worth-doing-now list as scope. Validate and summarize. Do not apply optional improvements unless explicitly requested; if no fixes are worth doing now, do not edit.
 
 Without autofix mode, ask before applying fixes unless I already authorized addressing review feedback. End that request with a compact numbered menu, including when applicable:
 

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 foreground 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. 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.
 
@@ -24,7 +24,7 @@ Delegate only independent work too large for a handful of tool calls; do not del
 
 After each round, synthesize blockers or scope/product/architecture decisions needing approval, fixes worth doing now, optional improvements, and feedback to ignore or defer with a short reason. Assess findings rather than applying them blindly. Pause for my approval before a writer acts on any unapproved product, scope, or architecture decision.
 
-An async implementation writer's handoff transitions into review; it is not final completion unless I requested writer-only work, review-only output, or a stop after implementation. When implementation is authorized and fixes are worth doing now, launch one async writer to apply only the synthesized fixes—`debugger` for correctness or `code-simplifier` for cleanup. Require it to preserve approved scope, run focused validation, and report changed files, commands with exit codes, validation evidence, surprises, and unfinished work.
+The implementation writer's handoff transitions into review; it is not final completion unless I requested writer-only work, review-only output, or a stop after implementation. When implementation is authorized and fixes are worth doing now, launch one foreground writer to apply only the synthesized fixes—`debugger` for correctness or `code-simplifier` for cleanup. Require it to preserve approved scope, run focused validation, and report changed files, commands with exit codes, validation evidence, surprises, and unfinished work.
 
 Run another review round after a fix only when it made material changes or addressed non-trivial findings. Do not loop for optional polish, speculative improvements, or already deferred findings.