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

package/dist/builtin/subagents/prompts/parallel-cleanup.md

@@ -1,61 +0,0 @@
----
-description: Parallel cleanup review and refinement of recent changes
----
-
-## Goal
-
-Run a fresh-context cleanup pass over the current work: two scouts identify concrete slop and verbosity issues, then synthesize which fixes are worth doing now. In authorized autofix mode, one writer applies that list.
-
-Additional scope or focus from the slash command invocation:
-
-$@
-
-## Constraints and tools
-
-Use the `subagent` tool with `context: "fresh"` unless I explicitly request forked context. Launch both scouts in parallel. Each must inspect the repository and current diff through `git diff`, `git status`, and targeted reads. Keep artifacts outside the repository unless I explicitly request them; prefer `output: false`.
-
-**Deslop scout — `codebase-analyzer`.** Pass the `deslop` skill when available; otherwise ask it to inspect the changed scope for:
-
-- comments that restate code, placeholders, stale rationale, or debug leftovers;
-- defensive checks that hide useful errors, return vague defaults, or validate trusted data past the real boundary;
-- type escapes, broad casts, duplicated types, or object-bag typing despite a source-of-truth type;
-- drift from nearby code or project instructions, including generated-sounding docs, changelogs, UI/CLI copy, status text, or test names;
-- pass-through wrappers, dead helpers, duplicate signatures or test setup, and abstractions without an invariant;
-- noisy, vague, brittle UI/CLI copy that requires extra interpretation.
-
-Treat tool output and scan findings as leads, not verdicts. Return only concrete in-scope issues with evidence, severity, `file:line`, and the smallest safe fix.
-
-**Verbosity scout — `codebase-analyzer`.** Pass the `verbosity-cleaner` skill when available; otherwise ask it to inspect code, tests, docs, status text, grouped messages, receipts, and changelog wording for:
-
-- single-use helpers or variables that merely name an obvious expression;
-- nested branches replaceable by direct returns without hiding intent;
-- multi-line cleanup scaffolding replaceable by a direct local pattern without changing cleanup semantics;
-- boilerplate replaceable by an existing fixture or small local helper;
-- formatter-detail tests already covered more cheaply, or wrapper/API-adjacent assertions that repeat one regression claim;
-- prose that repeats itself, sounds generic, or buries the important rule.
-
-Shorter is better only when clearer and when behavior, error signals, cleanup semantics, useful invariants, and local style remain intact.
-
-Both scouts are read-only; `codebase-analyzer` cannot edit. Their reports are review findings, not context summaries. While they run, perform a narrow inspection if useful. Synthesize fixes worth doing now, optional improvements, and feedback to ignore or defer 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 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:
-
-```text
-Reply with [1], [2], or further instructions:
-[1] Apply only the fixes worth doing now via `code-simplifier`.
-[2] Apply the fixes worth doing now plus optional improvements via `code-simplifier`.
-```
-
-## Output
-
-Return a concise, user-facing cleanup report of roughly 300–700 words: fixes worth doing now, optional improvements, ignored or deferred feedback with reasons, edits made when authorized, and validation. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-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.
-
-## Stop rule
-
-Done means both scouts' evidence has been assessed and synthesized, then either the authorized writer's focused changes have been validated, no worthwhile fixes exist, or the numbered approval menu has been presented. Stop without editing when authorization is absent.

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

@@ -1,43 +0,0 @@
----
-description: Parallel codebase specialists building handoff context for planning
----
-
-## Goal
-
-Build grounded, implementation-ready handoff context for the next planner or writer without starting implementation.
-
-Primary request, target, or focus:
-
-$@
-
-## Constraints and tools
-
-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`
-
-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:
-
-- **Locate — `codebase-locator`:** map every relevant file, directory, test, fixture, config, and doc by purpose, using full repo-root paths.
-- **Analyze — `codebase-analyzer`:** trace entry points, control flow, data transformations, side effects, and error handling with `file:line` citations.
-- **Pattern-find — `codebase-pattern-finder`:** provide comparable implementations, test patterns, conventions, and useful code snippets.
-- **Prior research — `codebase-research-locator` then `codebase-research-analyzer`:** when `research/` or `specs/` history applies, locate it before extracting current decisions, constraints, and rationale.
-
-For an issue or PR URL, include locator and analyzer coverage of mentioned files. For a plan, cover its files and their current behavior. For external API/library work, add `codebase-online-researcher` for current primary sources. For a large refactor, emphasize module-boundary and dependency-direction patterns. For UI/product work, cover analogous components and the surrounding render path.
-
-Every specialist is read-only and produces a compact handoff file containing only its unique contribution, ending with `## Open Questions`. 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.
-
-## Output
-
-Synthesize the artifacts for the downstream planner or writer into roughly 500–900 words: the most important context, a compact implementation-ready meta-prompt, open questions or assumptions, and artifact paths. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-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.
-
-## Stop rule
-
-Done means the selected specialists have returned their distinct handoff files and the downstream synthesis names its evidence and artifact paths. Do not implement unless I explicitly ask.

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

@@ -1,47 +0,0 @@
----
-description: Parallel external + local research builders into an implementation handoff plan
----
-
-## Goal
-
-Produce a grounded implementation handoff plan and implementation-ready meta-prompt by comparing applicable external evidence, local behavior, established patterns, and prior decisions.
-
-Primary request, target, or focus:
-
-$@
-
-## 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 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 `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, for example:
-
-- `handoff/external-reference.md`
-- `handoff/local-files.md`
-- `handoff/local-flow.md`
-- `handoff/local-patterns.md`
-- `handoff/prior-research.md`
-
-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.
-
-## Output
-
-Compare external evidence with local architecture and write `handoff/final-handoff-plan.md` yourself, or summarize inline when no persisted artifact was requested. The downstream writer needs roughly 700–1,200 words covering: intended behavior; lessons from external references; local implications; recommended approach; likely files; constraints and non-goals; edge cases, validation commands, risks, and approval decisions; unresolved questions; and a compact implementation-ready meta-prompt.
-
-Then give the user a concise summary with the recommendation, artifact paths, final meta-prompt, and remaining questions or assumptions. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-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.
-
-## Stop rule
-
-Done means discovery evidence has been compared, the final handoff exists at the requested destination or inline, and the user has the recommendation, paths, meta-prompt, and unresolved decisions. Do not start implementation unless I explicitly ask.

package/dist/builtin/subagents/prompts/parallel-research.md

@@ -1,34 +0,0 @@
----
-description: Parallel research specialists for grounded answers
----
-
-## Goal
-
-Build a grounded answer to the current question or decision from distinct external, local, convention, or prior-decision evidence.
-
-Primary question or focus:
-
-$@
-
-## Constraints and tools
-
-Use fresh context unless I explicitly request forked context; specialists inspect sources directly rather than relying on the main conversation. Choose two or three strong specialists with distinct applicable angles, using my specified angles when provided:
-
-- **External evidence — `codebase-online-researcher`:** current authoritative sources such as official docs, standards, release notes, benchmarks, issue threads, and primary explanations.
-- **Local context — `codebase-locator` and/or `codebase-analyzer`:** relevant repository files and how they work, with `file:line` references.
-- **Local conventions — `codebase-pattern-finder`:** analogous implementations and patterns the answer should respect.
-- **Prior decisions — `codebase-research-locator` then `codebase-research-analyzer`:** applicable decisions and constraints from `research/` or `specs/`, with locator preceding analyzer.
-
-For library/API questions, include official docs and recent examples. For architecture decisions, cover module boundaries and dependency direction. For debugging, cover call paths and authoritative information about the error. For UI/product questions, cover analogous components and design precedent. For time-sensitive topics, have the online researcher prefer 2026/2025 sources and persist findings to `research/web/`.
-
-This is read-only research unless I explicitly request implementation. 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.
-
-## Output
-
-Each specialist returns concise evidence: local paths and line ranges or external links, confidence and gaps, and the decision implication or next step. Synthesize a user-facing answer of roughly 400–800 words covering what is known, local implications, tradeoffs and risks, gaps or assumptions, and the recommended move. Name disagreements rather than smoothing them over. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-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.
-
-## Stop rule
-
-Done means applicable specialists have returned direct evidence and the synthesis answers the question, identifies material uncertainty or disagreement, and recommends the next move. Do not edit files unless implementation was explicitly requested.

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

@@ -1,47 +0,0 @@
----
-description: Parallel specialist review of the current work
----
-
-## Goal
-
-Produce an adversarial, evidence-backed review of the current work, separating fixes worth doing now from optional or inapplicable feedback. Apply fixes only when authorized.
-
-Additional review target or focus from the slash command invocation:
-
-$@
-
-If this supplies a URL, issue, file, plan, or freeform focus, treat it as primary scope: read or fetch it before assigning angles and pass it into every specialist task.
-
-## Constraints and tools
-
-Use fresh context unless I explicitly request forked context. Specialists inspect repository instructions, relevant files, and the current diff through direct reads and commands, not main-conversation history. There is no generic `reviewer`; choose read-only specialists with distinct angles derived from user intent, the plan, implementation, and diff. Use my angles when supplied; otherwise select three applicable angles:
-
-- **Correctness and regressions — `codebase-analyzer`:** trace the diff and surrounding flow against the request, preserved behavior, edge cases, and hidden runtime failures; cite `file:line` for every claim.
-- **Bug and failure modes — `debugger`:** reproduce relevant behavior where possible, assess how the suspect diff could break, and report evidence.
-- **Pattern fit — `codebase-pattern-finder`:** compare analogous code and conventions, identifying structural drift or missed reuse with `file:line` snippets.
-- **Prior constraints — `codebase-research-locator` then `codebase-research-analyzer`:** surface applicable research or specs and the decisions the change must honor.
-- **External conformance — `codebase-online-researcher`:** compare an external API, RFC, or library contract with its authoritative source.
-
-Use `/parallel-cleanup` instead for simplicity, slop, or verbosity angles. Every specialist gets a task naming its angle and returns concise review findings with evidence, `file:line`, and suggested fixes—not a context summary. Every specialist is read-only, including agent types that can edit. While they run, perform a narrow inspection if useful.
-
-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 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:
-
-```text
-Reply with [1], [2], or further instructions:
-[1] Apply only the fixes worth doing now.
-[2] Apply the fixes worth doing now plus optional improvements.
-```
-
-## Output
-
-Return a concise, user-facing review of roughly 400–800 words: outcome, evidence-backed fixes worth doing now, optional improvements, ignored or deferred feedback with reasons, and any authorized edits and validation. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-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.
-
-## Stop rule
-
-Done means the specialist evidence has been assessed and synthesized, then either authorized fixes were validated, no worthwhile fixes exist, or the numbered approval menu was presented. Stop without editing when authorization is absent.

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

@@ -1,39 +0,0 @@
----
-description: Specialist review/fix loop until clean
----
-
-## Goal
-
-Run a parent-orchestrated review-and-fix loop for the requested work until the current scope is clean, blocked on an unapproved decision, or capped. The parent controls the loop and makes final decisions; children receive concrete role-specific tasks and must not launch subagents or manage the loop.
-
-Additional target, implementation request, max-iteration cap, or review focus from the slash command invocation:
-
-$@
-
-## Constraints and tools
-
-Use the `subagent` tool and specialist roles rather than a generic worker or reviewer. Use one writer per pass: `debugger` for bugs, correctness/regression fixes, or behavior changes; `code-simplifier` for cleanup, refinement, or simplification. Reviewer options are `codebase-analyzer` for correctness and flow, `debugger` in inspect-only mode for failure modes, `codebase-pattern-finder` for consistency, `codebase-online-researcher` for external conformance, and `codebase-research-locator` then `codebase-research-analyzer` for prior decisions.
-
-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 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.
-
-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.
-
-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.
-
-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.
-
-## Output
-
-On completion, inspect the final diff and run or confirm appropriate focused validation. Return a concise, user-facing summary of roughly 300–700 words: why the loop stopped, rounds run, fixes applied, validation, remaining blockers or deferred items, and next steps. Lead with the outcome; keep facts, decisions, caveats, and next steps; drop background and repetition; stay readable rather than compressed into fragments.
-
-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.
-
-## Stop rule
-
-Stop and summarize when reviewers find no blockers or fixes worth doing now; remaining feedback is optional, speculative, or intentionally deferred; an unapproved decision needs me; or the review-round cap is reached. The loop is done only after the final diff and focused validation have been inspected or explicitly reported as unverified.

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

@@ -1,116 +0,0 @@
-import * as fs from "node:fs";
-import * as os from "node:os";
-import * as path from "node:path";
-import { getEnvValue } from "@bastani/atomic";
-import { type AgentLoadDiagnostic, loadAgentsFromDir, loadAgentsFromDirWithDiagnostics } from "./agent-loaders.js";
-import { applyBuiltinOverrides, readMergedSubagentSettings } from "./agent-overrides.js";
-import {
-	BUILTIN_AGENTS_DIR,
-	getProjectAgentSettingsPath,
-	getProjectAgentSettingsPaths,
-	getUserAgentDirs,
-	getUserAgentSettingsPath,
-	getUserAgentSettingsPaths,
-	resolveNearestProjectAgentDirs,
-} from "./agent-paths.js";
-import { mergeAgentsForScope } from "./agent-selection.js";
-import {
-	type AgentConfig,
-	type AgentDiscoveryResult,
-	type AgentScope,
-	EMPTY_SUBAGENT_SETTINGS,
-} from "./agent-types.js";
-
-export function discoverAgents(cwd: string, scope: AgentScope): AgentDiscoveryResult {
-	const userDirOld = getUserAgentDirs();
-	const userDirNew = path.join(os.homedir(), ".agents");
-	const { readDirs: projectAgentDirs, preferredDir: projectAgentsDir } = resolveNearestProjectAgentDirs(cwd);
-	const userSettingsLoad = readMergedSubagentSettings(getUserAgentSettingsPaths());
-	const projectSettingsLoad = readMergedSubagentSettings(getProjectAgentSettingsPaths(cwd));
-	const userSettingsPath = userSettingsLoad.path ?? getUserAgentSettingsPath();
-	const projectSettingsPath = projectSettingsLoad.path ?? getProjectAgentSettingsPath(cwd);
-	const userSettings = scope === "project" ? EMPTY_SUBAGENT_SETTINGS : userSettingsLoad.settings;
-	const projectSettings = scope === "user" ? EMPTY_SUBAGENT_SETTINGS : projectSettingsLoad.settings;
-
-	const builtinAgents = applyBuiltinOverrides(
-		loadAgentsFromDir(BUILTIN_AGENTS_DIR, "builtin"),
-		userSettings,
-		projectSettings,
-		userSettingsPath,
-		projectSettingsPath,
-	);
-
-	const userAgentsOld = scope === "project" ? [] : userDirOld.flatMap((dir) => loadAgentsFromDir(dir, "user"));
-	const userAgentsNew = scope === "project" ? [] : loadAgentsFromDir(userDirNew, "user");
-	const userAgents = [...userAgentsOld, ...userAgentsNew];
-
-	const projectAgents = scope === "user" ? [] : projectAgentDirs.flatMap((dir) => loadAgentsFromDir(dir, "project"));
-	const agents = mergeAgentsForScope(scope, userAgents, projectAgents, builtinAgents).filter(
-		(agent) => agent.disabled !== true,
-	);
-
-	return { agents, projectAgentsDir };
-}
-
-export function discoverAgentsAll(cwd: string): {
-	builtin: AgentConfig[];
-	user: AgentConfig[];
-	project: AgentConfig[];
-	userDir: string;
-	projectDir: string | null;
-	userSettingsPath: string;
-	projectSettingsPath: string | null;
-	diagnostics: AgentLoadDiagnostic[];
-} {
-	const userDirOld = getUserAgentDirs();
-	const userDirNew = path.join(os.homedir(), ".agents");
-	const { readDirs: projectDirs, preferredDir: projectDir } = resolveNearestProjectAgentDirs(cwd);
-	const userSettingsLoad = readMergedSubagentSettings(getUserAgentSettingsPaths());
-	const projectSettingsLoad = readMergedSubagentSettings(getProjectAgentSettingsPaths(cwd));
-	const userSettingsPath = userSettingsLoad.path ?? getUserAgentSettingsPath();
-	const projectSettingsPath = projectSettingsLoad.path ?? getProjectAgentSettingsPath(cwd);
-	const userSettings = userSettingsLoad.settings;
-	const projectSettings = projectSettingsLoad.settings;
-
-	const diagnostics: AgentLoadDiagnostic[] = [];
-	const loadDir = (dir: string, source: "builtin" | "user" | "project"): AgentConfig[] => {
-		const result = loadAgentsFromDirWithDiagnostics(dir, source);
-		diagnostics.push(...result.diagnostics);
-		return result.agents;
-	};
-
-	const builtin = applyBuiltinOverrides(
-		loadDir(BUILTIN_AGENTS_DIR, "builtin"),
-		userSettings,
-		projectSettings,
-		userSettingsPath,
-		projectSettingsPath,
-	);
-	const user = [...userDirOld.flatMap((dir) => loadDir(dir, "user")), ...loadDir(userDirNew, "user")];
-	const projectMap = new Map<string, AgentConfig>();
-	for (const dir of projectDirs) {
-		for (const agent of loadDir(dir, "project")) {
-			projectMap.set(agent.name, agent);
-		}
-	}
-	const project = Array.from(projectMap.values());
-
-	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")
-		? legacyUserAgentDir
-		: fs.existsSync(userDirNew)
-			? userDirNew
-			: legacyUserAgentDir;
-
-	return {
-		builtin,
-		user,
-		project,
-		userDir,
-		projectDir,
-		userSettingsPath,
-		projectSettingsPath,
-		diagnostics,
-	};
-}

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

@@ -1,216 +0,0 @@
-import * as fs from "node:fs";
-import * as path from "node:path";
-import { splitToolList } from "./agent-overrides.js";
-import { shouldPreserveAgentExtraField } from "./agent-serializer.js";
-import {
-	type AgentConfig,
-	type AgentSource,
-	defaultInheritProjectContext,
-	defaultInheritSkills,
-	defaultSystemPromptMode,
-} from "./agent-types.js";
-import { type FrontmatterValue, parseFrontmatter } from "./frontmatter.js";
-import { buildRuntimeName, parsePackageName } from "./identity.js";
-
-function listFilesRecursive(dir: string, predicate: (fileName: string) => boolean): string[] {
-	const files: string[] = [];
-	if (!fs.existsSync(dir)) return files;
-
-	let entries: fs.Dirent[];
-	try {
-		entries = fs.readdirSync(dir, { withFileTypes: true }).sort((a, b) => a.name.localeCompare(b.name));
-	} catch {
-		return files;
-	}
-
-	for (const entry of entries) {
-		const filePath = path.join(dir, entry.name);
-		if (entry.isDirectory()) {
-			files.push(...listFilesRecursive(filePath, predicate));
-			continue;
-		}
-		if (!entry.isFile() && !entry.isSymbolicLink()) continue;
-		if (!predicate(entry.name)) continue;
-		files.push(filePath);
-	}
-	return files;
-}
-
-function parseCommaSeparatedList(value: string | undefined): string[] | undefined {
-	const parsed = value
-		?.split(",")
-		.map((item) => item.trim())
-		.filter(Boolean);
-	return parsed && parsed.length > 0 ? parsed : undefined;
-}
-
-/**
- * Narrow a frontmatter value to its scalar spelling. A YAML sequence where a
- * scalar belongs (`model: [anthropic, x]`) reads as undefined rather than a
- * stringified list, matching upstream's `typeof` narrowing.
- */
-function frontmatterString(value: FrontmatterValue | undefined): string | undefined {
-	return typeof value === "string" ? value : undefined;
-}
-
-/**
- * Narrow a frontmatter value to a boolean. The real YAML parser yields true
- * booleans for the unquoted spellings `serializeAgent` itself writes
- * (`interactive: true`); quoted or hand-written `"true"`/`"false"` strings
- * from the legacy line-reader era stay accepted.
- */
-function frontmatterBoolean(value: FrontmatterValue | undefined): boolean | undefined {
-	if (typeof value === "boolean") return value;
-	if (value === "true") return true;
-	if (value === "false") return false;
-	return undefined;
-}
-
-/**
- * Normalize a frontmatter `tools` value to a list of tool names.
- *
- * Both spellings are valid YAML and both are in use (upstream pi #7598):
- *
- *     tools: read, bash        # string, comma-separated
- *     tools: [read, bash]      # flow sequence
- *     tools:                   # block sequence
- *       - read
- *       - bash
- *
- * so accept either. Anything else yields no tools rather than throwing: this
- * runs inside agent discovery, where a single bad file must not take down
- * every other agent in the same directory.
- */
-function parseToolList(value: FrontmatterValue | undefined): string[] | undefined {
-	const raw = Array.isArray(value) ? value : typeof value === "string" ? value.split(",") : [];
-	const tools = raw
-		.filter((tool): tool is string => typeof tool === "string")
-		.map((tool) => tool.trim())
-		.filter(Boolean);
-	return tools.length > 0 ? tools : undefined;
-}
-
-export interface AgentLoadDiagnostic {
-	/** Absolute path of the skipped file. */
-	path: string;
-	/** Why the file was skipped, from the YAML parser when it threw. */
-	message: string;
-}
-
-export interface AgentDirLoadResult {
-	agents: AgentConfig[];
-	diagnostics: AgentLoadDiagnostic[];
-}
-
-/**
- * Load every agent file in a directory, collecting a diagnostic per file
- * skipped for invalid YAML frontmatter. The real YAML parser is stricter
- * than the line reader it replaced (`description: Deploy: fast` is a
- * nested-mapping error, not a description), so without this record those
- * files would vanish from discovery with no signal.
- */
-export function loadAgentsFromDirWithDiagnostics(dir: string, source: AgentSource): AgentDirLoadResult {
-	const agents: AgentConfig[] = [];
-	const diagnostics: AgentLoadDiagnostic[] = [];
-
-	for (const filePath of listFilesRecursive(dir, (fileName) => fileName.endsWith(".md"))) {
-		let content: string;
-		try {
-			content = fs.readFileSync(filePath, "utf-8");
-		} catch {
-			continue;
-		}
-
-		const { frontmatter, body, parseError } = parseFrontmatter(content);
-		if (parseError !== undefined) {
-			diagnostics.push({ path: filePath, message: parseError });
-			continue;
-		}
-
-		// Sequences are legal frontmatter but not valid `name`/`description`
-		// spellings; a file whose identity fields are not plain strings is
-		// skipped whole, exactly as upstream's loader does.
-		const localName = frontmatterString(frontmatter.name);
-		const description = frontmatterString(frontmatter.description);
-		if (!localName || !description) {
-			continue;
-		}
-
-		const parsedPackage = parsePackageName(frontmatterString(frontmatter.package), `Agent '${localName}' package`);
-		if (parsedPackage.error) continue;
-		const packageName = parsedPackage.packageName;
-		const runtimeName = buildRuntimeName(localName, packageName);
-
-		const rawTools = parseToolList(frontmatter.tools);
-		const parsedTools = splitToolList(rawTools);
-		const inheritProjectContextRaw = frontmatterBoolean(frontmatter.inheritProjectContext);
-		const inheritSkillsRaw = frontmatterBoolean(frontmatter.inheritSkills);
-		const defaultContextRaw = frontmatterString(frontmatter.defaultContext);
-		const extensionsRaw = frontmatterString(frontmatter.extensions);
-		const systemPromptModeRaw = frontmatterString(frontmatter.systemPromptMode);
-		const defaultReads = parseCommaSeparatedList(frontmatterString(frontmatter.defaultReads));
-		const skillStr = frontmatterString(frontmatter.skill) || frontmatterString(frontmatter.skills) || undefined;
-		const skills = parseCommaSeparatedList(skillStr);
-		const fallbackModels = parseCommaSeparatedList(frontmatterString(frontmatter.fallbackModels));
-		const fallbackThinkingLevels = parseCommaSeparatedList(frontmatterString(frontmatter.fallbackThinkingLevels));
-		const inheritProjectContext = inheritProjectContextRaw ?? defaultInheritProjectContext(localName);
-		const inheritSkills = inheritSkillsRaw ?? defaultInheritSkills();
-		const systemPromptMode =
-			systemPromptModeRaw === "replace"
-				? "replace"
-				: systemPromptModeRaw === "append"
-					? "append"
-					: defaultSystemPromptMode(localName);
-		const defaultContext =
-			defaultContextRaw === "fork"
-				? ("fork" as const)
-				: defaultContextRaw === "fresh"
-					? ("fresh" as const)
-					: undefined;
-		let extensions: string[] | undefined;
-		if (extensionsRaw !== undefined) {
-			extensions = extensionsRaw
-				.split(",")
-				.map((extension) => extension.trim())
-				.filter(Boolean);
-		}
-
-		const extraFields: Record<string, FrontmatterValue> = {};
-		for (const [key, value] of Object.entries(frontmatter)) {
-			if (shouldPreserveAgentExtraField(key)) extraFields[key] = value;
-		}
-
-		agents.push({
-			name: runtimeName,
-			localName,
-			packageName,
-			description,
-			tools: parsedTools.tools,
-			mcpDirectTools: parsedTools.mcpDirectTools,
-			model: frontmatterString(frontmatter.model),
-			fallbackModels,
-			fallbackThinkingLevels,
-			thinking: frontmatterString(frontmatter.thinking),
-			systemPromptMode,
-			inheritProjectContext,
-			inheritSkills,
-			defaultContext,
-			systemPrompt: body,
-			source,
-			filePath,
-			skills,
-			extensions,
-			output: frontmatterString(frontmatter.output),
-			defaultReads,
-			defaultProgress: frontmatterBoolean(frontmatter.defaultProgress) === true,
-			interactive: frontmatterBoolean(frontmatter.interactive) === true,
-			extraFields: Object.keys(extraFields).length > 0 ? extraFields : undefined,
-		});
-	}
-
-	return { agents, diagnostics };
-}
-
-export function loadAgentsFromDir(dir: string, source: AgentSource): AgentConfig[] {
-	return loadAgentsFromDirWithDiagnostics(dir, source).agents;
-}