Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/vercel/eve/technical-writingnpx skills add vercel/eve --skill technical-writinggit clone --depth 1 https://github.com/vercel/eveWhat 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 | $0.00078 | $0.01274 |
| Opus 5 | $0.00039 | $0.00637 |
| Sonnet 5 | $0.00016 | $0.00255 |
| Haiku 4.5 | $0.00008 | $0.00127 |
Grade A, and why
technical-writing 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 yesterday.
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 — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Technical writing
Write accurate, task-focused documentation for eve. Treat developers and AI agents as readers: make each section easy to scan, retrieve, and act on without relying on unstated context.
Choose a workflow
- For a new page or full rewrite, read references/writing-workflow.md.
- For targeted or structural changes to existing pages, read references/editing-workflow.md.
- Before finalizing any change, read references/review-framework.md.
- For formatting and terminology, read references/style-rules.md.
- For wording, voice, or AI-pattern concerns, read references/prose-quality.md.
- For page structure, read references/content-types.md when the content type is unclear or changing.
Verify before writing
Do not rely on training data for eve behavior. Use this source hierarchy:
- Current source, public types, and tests in
packages/eve - Current CLI help and setup implementation
- Existing pages under
docs/ - Merged pull requests, changelogs, and release notes
- Research plans under
research/as proposed intent, not shipped behavior - Support evidence such as Slack threads or issues
Use support evidence to identify the reader's problem, not to establish product behavior. Verify commands, flags, API names, defaults, limitations, and examples against the current repository. For a docs-only change, also compare the implementation with the latest public release so the docs do not announce branch-only behavior. When docs accompany product code in the same change, state that dependency during review. If a claim cannot be verified, omit it or report the missing owner or source. Never leave [VERIFY] markers in a completed docs change.
Follow eve conventions
- Write
evelowercase, including headings and sentence starts when practical. - Use exact public names such as
defineAgent,eve dev, andeve add channel/slack. - Distinguish the root agent, the built-in
agenttool, declared subagents, and remote agents. They have different inheritance and execution semantics. - Distinguish eve connections from Vercel Connect, the model-facing
Workflowtool from authored Vercel Workflows, and durable session state from sandbox filesystem or attachment storage. - Name diagnostic surfaces precisely: Vercel runtime logs, Agent Runs, OpenTelemetry,
eve logs, andeve tracesare not interchangeable. - Treat
docs/**as published documentation. Updatedocs/meta.jsonwhen navigation changes. - Keep
.mdfiles framework-agnostic. Use MDX components only in.mdxfiles and only when nearby pages establish the convention. - Preserve published routes and heading anchors when possible. When moving a page, update authored links and add permanent redirects for old HTML and Markdown URLs.
- Prefer TypeScript examples. Include imports and language labels, and verify examples against current exports.
- Show only supported commands and flags. Check CLI help or the command implementation before documenting them.
- Link to related pages with descriptive text. Include the critical fact locally because retrieved sections may be read without their links.
- Leave no page orphaned. Every page needs at least one descriptive inbound body link from a related hub or overview page; a
meta.jsonsidebar entry or a routing-table cell alone is not enough. When adding a page, add the inbound link from the page that owns the topic in the same change, and keep every page reachable by following body links fromgetting-started. - Do not document proposed behavior as shipped. Describe unsupported boundaries directly when they affect a user task.
What ships with it
7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 79 lines · 78 tokens per session scan A 2f09117fc48e
technical-writing is a skill published in the GitHub repository vercel/eve (4,875 stars, last pushed yesterday), licensed Apache-2.0. It adds 78 tokens to every session and 1,274 once invoked, about $0.0004 per session on Opus 5. 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.
Other skills, from other repositories
demo
Skill "demo" from chenxin-yan/crust, covering demo, how to use this skill and command reference.
funnel-builder
Hand-authored skill bundle used by the @crustjs/skills test suite.
maintain-model-list
Maintain the supported LLM model list: add a new model, or run routine maintenance to verify availability and discover new models worth adding. Use when the user asks to add/support a model, update the model list, or check model availability.
update-changelog
Update docs/CHANGELOG.md from git history, GitHub releases, and code diffs. Use when: writing release notes, syncing the latest changelog entry, summarizing a new tag, or keeping changelog wording concise and consistent.
git-cleanup
Clean up local git branches and remotes accumulated from PR reviews. Use when the user asks to clean branches, remove stale remotes, or tidy up the local git state.
submit-pr-from-current-changes
Create a branch, commit existing local changes, push them, and open a pull request. Use when submitting current work as a PR.