@bastani/atomic 0.9.17 → 0.9.18-alpha.2

package/dist/core/atomic-guide-command.d.ts

@@ -1,41 +0,0 @@
-import type { AutocompleteItem } from "@earendil-works/pi-tui";
-export declare const ATOMIC_GUIDE_COMMAND_NAME = "atomic";
-export declare const ATOMIC_GUIDE_COMMAND_DESCRIPTION = "Atomic onboarding and help guide";
-declare const GUIDE_SECTIONS: readonly [{
-    readonly name: "overview";
-    readonly aliases: readonly [];
-    readonly label: "overview";
-    readonly description: "30-second overview";
-    readonly render: () => string;
-}, {
-    readonly name: "workflows";
-    readonly aliases: readonly ["workflow"];
-    readonly label: "workflows";
-    readonly description: "Workflow primer";
-    readonly render: () => string;
-}, {
-    readonly name: "example";
-    readonly aliases: readonly ["examples"];
-    readonly label: "example";
-    readonly description: "Practical first workflow";
-    readonly render: () => string;
-}, {
-    readonly name: "whats-new";
-    readonly aliases: readonly ["what's new", "whats new", "news", "updates", "changelog"];
-    readonly label: "what's new";
-    readonly description: "Recent release notes";
-    readonly render: typeof readLatestStableChangelog;
-}];
-type AtomicGuideSection = (typeof GUIDE_SECTIONS)[number];
-type AtomicGuideSectionName = AtomicGuideSection["name"];
-export type AtomicGuideHelpChoice = AtomicGuideSection["label"];
-export type AtomicGuideMode = "help" | AtomicGuideSectionName;
-export declare const ATOMIC_GUIDE_HELP_CHOICES: readonly AtomicGuideHelpChoice[];
-export declare function isAtomicGuideHelpChoice(choice: string): choice is AtomicGuideHelpChoice;
-export declare function normalizeAtomicGuideMode(args: string): AtomicGuideMode;
-export declare function getAtomicGuideArgumentCompletions(prefix: string): AutocompleteItem[] | null;
-declare function readLatestStableChangelog(cwd: string): string;
-export declare function getAtomicGuideMessage(mode: AtomicGuideMode, cwd: string): string;
-export declare function atomicGuideModeForChoice(choice: AtomicGuideHelpChoice): AtomicGuideMode;
-export {};
-//# sourceMappingURL=atomic-guide-command.d.ts.map

package/dist/core/atomic-guide-command.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"atomic-guide-command.d.ts","sourceRoot":"","sources":["../../src/core/atomic-guide-command.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,wBAAwB,CAAC;AAG/D,eAAO,MAAM,yBAAyB,WAAW,CAAC;AAClD,eAAO,MAAM,gCAAgC,qCAAqC,CAAC;AAsNnF,QAAA,MAAM,cAAc;mBAEZ,UAAU;;oBAET,UAAU;0BACJ,oBAAoB;;;mBAI3B,WAAW;;oBAEV,WAAW;0BACL,iBAAiB;;;mBAIxB,SAAS;;oBAER,SAAS;0BACH,0BAA0B;;;mBAIjC,WAAW;;oBAEV,YAAY;0BACN,sBAAsB;;EASlC,CAAC;AAEJ,KAAK,kBAAkB,GAAG,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,CAAC,CAAC;AAC1D,KAAK,sBAAsB,GAAG,kBAAkB,CAAC,MAAM,CAAC,CAAC;AAEzD,MAAM,MAAM,qBAAqB,GAAG,kBAAkB,CAAC,OAAO,CAAC,CAAC;AAEhE,MAAM,MAAM,eAAe,GAAG,MAAM,GAAG,sBAAsB,CAAC;AAE9D,eAAO,MAAM,yBAAyB,EAAE,SAAS,qBAAqB,EAErE,CAAC;AAcF,wBAAgB,uBAAuB,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM,IAAI,qBAAqB,CAEvF;AA6BD,wBAAgB,wBAAwB,CAAC,IAAI,EAAE,MAAM,GAAG,eAAe,CAKtE;AAED,wBAAgB,iCAAiC,CAAC,MAAM,EAAE,MAAM,GAAG,gBAAgB,EAAE,GAAG,IAAI,CAW3F;AAED,iBAAS,yBAAyB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CActD;AAED,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,eAAe,EAAE,GAAG,EAAE,MAAM,GAAG,MAAM,CAGhF;AAED,wBAAgB,wBAAwB,CAAC,MAAM,EAAE,qBAAqB,GAAG,eAAe,CAEvF"}

package/dist/core/atomic-guide-command.js

@@ -1,311 +0,0 @@
-import * as path from "node:path";
-import { getChangelogPath, parseChangelog } from "../utils/changelog.js";
-export const ATOMIC_GUIDE_COMMAND_NAME = "atomic";
-export const ATOMIC_GUIDE_COMMAND_DESCRIPTION = "Atomic onboarding and help guide";
-const OVERVIEW = `# Atomic overview
-
-Atomic turns non-trivial work into executable, inspectable workflows. Default to a workflow for implementation, build, debugging, bug fixes, migrations, features, scoped multi-file changes, and validated docs/code work, or whenever a request has dependencies, handoffs, uncertainty, review gates, measurable done criteria, or evidence requirements. Use direct chat for tiny deterministic low-risk answers or edits. Loop-shaped prompts such as \`do X until Y\`, \`review/fix until passing\`, or \`run checks and fix until green\` are especially strong workflow signals. Workflow-first is not builtin-only or monolithic: use named workflows, direct modes, author a custom TypeScript \`workflow({...})\` inline, or import reusable project/package and builtin definitions from \`@bastani/workflows/builtin\` and nest them with \`ctx.workflow(...)\`. Nested children may compose further children within \`maxDepth\`, enabling powerful research → implementation → verification → approval graphs from reusable parts. Start Atomic in a project with \`atomic\`, then talk to it normally. Use \`@file\` to attach files, \`!command\` to run shell output through the model, and \`!!command\` to run shell output without adding it to context.
-
-## Core session commands
-
-| Command | Use |
-|---|---|
-| \`/login\` | configure auth |
-| \`/model\` | switch model |
-| \`/settings\` | thinking level, theme, message delivery, transport |
-| \`/new\`, \`/resume\` | start or resume sessions |
-| \`/tree\`, \`/fork\`, \`/clone\` | branch or navigate session history |
-| \`/compact\` | delete safe older context verbatim |
-| \`/hotkeys\`, \`/changelog\` | local help and release notes |
-
-## Examples of using Atomic
-
-| Goal | How to use |
-|---|---|
-| On-call / broken behavior | Use a focused workflow to reproduce, diagnose, repair, and validate; direct debugger/subagent calls remain useful as stages or for tiny deterministic diagnosis |
-| Research → spec → implementation | Use \`/skill:research-codebase\`, then \`/skill:create-spec\`, then a named or custom implementation workflow with explicit validation and review |
-| Testing / regression hardening | Use a workflow for test/fix loops so retries, evidence, and the passing stop condition are tracked |
-| Large repo discovery | Use repository-focused \`fan-out-and-synthesize\` branches plus a synthesis barrier, or launch locator/analyzer/pattern-finder children with the \`subagent\` tool |
-| UI / product polish | Run \`/skill:impeccable\` for interface critique and refinement, or \`/workflow open-claude-design\` for one generated preview plus a live review session and export |
-
-## Built-in workflows
-
-| Workflow | When to use | How to run |
-|---|---|---|
-| \`classify-and-act\` | structured routing with a low-confidence human fallback | \`/workflow classify-and-act prompt="Triage this request"\` |
-| \`fan-out-and-synthesize\` | independent slices or repository-focused research with artifact synthesis | \`/workflow fan-out-and-synthesize prompt="Map payment retries by subsystem"\` |
-| \`adversarial-verification\` | fresh verification and bounded repair of a candidate | \`/workflow adversarial-verification task="Verify the migration patch"\` |
-| \`generate-and-filter\` | generate many candidates and keep a distinct shortlist | \`/workflow generate-and-filter prompt="Propose command names"\` |
-| \`tournament\` | compare whole solutions through balanced pairwise judging | \`/workflow tournament prompt="Design the retry strategy"\` |
-| \`loop-until-done\` | iterate until explicit evidence passes or the bound is exhausted | \`/workflow loop-until-done prompt="Repair failures until tests pass"\` |
-| \`goal\` | ledger-backed autonomous work with receipts and reviewer-gated completion | \`/workflow goal objective="Update CLI docs and validate the docs build"\` |
-| \`ralph\` | research-first delegated implementation with bounded multi-model review | \`/workflow ralph prompt="Implement specs/rate-limit.md"\` |
-| \`open-claude-design\` | UI and design-system generation with one live review session and export | \`/workflow open-claude-design prompt="Refresh the settings page hierarchy"\` |
-
-Use \`/workflow list\` to see what is available and \`/workflow inputs <name>\` to inspect inputs in your environment.
-
-## Top skills
-
-| Skill | When to use | How to run |
-|---|---|---|
-| \`research-codebase\` | write a grounded research artifact for one subsystem or question | \`/skill:research-codebase how the rate limiter works in src/middleware/\` |
-| \`create-spec\` | turn research into an implementation-ready plan | \`/skill:create-spec from research/docs/<date>-<topic>.md\` |
-| \`tdd\` | do test-first feature or bug work | \`/skill:tdd\` |
-| \`prompt-engineer\` | tighten a vague prompt before a long run | \`/skill:prompt-engineer Draft a sharper implementation prompt for ...\` |
-| \`subagent\` | learn when and how to delegate with the \`subagent\` tool | \`/skill:subagent\` |
-| \`impeccable\` | critique or refine frontend and product UI | \`/skill:impeccable\` |
-| \`show-me\` | explain a topic visually with concise diagrams, code-shape sketches, or focused HTML artifacts (HumanLayer, MIT) | \`/skill:show-me\` |
-
-## Subagents
-
-Subagents are focused child Atomic sessions you can point at one job inside the repo.
-
-| Built-in subagent | Use |
-|---|---|
-| \`codebase-locator\` | find relevant files, tests, entrypoints, and configs |
-| \`codebase-analyzer\` | explain current behavior with file:line refs |
-| \`codebase-pattern-finder\` | find existing code to model after |
-| \`debugger\` | reproduce, diagnose, and fix broken behavior |
-
-
-─────────────────────────────────────────────────────────────────
-
-Where to next:
-
-\`/atomic example\` — see the pieces used on a code task
-\`/atomic workflows\` — learn when to use workflows`;
-const EXAMPLE = `# Practical example
-
-This example shows a spec-driven development process whose clearly delegated autonomous implementation benefits from durable workflow execution. For interactive or conversation-led work, stay inline or use bounded subagents while the parent remains in control. Type the examples below into the Atomic TUI chat after starting \`atomic\` in your project.
-
-## 1. Research what exists
-
-Use \`/skill:research-codebase\` for a scoped area, subsystem, or directory:
-
-\`/skill:research-codebase how the rate limiter works in src/middleware/\`
-
-For repository-wide research, use \`fan-out-and-synthesize\` with distinct subsystem partitions, artifact outputs, and a synthesis prompt that cites concrete paths:
-
-\`/workflow fan-out-and-synthesize prompt="Partition payment retries by subsystem and synthesize cited end-to-end findings"\`
-
-If the research prompt is vague, tighten it first with \`/skill:prompt-engineer\`:
-
-\`/skill:prompt-engineer Draft a sharper repo-research prompt for understanding payment retries end to end, including retries, queues, and failure handling.\`
-
-## 2. Create a spec when requirements are fuzzy
-
-Skip this if the implementation request is already precise.
-
-\`/skill:create-spec from research/docs/<date>-<topic>.md\`
-
-## 3. Implement with review built in
-
-Default to a workflow for non-trivial implementation and review. Use direct chat only for tiny deterministic low-risk edits; use focused subagents inside workflow stages or for bounded specialist passes. Choose an installed workflow when it fits, or author a custom TypeScript workflow inline from the starter patterns when the task needs a richer graph.
-
-For implementation with review built in, author a task-specific worker → fresh verifier → reducer loop. Give it literal acceptance criteria, deterministic checks, evidence-backed repair payloads, and a bounded stop condition:
-
-\`Create and run a workflow that implements specs/<date>-<topic>.md, runs focused tests, sends the patch to fresh verifiers, and repairs findings until the documented behavior passes or the iteration bound is reached.\`
-
-Loop or stop-condition phrasing is a key workflow signal. Encode \`do X until Y\`, \`review/fix until passing\`, or \`run checks and fix until green\` as explicit bounded workflow gates rather than informal retries.
-
-## 4. Decide and land
-
-Use the workflow's deterministic evidence, verifier decision, remaining-work report, and bound-exhaustion state to decide whether to ship, repair, unblock, or clarify. Keep PR/MR creation, deployment, and publication as separately authorized post-approval actions.
-
-If you implemented directly instead of using a workflow, launch a fresh-context cleanup pass with the \`subagent\` tool and apply only the synthesized fixes you accept.
-
-─────────────────────────────────────────────────────────────────
-
-Where to next:
-
-\`/atomic workflows\` — learn when to use workflows
-\`/atomic overview\` — quick refresh`;
-const WORKFLOWS = `# Workflows primer
-
-A workflow is a TypeScript-defined pipeline exported from \`workflow({...})\`. It can run tasks, chains, parallel fan-out, human-in-the-loop prompts, background status, and model fallback chains.
-
-Default to workflows for non-trivial work and requests with inherent structure plus a verifiable objective. Implementation, debugging, migrations, multi-file changes, validation, review, evidence requirements, and explicit stop conditions are workflow-shaped; use direct chat only for tiny deterministic low-risk answers or edits.
-
-Workflow-first is not builtin-only or monolithic. Atomic can author custom TypeScript \`workflow({...})\` definitions inline, and workflows can import reusable project/package definitions or builtins from \`@bastani/workflows/builtin\`, then nest them with \`ctx.workflow(...)\`. Imported children can nest further children within \`maxDepth\`, so compose proven research, implementation, design, verification, and approval workflows instead of copying their stages. Use the documented starter patterns for classify-and-act routing, dynamic fan-out and synthesis, adversarial verification, candidate selection, and bounded convergence. Atomic writes the parent definition, reloads it, and runs the composed graph.
-
-## Built-in workflows
-
-| Workflow | When to use | How to run |
-|---|---|---|
-| \`classify-and-act\` | structured routing | \`/workflow classify-and-act prompt="Triage this request"\` |
-| \`fan-out-and-synthesize\` | independent slices or repository research | \`/workflow fan-out-and-synthesize prompt="Map payment retries by subsystem"\` |
-| \`adversarial-verification\` | fresh verification and bounded repair | \`/workflow adversarial-verification task="Verify the patch"\` |
-| \`generate-and-filter\` | candidate generation and shortlisting | \`/workflow generate-and-filter prompt="Propose command names"\` |
-| \`tournament\` | balanced whole-solution comparison | \`/workflow tournament prompt="Design the retry strategy"\` |
-| \`loop-until-done\` | bounded convergence on explicit evidence | \`/workflow loop-until-done prompt="Repair failures until tests pass"\` |
-| \`goal\` | durable ledger, bounded orchestration, and reviewer-gated completion | \`/workflow goal objective="Update CLI docs and validate the docs build"\` |
-| \`ralph\` | research-first delegated implementation and iterative review | \`/workflow ralph prompt="Implement specs/rate-limit.md"\` |
-| \`open-claude-design\` | frontend and product design | \`/workflow open-claude-design prompt="Refresh the settings page hierarchy"\` |
-
-Use \`/workflow inputs <name>\` to inspect exact inputs. Goal and Ralph skip PR creation unless \`create_pr=true\` explicitly authorizes their post-approval final stage. Use \`/skill:research-codebase\` for one focused subsystem and repository-focused \`fan-out-and-synthesize\` for independent whole-repository slices.
-
-If you are drafting research, reviewer, or synthesis prompts for a workflow, use \`/skill:prompt-engineer\` first. It is a good fit when a stage prompt feels vague, overloaded, or underspecified.
-
-## What good workflow authoring looks like
-
-A good workflow request is explicit about stage purpose, model choice, handoff, and the decision each step must return.
-
-For workflow-owned side effects such as filesystem writes, network mutations, and external API actions, prefer \`ctx.tool(name, args, fn)\`: completed calls are durably cached, so resume returns the saved result without rerunning \`fn\`. Keep pure computation as ordinary TypeScript, and do not wrap agent-stage internals or every function call indiscriminately.
-
-Example: ask Atomic in chat with something like this:
-
-~~~text
-Create a reusable workflow called review-changes.
-
-It should accept one required text input called target for a diff, PR summary, or review target.
-
-Run two independent review stages in parallel with fresh context:
-- one reviewer focused on correctness, regressions, and missing tests using openai-codex/gpt-5.5 at xhigh thinking
-- one reviewer focused on edge cases, maintainability, and hidden risks using anthropic/claude-opus-4-8 at xhigh thinking
-
-Then add an aggregate stage that consolidates both reviews, deduplicates overlap, keeps only evidence-backed issues, and separates blockers from optional suggestions using openai/gpt-5.5 at high thinking.
-
-Finally add an adjudicate stage using anthropic/claude-sonnet-4 at high thinking that decides what to fix now, what to defer, and what to reject. Return a short action list with rationale.
-
-The workflow should return structured output with consolidated_review and decision fields.
-~~~
-
-Why this is good:
-- it names the workflow and required input
-- it specifies which stages are parallel vs sequential
-- each stage has one job
-- it defines the handoff and final outputs
-- it calls out model choice and thinking level where that matters
-
-## Run and inspect
-
-\`/workflow list\`
-
-\`/workflow inputs fan-out-and-synthesize\`
-
-\`/workflow fan-out-and-synthesize prompt="Partition the settings flow by subsystem and synthesize cited findings"\`
-
-\`/workflow inputs adversarial-verification\`
-
-\`/workflow adversarial-verification task="Verify the settings form validation patch"\`
-
-\`/workflow status\`
-
-\`/workflow connect <run-id>\`
-
-\`/workflow interrupt <run-id>\`
-
-\`/workflow quit <run-id>\`
-
-\`/workflow resume <run-id>\`
-
-Workflows run as background tasks. Use F2 or \`/workflow connect <run-id>\` for the graph viewer. Human-in-the-loop prompts appear there, not as chat modals, and awaiting-input states do not wake the main chat agent. Completion and failure notices are steered back into the main chat; answers submitted in the workflow UI interrupt stale main-chat questions so the model does not ask again.
-
-## Author your own
-
-Describe your workflow in plain chat — say what you want the workflow to accomplish, what inputs it should accept, what stages should run, and what final output or decision it should return. Atomic will use the workflow docs to scaffold a reusable definition under \`.atomic/workflows/\`, ask clarifying questions when stage purpose, models, or handoffs are ambiguous, and run \`/workflow reload\` so you can launch it immediately.
-
-─────────────────────────────────────────────────────────────────
-
-Where to next:
-
-\`/atomic example\` — see workflows in a normal task flow
-\`/atomic overview\` — quick refresh`;
-const GUIDE_SECTIONS = [
-    {
-        name: "overview",
-        aliases: [],
-        label: "overview",
-        description: "30-second overview",
-        render: () => OVERVIEW,
-    },
-    {
-        name: "workflows",
-        aliases: ["workflow"],
-        label: "workflows",
-        description: "Workflow primer",
-        render: () => WORKFLOWS,
-    },
-    {
-        name: "example",
-        aliases: ["examples"],
-        label: "example",
-        description: "Practical first workflow",
-        render: () => EXAMPLE,
-    },
-    {
-        name: "whats-new",
-        aliases: ["what's new", "whats new", "news", "updates", "changelog"],
-        label: "what's new",
-        description: "Recent release notes",
-        render: readLatestStableChangelog,
-    },
-];
-export const ATOMIC_GUIDE_HELP_CHOICES = GUIDE_SECTIONS.map((section) => section.label);
-const GUIDE_SECTIONS_BY_NAME = new Map(GUIDE_SECTIONS.map((section) => [section.name, section]));
-const GUIDE_SECTIONS_BY_LABEL = new Map(GUIDE_SECTIONS.map((section) => [section.label, section]));
-const GUIDE_SECTIONS_BY_INPUT = new Map(GUIDE_SECTIONS.flatMap((section) => [section.name, section.label, ...section.aliases].map((input) => [input, section])));
-export function isAtomicGuideHelpChoice(choice) {
-    return GUIDE_SECTIONS_BY_LABEL.has(choice);
-}
-const ATOMIC_GUIDE_TRAILING_PUNCTUATION = "?!.,;:";
-function stripTrailingAtomicGuidePunctuation(value) {
-    let end = value.length;
-    while (end > 0 && ATOMIC_GUIDE_TRAILING_PUNCTUATION.includes(value.charAt(end - 1))) {
-        end--;
-    }
-    return value.slice(0, end);
-}
-function getGuideSectionForChoice(choice) {
-    return GUIDE_SECTIONS_BY_LABEL.get(choice);
-}
-function getGuideSectionForMode(mode) {
-    const section = GUIDE_SECTIONS_BY_NAME.get(mode);
-    if (!section)
-        throw new Error(`Unknown Atomic guide section: ${mode}`);
-    return section;
-}
-function getAtomicGuideHelpMenu() {
-    const sectionHelp = GUIDE_SECTIONS.map((section) => `- \`${section.label}\` — run \`/atomic ${section.label}\``).join("\n");
-    return `# Atomic\n\nSelect where to start:\n\n${sectionHelp}`;
-}
-export function normalizeAtomicGuideMode(args) {
-    const normalized = stripTrailingAtomicGuidePunctuation(args.trim().toLowerCase());
-    if (!normalized)
-        return "help";
-    return GUIDE_SECTIONS_BY_INPUT.get(normalized)?.name ?? "help";
-}
-export function getAtomicGuideArgumentCompletions(prefix) {
-    const query = prefix.trim().toLowerCase();
-    const items = GUIDE_SECTIONS.map((section) => ({
-        value: section.label,
-        label: section.label,
-        description: section.description,
-    }));
-    const filtered = query
-        ? items.filter((item) => item.value.startsWith(query) || item.label.startsWith(query))
-        : items;
-    return filtered.length > 0 ? filtered : null;
-}
-function readLatestStableChangelog(cwd) {
-    const changelogPath = getChangelogPath();
-    const stableSections = parseChangelog(changelogPath)
-        .filter((entry) => entry.prerelease === null)
-        .slice(0, 3)
-        .map((entry) => entry.content.trim())
-        .filter(Boolean);
-    if (stableSections.length === 0) {
-        return `# What's new\n\nNo stable release sections were found. Try \`/changelog\` for the interactive changelog viewer.\n\n─────────────────────────────────────────────────────────────────\n\nWhere to next:\n\n\`/atomic example\` — see a practical first workflow\n\`/atomic overview\` — quick refresh`;
-    }
-    const relativePath = path.relative(cwd, changelogPath) || changelogPath;
-    return `# What's new\n\n${stableSections.join("\n\n")}\n\nSource: \`${relativePath}\`\n\n─────────────────────────────────────────────────────────────────\n\nWhere to next:\n\n\`/atomic example\` — see a practical first workflow\n\`/atomic overview\` — quick refresh`;
-}
-export function getAtomicGuideMessage(mode, cwd) {
-    if (mode === "help")
-        return getAtomicGuideHelpMenu();
-    return getGuideSectionForMode(mode).render(cwd);
-}
-export function atomicGuideModeForChoice(choice) {
-    return getGuideSectionForChoice(choice)?.name ?? "help";
-}
-//# sourceMappingURL=atomic-guide-command.js.map

package/dist/core/atomic-guide-command.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"atomic-guide-command.js","sourceRoot":"","sources":["../../src/core/atomic-guide-command.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,IAAI,MAAM,WAAW,CAAC;AAElC,OAAO,EAAE,gBAAgB,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AAEzE,MAAM,CAAC,MAAM,yBAAyB,GAAG,QAAQ,CAAC;AAClD,MAAM,CAAC,MAAM,gCAAgC,GAAG,kCAAkC,CAAC;AAEnF,MAAM,QAAQ,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oDAuEmC,CAAC;AAErD,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;qCA6CqB,CAAC;AAEtC,MAAM,SAAS,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;qCA0FmB,CAAC;AAEtC,MAAM,cAAc,GAAG;IACtB;QACC,IAAI,EAAE,UAAU;QAChB,OAAO,EAAE,EAAE;QACX,KAAK,EAAE,UAAU;QACjB,WAAW,EAAE,oBAAoB;QACjC,MAAM,EAAE,GAAG,EAAE,CAAC,QAAQ;KACtB;IACD;QACC,IAAI,EAAE,WAAW;QACjB,OAAO,EAAE,CAAC,UAAU,CAAC;QACrB,KAAK,EAAE,WAAW;QAClB,WAAW,EAAE,iBAAiB;QAC9B,MAAM,EAAE,GAAG,EAAE,CAAC,SAAS;KACvB;IACD;QACC,IAAI,EAAE,SAAS;QACf,OAAO,EAAE,CAAC,UAAU,CAAC;QACrB,KAAK,EAAE,SAAS;QAChB,WAAW,EAAE,0BAA0B;QACvC,MAAM,EAAE,GAAG,EAAE,CAAC,OAAO;KACrB;IACD;QACC,IAAI,EAAE,WAAW;QACjB,OAAO,EAAE,CAAC,YAAY,EAAE,WAAW,EAAE,MAAM,EAAE,SAAS,EAAE,WAAW,CAAC;QACpE,KAAK,EAAE,YAAY;QACnB,WAAW,EAAE,sBAAsB;QACnC,MAAM,EAAE,yBAAyB;KACjC;CAOC,CAAC;AASJ,MAAM,CAAC,MAAM,yBAAyB,GAAqC,cAAc,CAAC,GAAG,CAC5F,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,KAAK,CAC1B,CAAC;AAEF,MAAM,sBAAsB,GAAG,IAAI,GAAG,CACrC,cAAc,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,OAAO,CAAC,CAAC,CACxD,CAAC;AACF,MAAM,uBAAuB,GAAG,IAAI,GAAG,CACtC,cAAc,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC,CACzD,CAAC;AACF,MAAM,uBAAuB,GAAG,IAAI,GAAG,CACtC,cAAc,CAAC,OAAO,CAAC,CAAC,OAAO,EAAE,EAAE,CAClC,CAAC,OAAO,CAAC,IAAI,EAAE,OAAO,CAAC,KAAK,EAAE,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC,KAAK,EAAE,OAAO,CAAU,CAAC,CAC3F,CACD,CAAC;AAEF,MAAM,UAAU,uBAAuB,CAAC,MAAc;IACrD,OAAO,uBAAuB,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;AAC5C,CAAC;AAED,MAAM,iCAAiC,GAAG,QAAQ,CAAC;AAEnD,SAAS,mCAAmC,CAAC,KAAa;IACzD,IAAI,GAAG,GAAG,KAAK,CAAC,MAAM,CAAC;IACvB,OAAO,GAAG,GAAG,CAAC,IAAI,iCAAiC,CAAC,QAAQ,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC;QACrF,GAAG,EAAE,CAAC;IACP,CAAC;IACD,OAAO,KAAK,CAAC,KAAK,CAAC,CAAC,EAAE,GAAG,CAAC,CAAC;AAC5B,CAAC;AAED,SAAS,wBAAwB,CAAC,MAAc;IAC/C,OAAO,uBAAuB,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;AAC5C,CAAC;AAED,SAAS,sBAAsB,CAAC,IAA4B;IAC3D,MAAM,OAAO,GAAG,sBAAsB,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;IACjD,IAAI,CAAC,OAAO;QAAE,MAAM,IAAI,KAAK,CAAC,iCAAiC,IAAI,EAAE,CAAC,CAAC;IACvE,OAAO,OAAO,CAAC;AAChB,CAAC;AAED,SAAS,sBAAsB;IAC9B,MAAM,WAAW,GAAG,cAAc,CAAC,GAAG,CACrC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,OAAO,CAAC,KAAK,sBAAsB,OAAO,CAAC,KAAK,IAAI,CACxE,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IACb,OAAO,yCAAyC,WAAW,EAAE,CAAC;AAC/D,CAAC;AAED,MAAM,UAAU,wBAAwB,CAAC,IAAY;IACpD,MAAM,UAAU,GAAG,mCAAmC,CAAC,IAAI,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC,CAAC;IAClF,IAAI,CAAC,UAAU;QAAE,OAAO,MAAM,CAAC;IAE/B,OAAO,uBAAuB,CAAC,GAAG,CAAC,UAAU,CAAC,EAAE,IAAI,IAAI,MAAM,CAAC;AAChE,CAAC;AAED,MAAM,UAAU,iCAAiC,CAAC,MAAc;IAC/D,MAAM,KAAK,GAAG,MAAM,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;IAC1C,MAAM,KAAK,GAAG,cAAc,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,CAAC;QAC9C,KAAK,EAAE,OAAO,CAAC,KAAK;QACpB,KAAK,EAAE,OAAO,CAAC,KAAK;QACpB,WAAW,EAAE,OAAO,CAAC,WAAW;KAChC,CAAC,CAAC,CAAC;IACJ,MAAM,QAAQ,GAAG,KAAK;QACrB,CAAC,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,KAAK,CAAC,UAAU,CAAC,KAAK,CAAC,IAAI,IAAI,CAAC,KAAK,CAAC,UAAU,CAAC,KAAK,CAAC,CAAC;QACtF,CAAC,CAAC,KAAK,CAAC;IACT,OAAO,QAAQ,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,IAAI,CAAC;AAC9C,CAAC;AAED,SAAS,yBAAyB,CAAC,GAAW;IAC7C,MAAM,aAAa,GAAG,gBAAgB,EAAE,CAAC;IACzC,MAAM,cAAc,GAAG,cAAc,CAAC,aAAa,CAAC;SAClD,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,UAAU,KAAK,IAAI,CAAC;SAC5C,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC;SACX,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,OAAO,CAAC,IAAI,EAAE,CAAC;SACpC,MAAM,CAAC,OAAO,CAAC,CAAC;IAElB,IAAI,cAAc,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACjC,OAAO,sSAAsS,CAAC;IAC/S,CAAC;IAED,MAAM,YAAY,GAAG,IAAI,CAAC,QAAQ,CAAC,GAAG,EAAE,aAAa,CAAC,IAAI,aAAa,CAAC;IACxE,OAAO,mBAAmB,cAAc,CAAC,IAAI,CAAC,MAAM,CAAC,iBAAiB,YAAY,yLAAyL,CAAC;AAC7Q,CAAC;AAED,MAAM,UAAU,qBAAqB,CAAC,IAAqB,EAAE,GAAW;IACvE,IAAI,IAAI,KAAK,MAAM;QAAE,OAAO,sBAAsB,EAAE,CAAC;IACrD,OAAO,sBAAsB,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;AACjD,CAAC;AAED,MAAM,UAAU,wBAAwB,CAAC,MAA6B;IACrE,OAAO,wBAAwB,CAAC,MAAM,CAAC,EAAE,IAAI,IAAI,MAAM,CAAC;AACzD,CAAC","sourcesContent":["import * as path from \"node:path\";\nimport type { AutocompleteItem } from \"@earendil-works/pi-tui\";\nimport { getChangelogPath, parseChangelog } from \"../utils/changelog.ts\";\n\nexport const ATOMIC_GUIDE_COMMAND_NAME = \"atomic\";\nexport const ATOMIC_GUIDE_COMMAND_DESCRIPTION = \"Atomic onboarding and help guide\";\n\nconst OVERVIEW = `# Atomic overview\n\nAtomic turns non-trivial work into executable, inspectable workflows. Default to a workflow for implementation, build, debugging, bug fixes, migrations, features, scoped multi-file changes, and validated docs/code work, or whenever a request has dependencies, handoffs, uncertainty, review gates, measurable done criteria, or evidence requirements. Use direct chat for tiny deterministic low-risk answers or edits. Loop-shaped prompts such as \\`do X until Y\\`, \\`review/fix until passing\\`, or \\`run checks and fix until green\\` are especially strong workflow signals. Workflow-first is not builtin-only or monolithic: use named workflows, direct modes, author a custom TypeScript \\`workflow({...})\\` inline, or import reusable project/package and builtin definitions from \\`@bastani/workflows/builtin\\` and nest them with \\`ctx.workflow(...)\\`. Nested children may compose further children within \\`maxDepth\\`, enabling powerful research → implementation → verification → approval graphs from reusable parts. Start Atomic in a project with \\`atomic\\`, then talk to it normally. Use \\`@file\\` to attach files, \\`!command\\` to run shell output through the model, and \\`!!command\\` to run shell output without adding it to context.\n\n## Core session commands\n\n| Command | Use |\n|---|---|\n| \\`/login\\` | configure auth |\n| \\`/model\\` | switch model |\n| \\`/settings\\` | thinking level, theme, message delivery, transport |\n| \\`/new\\`, \\`/resume\\` | start or resume sessions |\n| \\`/tree\\`, \\`/fork\\`, \\`/clone\\` | branch or navigate session history |\n| \\`/compact\\` | delete safe older context verbatim |\n| \\`/hotkeys\\`, \\`/changelog\\` | local help and release notes |\n\n## Examples of using Atomic\n\n| Goal | How to use |\n|---|---|\n| On-call / broken behavior | Use a focused workflow to reproduce, diagnose, repair, and validate; direct debugger/subagent calls remain useful as stages or for tiny deterministic diagnosis |\n| Research → spec → implementation | Use \\`/skill:research-codebase\\`, then \\`/skill:create-spec\\`, then a named or custom implementation workflow with explicit validation and review |\n| Testing / regression hardening | Use a workflow for test/fix loops so retries, evidence, and the passing stop condition are tracked |\n| Large repo discovery | Use repository-focused \\`fan-out-and-synthesize\\` branches plus a synthesis barrier, or launch locator/analyzer/pattern-finder children with the \\`subagent\\` tool |\n| UI / product polish | Run \\`/skill:impeccable\\` for interface critique and refinement, or \\`/workflow open-claude-design\\` for one generated preview plus a live review session and export |\n\n## Built-in workflows\n\n| Workflow | When to use | How to run |\n|---|---|---|\n| \\`classify-and-act\\` | structured routing with a low-confidence human fallback | \\`/workflow classify-and-act prompt=\"Triage this request\"\\` |\n| \\`fan-out-and-synthesize\\` | independent slices or repository-focused research with artifact synthesis | \\`/workflow fan-out-and-synthesize prompt=\"Map payment retries by subsystem\"\\` |\n| \\`adversarial-verification\\` | fresh verification and bounded repair of a candidate | \\`/workflow adversarial-verification task=\"Verify the migration patch\"\\` |\n| \\`generate-and-filter\\` | generate many candidates and keep a distinct shortlist | \\`/workflow generate-and-filter prompt=\"Propose command names\"\\` |\n| \\`tournament\\` | compare whole solutions through balanced pairwise judging | \\`/workflow tournament prompt=\"Design the retry strategy\"\\` |\n| \\`loop-until-done\\` | iterate until explicit evidence passes or the bound is exhausted | \\`/workflow loop-until-done prompt=\"Repair failures until tests pass\"\\` |\n| \\`goal\\` | ledger-backed autonomous work with receipts and reviewer-gated completion | \\`/workflow goal objective=\"Update CLI docs and validate the docs build\"\\` |\n| \\`ralph\\` | research-first delegated implementation with bounded multi-model review | \\`/workflow ralph prompt=\"Implement specs/rate-limit.md\"\\` |\n| \\`open-claude-design\\` | UI and design-system generation with one live review session and export | \\`/workflow open-claude-design prompt=\"Refresh the settings page hierarchy\"\\` |\n\nUse \\`/workflow list\\` to see what is available and \\`/workflow inputs <name>\\` to inspect inputs in your environment.\n\n## Top skills\n\n| Skill | When to use | How to run |\n|---|---|---|\n| \\`research-codebase\\` | write a grounded research artifact for one subsystem or question | \\`/skill:research-codebase how the rate limiter works in src/middleware/\\` |\n| \\`create-spec\\` | turn research into an implementation-ready plan | \\`/skill:create-spec from research/docs/<date>-<topic>.md\\` |\n| \\`tdd\\` | do test-first feature or bug work | \\`/skill:tdd\\` |\n| \\`prompt-engineer\\` | tighten a vague prompt before a long run | \\`/skill:prompt-engineer Draft a sharper implementation prompt for ...\\` |\n| \\`subagent\\` | learn when and how to delegate with the \\`subagent\\` tool | \\`/skill:subagent\\` |\n| \\`impeccable\\` | critique or refine frontend and product UI | \\`/skill:impeccable\\` |\n| \\`show-me\\` | explain a topic visually with concise diagrams, code-shape sketches, or focused HTML artifacts (HumanLayer, MIT) | \\`/skill:show-me\\` |\n\n## Subagents\n\nSubagents are focused child Atomic sessions you can point at one job inside the repo.\n\n| Built-in subagent | Use |\n|---|---|\n| \\`codebase-locator\\` | find relevant files, tests, entrypoints, and configs |\n| \\`codebase-analyzer\\` | explain current behavior with file:line refs |\n| \\`codebase-pattern-finder\\` | find existing code to model after |\n| \\`debugger\\` | reproduce, diagnose, and fix broken behavior |\n\n\n─────────────────────────────────────────────────────────────────\n\nWhere to next:\n\n\\`/atomic example\\` — see the pieces used on a code task\n\\`/atomic workflows\\` — learn when to use workflows`;\n\nconst EXAMPLE = `# Practical example\n\nThis example shows a spec-driven development process whose clearly delegated autonomous implementation benefits from durable workflow execution. For interactive or conversation-led work, stay inline or use bounded subagents while the parent remains in control. Type the examples below into the Atomic TUI chat after starting \\`atomic\\` in your project.\n\n## 1. Research what exists\n\nUse \\`/skill:research-codebase\\` for a scoped area, subsystem, or directory:\n\n\\`/skill:research-codebase how the rate limiter works in src/middleware/\\`\n\nFor repository-wide research, use \\`fan-out-and-synthesize\\` with distinct subsystem partitions, artifact outputs, and a synthesis prompt that cites concrete paths:\n\n\\`/workflow fan-out-and-synthesize prompt=\"Partition payment retries by subsystem and synthesize cited end-to-end findings\"\\`\n\nIf the research prompt is vague, tighten it first with \\`/skill:prompt-engineer\\`:\n\n\\`/skill:prompt-engineer Draft a sharper repo-research prompt for understanding payment retries end to end, including retries, queues, and failure handling.\\`\n\n## 2. Create a spec when requirements are fuzzy\n\nSkip this if the implementation request is already precise.\n\n\\`/skill:create-spec from research/docs/<date>-<topic>.md\\`\n\n## 3. Implement with review built in\n\nDefault to a workflow for non-trivial implementation and review. Use direct chat only for tiny deterministic low-risk edits; use focused subagents inside workflow stages or for bounded specialist passes. Choose an installed workflow when it fits, or author a custom TypeScript workflow inline from the starter patterns when the task needs a richer graph.\n\nFor implementation with review built in, author a task-specific worker → fresh verifier → reducer loop. Give it literal acceptance criteria, deterministic checks, evidence-backed repair payloads, and a bounded stop condition:\n\n\\`Create and run a workflow that implements specs/<date>-<topic>.md, runs focused tests, sends the patch to fresh verifiers, and repairs findings until the documented behavior passes or the iteration bound is reached.\\`\n\nLoop or stop-condition phrasing is a key workflow signal. Encode \\`do X until Y\\`, \\`review/fix until passing\\`, or \\`run checks and fix until green\\` as explicit bounded workflow gates rather than informal retries.\n\n## 4. Decide and land\n\nUse the workflow's deterministic evidence, verifier decision, remaining-work report, and bound-exhaustion state to decide whether to ship, repair, unblock, or clarify. Keep PR/MR creation, deployment, and publication as separately authorized post-approval actions.\n\nIf you implemented directly instead of using a workflow, launch a fresh-context cleanup pass with the \\`subagent\\` tool and apply only the synthesized fixes you accept.\n\n─────────────────────────────────────────────────────────────────\n\nWhere to next:\n\n\\`/atomic workflows\\` — learn when to use workflows\n\\`/atomic overview\\` — quick refresh`;\n\nconst WORKFLOWS = `# Workflows primer\n\nA workflow is a TypeScript-defined pipeline exported from \\`workflow({...})\\`. It can run tasks, chains, parallel fan-out, human-in-the-loop prompts, background status, and model fallback chains.\n\nDefault to workflows for non-trivial work and requests with inherent structure plus a verifiable objective. Implementation, debugging, migrations, multi-file changes, validation, review, evidence requirements, and explicit stop conditions are workflow-shaped; use direct chat only for tiny deterministic low-risk answers or edits.\n\nWorkflow-first is not builtin-only or monolithic. Atomic can author custom TypeScript \\`workflow({...})\\` definitions inline, and workflows can import reusable project/package definitions or builtins from \\`@bastani/workflows/builtin\\`, then nest them with \\`ctx.workflow(...)\\`. Imported children can nest further children within \\`maxDepth\\`, so compose proven research, implementation, design, verification, and approval workflows instead of copying their stages. Use the documented starter patterns for classify-and-act routing, dynamic fan-out and synthesis, adversarial verification, candidate selection, and bounded convergence. Atomic writes the parent definition, reloads it, and runs the composed graph.\n\n## Built-in workflows\n\n| Workflow | When to use | How to run |\n|---|---|---|\n| \\`classify-and-act\\` | structured routing | \\`/workflow classify-and-act prompt=\"Triage this request\"\\` |\n| \\`fan-out-and-synthesize\\` | independent slices or repository research | \\`/workflow fan-out-and-synthesize prompt=\"Map payment retries by subsystem\"\\` |\n| \\`adversarial-verification\\` | fresh verification and bounded repair | \\`/workflow adversarial-verification task=\"Verify the patch\"\\` |\n| \\`generate-and-filter\\` | candidate generation and shortlisting | \\`/workflow generate-and-filter prompt=\"Propose command names\"\\` |\n| \\`tournament\\` | balanced whole-solution comparison | \\`/workflow tournament prompt=\"Design the retry strategy\"\\` |\n| \\`loop-until-done\\` | bounded convergence on explicit evidence | \\`/workflow loop-until-done prompt=\"Repair failures until tests pass\"\\` |\n| \\`goal\\` | durable ledger, bounded orchestration, and reviewer-gated completion | \\`/workflow goal objective=\"Update CLI docs and validate the docs build\"\\` |\n| \\`ralph\\` | research-first delegated implementation and iterative review | \\`/workflow ralph prompt=\"Implement specs/rate-limit.md\"\\` |\n| \\`open-claude-design\\` | frontend and product design | \\`/workflow open-claude-design prompt=\"Refresh the settings page hierarchy\"\\` |\n\nUse \\`/workflow inputs <name>\\` to inspect exact inputs. Goal and Ralph skip PR creation unless \\`create_pr=true\\` explicitly authorizes their post-approval final stage. Use \\`/skill:research-codebase\\` for one focused subsystem and repository-focused \\`fan-out-and-synthesize\\` for independent whole-repository slices.\n\nIf you are drafting research, reviewer, or synthesis prompts for a workflow, use \\`/skill:prompt-engineer\\` first. It is a good fit when a stage prompt feels vague, overloaded, or underspecified.\n\n## What good workflow authoring looks like\n\nA good workflow request is explicit about stage purpose, model choice, handoff, and the decision each step must return.\n\nFor workflow-owned side effects such as filesystem writes, network mutations, and external API actions, prefer \\`ctx.tool(name, args, fn)\\`: completed calls are durably cached, so resume returns the saved result without rerunning \\`fn\\`. Keep pure computation as ordinary TypeScript, and do not wrap agent-stage internals or every function call indiscriminately.\n\nExample: ask Atomic in chat with something like this:\n\n~~~text\nCreate a reusable workflow called review-changes.\n\nIt should accept one required text input called target for a diff, PR summary, or review target.\n\nRun two independent review stages in parallel with fresh context:\n- one reviewer focused on correctness, regressions, and missing tests using openai-codex/gpt-5.5 at xhigh thinking\n- one reviewer focused on edge cases, maintainability, and hidden risks using anthropic/claude-opus-4-8 at xhigh thinking\n\nThen add an aggregate stage that consolidates both reviews, deduplicates overlap, keeps only evidence-backed issues, and separates blockers from optional suggestions using openai/gpt-5.5 at high thinking.\n\nFinally add an adjudicate stage using anthropic/claude-sonnet-4 at high thinking that decides what to fix now, what to defer, and what to reject. Return a short action list with rationale.\n\nThe workflow should return structured output with consolidated_review and decision fields.\n~~~\n\nWhy this is good:\n- it names the workflow and required input\n- it specifies which stages are parallel vs sequential\n- each stage has one job\n- it defines the handoff and final outputs\n- it calls out model choice and thinking level where that matters\n\n## Run and inspect\n\n\\`/workflow list\\`\n\n\\`/workflow inputs fan-out-and-synthesize\\`\n\n\\`/workflow fan-out-and-synthesize prompt=\"Partition the settings flow by subsystem and synthesize cited findings\"\\`\n\n\\`/workflow inputs adversarial-verification\\`\n\n\\`/workflow adversarial-verification task=\"Verify the settings form validation patch\"\\`\n\n\\`/workflow status\\`\n\n\\`/workflow connect <run-id>\\`\n\n\\`/workflow interrupt <run-id>\\`\n\n\\`/workflow quit <run-id>\\`\n\n\\`/workflow resume <run-id>\\`\n\nWorkflows run as background tasks. Use F2 or \\`/workflow connect <run-id>\\` for the graph viewer. Human-in-the-loop prompts appear there, not as chat modals, and awaiting-input states do not wake the main chat agent. Completion and failure notices are steered back into the main chat; answers submitted in the workflow UI interrupt stale main-chat questions so the model does not ask again.\n\n## Author your own\n\nDescribe your workflow in plain chat — say what you want the workflow to accomplish, what inputs it should accept, what stages should run, and what final output or decision it should return. Atomic will use the workflow docs to scaffold a reusable definition under \\`.atomic/workflows/\\`, ask clarifying questions when stage purpose, models, or handoffs are ambiguous, and run \\`/workflow reload\\` so you can launch it immediately.\n\n─────────────────────────────────────────────────────────────────\n\nWhere to next:\n\n\\`/atomic example\\` — see workflows in a normal task flow\n\\`/atomic overview\\` — quick refresh`;\n\nconst GUIDE_SECTIONS = [\n\t{\n\t\tname: \"overview\",\n\t\taliases: [],\n\t\tlabel: \"overview\",\n\t\tdescription: \"30-second overview\",\n\t\trender: () => OVERVIEW,\n\t},\n\t{\n\t\tname: \"workflows\",\n\t\taliases: [\"workflow\"],\n\t\tlabel: \"workflows\",\n\t\tdescription: \"Workflow primer\",\n\t\trender: () => WORKFLOWS,\n\t},\n\t{\n\t\tname: \"example\",\n\t\taliases: [\"examples\"],\n\t\tlabel: \"example\",\n\t\tdescription: \"Practical first workflow\",\n\t\trender: () => EXAMPLE,\n\t},\n\t{\n\t\tname: \"whats-new\",\n\t\taliases: [\"what's new\", \"whats new\", \"news\", \"updates\", \"changelog\"],\n\t\tlabel: \"what's new\",\n\t\tdescription: \"Recent release notes\",\n\t\trender: readLatestStableChangelog,\n\t},\n] as const satisfies readonly {\n\treadonly name: string;\n\treadonly aliases: readonly string[];\n\treadonly label: string;\n\treadonly description: string;\n\treadonly render: (cwd: string) => string;\n}[];\n\ntype AtomicGuideSection = (typeof GUIDE_SECTIONS)[number];\ntype AtomicGuideSectionName = AtomicGuideSection[\"name\"];\n\nexport type AtomicGuideHelpChoice = AtomicGuideSection[\"label\"];\n\nexport type AtomicGuideMode = \"help\" | AtomicGuideSectionName;\n\nexport const ATOMIC_GUIDE_HELP_CHOICES: readonly AtomicGuideHelpChoice[] = GUIDE_SECTIONS.map(\n\t(section) => section.label,\n);\n\nconst GUIDE_SECTIONS_BY_NAME = new Map<AtomicGuideSectionName, AtomicGuideSection>(\n\tGUIDE_SECTIONS.map((section) => [section.name, section]),\n);\nconst GUIDE_SECTIONS_BY_LABEL = new Map<string, AtomicGuideSection>(\n\tGUIDE_SECTIONS.map((section) => [section.label, section]),\n);\nconst GUIDE_SECTIONS_BY_INPUT = new Map<string, AtomicGuideSection>(\n\tGUIDE_SECTIONS.flatMap((section) =>\n\t\t[section.name, section.label, ...section.aliases].map((input) => [input, section] as const),\n\t),\n);\n\nexport function isAtomicGuideHelpChoice(choice: string): choice is AtomicGuideHelpChoice {\n\treturn GUIDE_SECTIONS_BY_LABEL.has(choice);\n}\n\nconst ATOMIC_GUIDE_TRAILING_PUNCTUATION = \"?!.,;:\";\n\nfunction stripTrailingAtomicGuidePunctuation(value: string): string {\n\tlet end = value.length;\n\twhile (end > 0 && ATOMIC_GUIDE_TRAILING_PUNCTUATION.includes(value.charAt(end - 1))) {\n\t\tend--;\n\t}\n\treturn value.slice(0, end);\n}\n\nfunction getGuideSectionForChoice(choice: string): AtomicGuideSection | undefined {\n\treturn GUIDE_SECTIONS_BY_LABEL.get(choice);\n}\n\nfunction getGuideSectionForMode(mode: AtomicGuideSectionName): AtomicGuideSection {\n\tconst section = GUIDE_SECTIONS_BY_NAME.get(mode);\n\tif (!section) throw new Error(`Unknown Atomic guide section: ${mode}`);\n\treturn section;\n}\n\nfunction getAtomicGuideHelpMenu(): string {\n\tconst sectionHelp = GUIDE_SECTIONS.map(\n\t\t(section) => `- \\`${section.label}\\` — run \\`/atomic ${section.label}\\``,\n\t).join(\"\\n\");\n\treturn `# Atomic\\n\\nSelect where to start:\\n\\n${sectionHelp}`;\n}\n\nexport function normalizeAtomicGuideMode(args: string): AtomicGuideMode {\n\tconst normalized = stripTrailingAtomicGuidePunctuation(args.trim().toLowerCase());\n\tif (!normalized) return \"help\";\n\n\treturn GUIDE_SECTIONS_BY_INPUT.get(normalized)?.name ?? \"help\";\n}\n\nexport function getAtomicGuideArgumentCompletions(prefix: string): AutocompleteItem[] | null {\n\tconst query = prefix.trim().toLowerCase();\n\tconst items = GUIDE_SECTIONS.map((section) => ({\n\t\tvalue: section.label,\n\t\tlabel: section.label,\n\t\tdescription: section.description,\n\t}));\n\tconst filtered = query\n\t\t? items.filter((item) => item.value.startsWith(query) || item.label.startsWith(query))\n\t\t: items;\n\treturn filtered.length > 0 ? filtered : null;\n}\n\nfunction readLatestStableChangelog(cwd: string): string {\n\tconst changelogPath = getChangelogPath();\n\tconst stableSections = parseChangelog(changelogPath)\n\t\t.filter((entry) => entry.prerelease === null)\n\t\t.slice(0, 3)\n\t\t.map((entry) => entry.content.trim())\n\t\t.filter(Boolean);\n\n\tif (stableSections.length === 0) {\n\t\treturn `# What's new\\n\\nNo stable release sections were found. Try \\`/changelog\\` for the interactive changelog viewer.\\n\\n─────────────────────────────────────────────────────────────────\\n\\nWhere to next:\\n\\n\\`/atomic example\\` — see a practical first workflow\\n\\`/atomic overview\\` — quick refresh`;\n\t}\n\n\tconst relativePath = path.relative(cwd, changelogPath) || changelogPath;\n\treturn `# What's new\\n\\n${stableSections.join(\"\\n\\n\")}\\n\\nSource: \\`${relativePath}\\`\\n\\n─────────────────────────────────────────────────────────────────\\n\\nWhere to next:\\n\\n\\`/atomic example\\` — see a practical first workflow\\n\\`/atomic overview\\` — quick refresh`;\n}\n\nexport function getAtomicGuideMessage(mode: AtomicGuideMode, cwd: string): string {\n\tif (mode === \"help\") return getAtomicGuideHelpMenu();\n\treturn getGuideSectionForMode(mode).render(cwd);\n}\n\nexport function atomicGuideModeForChoice(choice: AtomicGuideHelpChoice): AtomicGuideMode {\n\treturn getGuideSectionForChoice(choice)?.name ?? \"help\";\n}\n"]}