feat(workflows): print the generated workflow folder after creating a custom workflow

[morgan-coded]

After Atomic creates a custom workflow, the success output never said where the generated code lives — users had to discover the storage location on their own (#1978). Custom workflows are authored by the running agent under model-visible guidance, so this change encodes the disclosure in that tested guidance contract plus the matching docs.

Acceptance criteria covered:

• After successful custom workflow creation, the success output states the folder containing the generated code, using the issue's message shape: Custom workflow created. You can inspect its code at: <workflow-folder-path> (packages/workflows/src/extension/workflow-prompts.ts: both WORKFLOW_TOOL_DESCRIPTION and the authoring section of DEFAULT_PROMPT_GUIDANCE).
• The message makes clear the workflow code can be inspected there (verbatim shape from the issue).
• Applies only to newly created custom workflows: the guidance explicitly excludes builtin and pre-existing workflows.
• No other workflow behavior or scope changes: the diff is the guidance text, its README JSON-example mirror, the two docs creation flows, one focused test, and a changelog entry.

Tests: test/unit/workflow-authoring-folder-disclosure.test.ts pins the message shape and the newly-created-only scoping across the tool description, the joined prompt guidance, docs/workflows.md, and docs/quickstart.md. It follows the execution-routing-guidance pattern as a separate file because that suite sits at the 500-line file-length gate.

Docs: the creation-flow lists in workflows.md and quickstart.md now end with the folder disclosure step; packages/workflows/README.md stays byte-synced with the tool description (covered by the existing integration assertion); changelog entry under @bastani/workflows Unreleased → Added.

Closes #1978

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

Greptile Summary

Adds model-facing guidance and matching documentation requiring Atomic to report the generated folder after creating a custom workflow.

• Updates workflow tool and prompt guidance with the scoped disclosure message.
• Synchronizes workflow documentation, package README, and changelog.
• Adds focused tests for message wording and newly-created-only scope.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failures remain.

T-Rex Logs

What T-Rex did

• Ran the Bun test command for test/unit/workflow-authoring-folder-disclosure.test.ts in the repository.
• The test run completed with exit code 0 and produced output that was captured for validation.
• Artifacts documenting the run were attached, including a test run log accessible via URL and a plain-text validation note.

_{Ran code and verified through T-Rex}

Important Files Changed

Filename	Overview
packages/workflows/src/extension/workflow-prompts.ts	Adds consistent, narrowly scoped folder-disclosure guidance for newly authored custom workflows.
test/unit/workflow-authoring-folder-disclosure.test.ts	Adds focused assertions covering the disclosure wording and scope across prompts and documentation.
packages/workflows/README.md	Keeps the documented workflow tool description synchronized with its source definition.
packages/coding-agent/docs/workflows.md	Documents the folder-disclosure step in the custom workflow creation flow.
packages/coding-agent/docs/quickstart.md	Adds the same scoped disclosure behavior to the quickstart workflow-authoring instructions.

_{Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[flora131]

Review result: no blocking findings

Correction: My first review treated issue #1978 as requiring a new host-side output path. That was too strict for Atomic's current custom-workflow authoring design.

Custom workflows are created by the running agent through normal file tools, then reloaded through the workflow tool. There is no separate runtime create workflow operation that knows whether a file is new or pre-existing. User-facing completion details for this kind of agent-authored action therefore come from model-visible guidance.

That differs from workflow-runtime UI such as background launch/connect hints and lifecycle notices, which Atomic generates deterministically. For example:

• packages/workflows/src/runs/background/runner.ts:69-83 constructs the /workflow connect <run> launch hint.
• packages/workflows/src/extension/lifecycle-notifications.ts:299-324 formats completion, failure, blocked, and input notices.

Within the agent-authored completion layer, this PR uses the established mechanism correctly:

• packages/workflows/src/extension/workflow-prompts.ts adds the disclosure to both the workflow tool description and the workflow-authoring prompt guidance.
• The guidance limits it to newly created custom workflows and excludes builtin and pre-existing workflows.
• The focused test pins the message and scope across both model-visible guidance surfaces and the user docs.
• The docs match the intended agent behavior.

A host-side guarantee would require a new creation API or tracking intent across ordinary file writes, edits, reloads, and agent responses. That would be a larger design change than issue #1978 calls for.

Review scope

• PR: feat(workflows): print the generated workflow folder after creating a custom workflow #2025
• Exact head tested: 591e59840b2c5f9aed811170fc0da68425d39d51
• The checkout matched that SHA and remained clean.
• The coding-agent CLI was built from that checkout with bun run --cwd packages/coding-agent build.

Real interactive source CLI test

tmux target: atomic-pr-2025-591e59840b2c-live:0.0

This was not a smoke test. I ran the source-built interactive Atomic TUI in tmux against a temporary project. The session created a real custom workflow, checked its file on disk, reloaded it, executed its model stage, inspected the completed output, and then ran an existing-workflow control.

The source CLI was launched from:

/tmp/atomic-pr-2025-591e59840b2c-live-review/packages/coding-agent/dist/cli.js

Creation and execution

Atomic created:

/tmp/atomic-pr-2025-591e59840b2c-cli-fixture/.atomic/workflows/pr-2025-live-evidence.ts

The workflow had the requested string input, model stage, and string result. After an initial generated-schema error, Atomic corrected the new workflow, reloaded it, and completed the real run:

✓ Workflow "pr-2025-live-evidence" completed
run       a5906c6b-f2a1-4876-ae66-725c539f2806
result    {"result":"LIVE_PR_2025_END_TO_END"}

The final agent response included the expected disclosure exactly once:

Custom workflow created. You can inspect its code at: .atomic/workflows/

Resolving that path from the test project matched the actual folder containing the generated workflow file.

Existing-workflow control

The same live CLI then ran the already-created workflow with message=EXISTING_WORKFLOW_CONTROL without creating or editing it:

✓ Workflow "pr-2025-live-evidence" completed
run       c7256932-aa5c-4387-be16-3dc0eeaf44fa
result    {"result":"EXISTING_WORKFLOW_CONTROL"}

Within the bounded control output:

• Workflow write calls: 0
• Workflow edit calls: 0
• Custom workflow created. occurrences: 0
• You can inspect its code at: occurrences: 0

This confirms the changed guidance worked in the actual CLI for both the positive creation case and the run-only control.

Bun checks

Command	Exit code	Result
bun test test/unit/workflow-authoring-folder-disclosure.test.ts	0	2 passed, 0 failed
bun run typecheck	0	Passed
bun run check:file-length	0	2,463 tracked files checked; passed
bun run test:unit	0	4,245 passed, 1 skipped, 0 failed

Residual limits

• The live run covered one project-scoped workflow and one configured model/provider.
• It did not cover user-scoped workflow creation or editing a pre-existing workflow.
• Those limits do not create a blocker for this prompt-guidance change; the focused contract test and successful real CLI path cover the PR's intended scope.

Final verdict: no blocking findings in the reviewed scope.

[flora131]

Thanks @morgan-coded, this has been merged.