eve: Skill for Codex

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:

1. Current source, public types, and tests in packages/eve
2. Current CLI help and setup implementation
3. Existing pages under docs/
4. Merged pull requests, changelogs, and release notes
5. Research plans under research/ as proposed intent, not shipped behavior
6. 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 eve lowercase, including headings and sentence starts when practical.
• Use exact public names such as defineAgent, eve dev, and eve add channel/slack.
• Distinguish the root agent, the built-in agent tool, declared subagents, and remote agents. They have different inheritance and execution semantics.
• Distinguish eve connections from Vercel Connect, the model-facing Workflow tool 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, and eve traces are not interchangeable.
• Treat docs/** as published documentation. Update docs/meta.json when navigation changes.
• Keep .md files framework-agnostic. Use MDX components only in .mdx files 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.json sidebar 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 from getting-started.
• Do not document proposed behavior as shipped. Describe unsupported boundaries directly when they affect a user task.