# Technical Writing

Write, edit, review, or audit user-facing documentation for the eve repository.

- Repository: https://github.com/vercel/eve (5761 stars)
- Category: Testing
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add vercel/eve --skill technical-writing -g -a claude-code -y`
Codex: `npx skills add vercel/eve --skill technical-writing -g -a codex -y`
Cursor: `npx skills add vercel/eve --skill technical-writing -g -a cursor -y`
Gemini CLI: `npx skills add vercel/eve --skill technical-writing -g -a gemini-cli -y`

## Description

Write, edit, review, or audit user-facing documentation for the eve repository. Use for changes under docs/, documentation tied to eve APIs or CLI behavior, docs work based on Slack or support feedback, and requests to make eve docs clearer, more natural, or less AI-patterned while verifying claims against current source, tests, CLI help, public releases, and repository conventions.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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](references/writing-workflow.md).
- For targeted or structural changes to existing pages, read [references/editing-workflow.md](references/editing-workflow.md).
- Before finalizing any change, read [references/review-framework.md](references/review-framework.md).
- For formatting and terminology, read [references/style-rules.md](references/style-rules.md).
- For wording, voice, or AI-pattern concerns, read [references/prose-quality.md](references/prose-quality.md).
- For page structure, read [references/content-types.md](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

The rest: https://github.com/vercel/eve/blob/HEAD/.agents/skills/technical-writing/SKILL.md