菜单
Enforce the project's documentation voice when writing or reviewing public-facing content. Triggers on edits to doc files (packages/web/src/content/docs/**/*.md) and README.md. Catches LLM prose patterns, marketing language, and messaging drift.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create and manage Architecture Decision Records (ADRs). Use when making architectural changes (refactoring, API versioning, new domain layers, schema changes), when reviewing recent commits for documentation needs, or when the user mentions ADR, architecture decisions, or documenting technical decisions.
Detect documentation and architecture-model drift by comparing source-of-truth code (CLI commands, flags, env vars, GH Action inputs/outputs, package structure, pipeline stages, providers, adapters, platforms) against web docs, README, and LikeC4 architecture model (.c4 files). Use when files that define the user-facing interface or internal structure change, when the user asks to check docs, or when mentioning doc drift, architecture drift, stale docs, or documentation sync.
Generate product pitch videos for the Erode project from screenshots. Use this skill whenever the user wants to create, update, or regenerate the product demo video, landing page animation, or pitch clip for erode.dev or the GitHub repo. Also trigger when the user mentions "product video", "demo video", "pitch video", "update the video", "regenerate video", or "landing page animation" in the context of Erode.
Conventional commits with project conventions. Use when the user asks to commit, make a commit, or wants to follow the project's git commit standard.
Sync the local LikeC4 syntax guide with the upstream LikeC4 skills repository (github.com/likec4/likec4/tree/main/skills/likec4-dsl). Use when the user asks to update, sync, or check the LikeC4 syntax guide, when upstream LikeC4 DSL changes are suspected, or when mentioning likec4 syntax sync, DSL drift, or syntax guide update.
Interact with Linear.app for issue tracking. Use when working with Linear tickets (format ABC-123), creating issues, updating status, or downloading attachments. Triggers on ticket references, issue management, or when user mentions Linear.
| name | docs-voice |
| description | Enforce the project's documentation voice when writing or reviewing public-facing content. Triggers on edits to doc files (packages/web/src/content/docs/**/*.md) and README.md. Catches LLM prose patterns, marketing language, and messaging drift. |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep |
Keep Erode's public-facing docs in a consistent, honest voice. Every doc should
read like it was written by the same person who wrote why-it-matters.md.
Before writing or reviewing any doc, read the voice calibration source:
packages/web/src/content/docs/docs/why-it-matters.md
That page sets the tone, the messaging, and the level of honesty. Match it.
Trigger proactively when any of these files are created or edited (staged, unstaged, or in recent commits):
packages/web/src/content/docs/**/*.mdREADME.mdWhen detected, say:
Doc files changed. Want me to run docs-voice to check the writing?
These are the project's core claims. New docs should reinforce them, not contradict or dilute them.
The core story. Architecture models rot because updating them is disconnected from coding. AI makes this worse by shipping structural changes faster than humans can review. Erode closes the loop by checking PRs automatically.
Visibility, not enforcement. Erode exists to make drift visible. It does not enforce rules or block merges.
Violations are not necessarily problems. Software evolves. New dependencies are natural. What matters is that changes are conscious and documented, not accidental.
Thin models win. The model should be nodes and connections at the system level. A thin model that stays true beats a detailed one nobody trusts.
Connect features to the core problem. When describing what Erode does, tie it back to the problem (drift goes unnoticed) and the solution (make it visible during code review).
Two to three sentences. One idea per paragraph. If a paragraph needs a fourth sentence, split it.
The subject does the action. "Erode checks every PR" not "Every PR is checked by Erode."
Name the thing. "Erode flags undeclared dependencies in PRs" not "The tool provides architectural governance capabilities."
State the pain before the fix. The reader needs to feel the problem before they care about the answer.
Say what it does. "Erode catches drift" not "Erode can help you potentially identify possible drift scenarios."
If something does not work yet, say so plainly. Do not hide limitations behind vague language or skip them entirely.
Banned words and phrases:
If you catch yourself reaching for these words, describe what the thing actually does instead.
Use > for short, quotable statements that express a core belief or insight.
Not for emphasis, not for callouts, not for tips. Starlight callouts
(:::note, :::tip) handle those.
Each pattern below includes examples. Flag every occurrence.
Banned entirely. Use commas, periods, semicolons, or parentheses.
Erode checks PRs — flagging undeclared dependencies — before merge.Erode checks PRs, flagging undeclared dependencies, before merge.This completely eliminates architecture drift forever.This catches drift when it's introduced.Remove without replacement. The sentence is stronger without them.
It's worth noting that Erode checks every PR.Erode checks every PR.As a matter of fact, the model stays current.The model stays current.Other fillers to catch: "It should be noted that", "Needless to say", "At the end of the day", "In order to" (use "to"), "Due to the fact that" (use "because"), "At this point in time" (use "now").
Erode essentially analyzes your PRs to actually find drift.Erode analyzes your PRs to find drift.Words to catch: "actually", "essentially", "basically", "really", "very", "quite", "rather", "somewhat", "just" (when used as filler).
No exclamation marks in body text. Reserve them for nothing.
Erode catches drift automatically!Erode catches drift automatically.Let's set up your first analysis.Set up your first analysis.PRs are analyzed by the tool for architectural violations.The tool analyzes PRs for architectural violations.Not all passive voice is wrong. Use judgment. "The model is defined in a
.c4 file" is fine because the model is the subject.
Many teams find that architecture drift causes problems.Architecture drift causes problems.Words to catch: "many", "most", "some", "often", "generally", "typically" when used to avoid making a direct statement.
No emoji in docs. Not in headings, not in body text, not in lists.
## Getting Started 🚀## Getting startedEvery doc page needs YAML front matter with title and description:
---
title: Page Title Here
description: One-sentence summary of what this page covers.
---
## (Starlight uses title from front matter as h1)Use tables for structured reference data (env vars, flags, options). Do not use tables for prose or explanations.
Always include a language label:
```bash
npm run build
```
Use Starlight callout syntax for tips, notes, and warnings:
:::tip
Short, actionable tip here.
:::
:::note
Context or background the reader might need.
:::
:::caution
Something that could go wrong if ignored.
:::
Do not use blockquotes (>) for this purpose.
Use relative paths, not absolute URLs:
[configuration](../guides/configuration.md)[configuration](https://erode.dev/docs/guides/configuration)Guides should end with a short section pointing to the next logical step:
## What's next
- [Configure environment variables](../guides/configuration.md)
- [Set up CI integration](../ci/github-actions.md)
why-it-matters.md and absorb the tone.Run this after every draft. Every item is a yes/no check.
title and description## and use sentence case