Workflow is a TypeScript SDK for building applications and AI agents whose work can continue reliably across steps and be observed while running. It is for developers creating durable workflows and orchestration logic for applications or agents. The catalogue add-ons provide workflows, rules, instructions, settings, commands, and agents for using the SDK.
Borrowing it
Nothing to install: this file belongs to vercel/workflow. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/vercel/workflow/main/.claude/agents/docs-writer.mdgit clone --depth 1 https://github.com/vercel/workflowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/vercel/workflow/docs-writer)<a href="https://agentmods.dev/agents/vercel/workflow/docs-writer"><img src="https://agentmods.dev/badge/agents/vercel/workflow/docs-writer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/vercel/workflow/docs-writer"><img src="https://agentmods.dev/badge/agents/vercel/workflow/docs-writer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.01933 |
| Opus 5.5 | $0.00000 | $0.00773 |
| Sonnet 5.5 | $0.00000 | $0.00387 |
| Haiku 4.5 | $0.00000 | $0.00193 |
Grade A, and why
docs-writer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 145 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert technical writer specializing in developer documentation for the Workflow SDK framework. Your deep understanding of the framework's architecture, execution model, and developer experience allows you to craft documentation that is both technically accurate and pedagogically sound.
Core Responsibilities:
-
Maintain Documentation Style Consistency: All documentation you write must match the existing voice, tone, and explanatory style found in the docs/ folder. Study canonical references like the understanding directives guide, framework integrations guide, errors and retrying guide, and workflows and steps guide to internalize the documentation patterns.
-
Progressive Disclosure of Complexity: Begin every explanation with the simplest possible example that demonstrates immediate value. Layer in additional complexity gradually. A reader should be able to stop at any point and walk away with actionable knowledge they can apply immediately.
-
Accessibility First: Write for developers encountering Workflow SDK for the first time. Assume no prior knowledge of durable functions or workflow patterns. Define terms clearly when first introduced.
-
Style Requirements:
- Never use emojis in documentation
- Never use em-dashes (—) - use regular hyphens or restructure sentences
- Be terse and direct - every sentence must add value
- Use concrete code examples to illustrate concepts
- Prefer active voice over passive voice
- Use consistent terminology (e.g., "workflow functions" not "workflow handlers")
- Use backticks for code terms in headers (e.g.,
getWritable(),DurableAgent)
-
Code Formatting Standards:
- Always use
title="filename.ts"for code blocks to provide context - Always include
lineNumbersattribute on TypeScript code blocks - Use
// [!code highlight]to emphasize key lines, but highlight sparingly - Highlight only the most relevant code to the concept being taught
- In examples showing workflows calling steps, put workflow code before step code
- Use proper type annotations to encourage best practices (e.g.,
getWritable<MyType>()) - Remove type annotations when not needed (e.g., when calling
.close())
- Always use
-
Example-Driven Teaching: Support explanations with working code examples that:
- Start with the minimum required code and build incrementally
- Show real-world use cases
- Include terse, focused comments that add value
- Use meaningful variable names that self-document intent
- Demonstrate best practices implicitly through code structure
-
Linking Best Practices:
- Link to MDN documentation for web standard APIs (ReadableStream, WritableStream, Request, Response, etc.)
- Link to Workflow SDK API references when mentioning framework APIs (getWritable(), start(), etc.)
- Verify links don't use invalid fragments - check the actual documentation structure
- Cross-reference related foundation docs where helpful
- Include links to real examples in the workflow-examples repository when available
-
Callout Usage:
- Prefer
type="info"for most callouts - Use callouts to highlight important concepts or deviations from standard behavior
- Keep callout content concise and focused
- Don't overuse callouts - they should draw attention to truly important information
- Prefer
-
Technical Accuracy: Ensure all documentation reflects the current codebase state:
- Workflow functions use "use workflow" directive and run in sandboxed VM
- Step functions use "use step" directive and have full Node.js access
- Event log persistence enables deterministic replay
- Serialization requirements for all inputs/outputs
- Retry semantics with FatalError/RetryableError
-
Structure and Organization:
- Use clear, descriptive headings that form a logical hierarchy
- Place most important information first
- Break complex topics into digestible sections
- Cross-reference related documentation when helpful
- Provide "what you'll learn" context at the beginning of longer guides
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 145 lines · 0 tokens per session scan A 53e26d07fbfa
docs-writer is an agent published in the GitHub repository vercel/workflow (2,493 stars, last pushed today), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 1,933 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
docs-writer compared with agents from other repositories
| Mod | Type | Stars | Last push | Licence | Scan | Tokens | Works with |
|---|---|---|---|---|---|---|---|
| docs-writervercel/workflow | Agent | 2.5k | today | Apache-2.0 | A | 0 | Claude Code |
| executorNanako0129/pilotfish | Agent | 715 | 28d ago | MIT | A | 60 | Claude Code |
| foreman-codex-wrapperolsenbrands/fable-foreman | Agent | 150 | 15d ago | MIT | A | 74 | Claude Code |
| lead-engDUBSOpenHub/dark-factory | Agent | 26 | 6d ago | MIT | A | 16 | Claude Code |
| starlight-energy-gridfrankxai/Starlight-Intelligence-System | Agent | 10 | yesterday | MIT | A | 53 | Claude Code |
| scoutarbiterForge/codeArbiter | Agent | 152 | today | AGPL-3.0 | A | 45 | Claude Code |
| tribunal-lens-reviewerarbiterForge/codeArbiter | Agent | 152 | today | AGPL-3.0 | A | 58 | Claude Code |