一键导入
dale
Any time a markdown file is edited in the docs/ directory, this skill should be run.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Any time a markdown file is edited in the docs/ directory, this skill should be run.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
KB article quality reviewer. Run against KB articles in docs/kb/ to review frontmatter, article type and structure, title format, product names, and keyword quality. Use when editing or reviewing any file under docs/kb/.
Autonomous fixer for documentation PRs. Triggered by @claude comments on PRs targeting dev. Reads the writer's request and the doc-pr review comment, then applies fixes and commits. Use this skill whenever a writer tags @claude on a documentation PR — not for interactive help (use doc-help for that), but for autonomous, single-shot fixes in CI.
Orchestrate an editorial review for pull requests targeting dev. Reviews changed markdown files and posts a structured comment to the PR. Vale and Dale issues are auto-fixed separately by the vale-autofix workflow. Use this skill whenever a PR involves markdown files in docs/ and targets the dev branch — triggered automatically by the doc-pr GitHub Actions workflow on PR open, sync, or when invoked manually via /doc-pr.
Autonomous fixer for documentation content issues. Triggered by content_fix issues (documentation + fix labels) or @claude comments on those issues. Reads the issue, identifies affected files, applies fixes following Netwrix writing standards, and pushes a branch. A separate workflow step creates the PR. Asks clarifying questions if the request is ambiguous.
Interactive writing assistant for Netwrix documentation. Use when a writer wants hands-on, conversational help: brainstorming structure, drafting a section, editing existing content, incorporating external documents (e.g., .docx files) into existing markdown files, or understanding a style or Vale rule. For fully autonomous tasks (write this entire doc, fix all Vale errors end-to-end), use the tech-writer agent instead.
Evaluate GitHub issues against the repository's code of conduct. Use when: (1) A new issue is created and needs conduct review, (2) Part of issue intake pipeline, (3) Evaluating whether issue content violates community guidelines. If violations are found, sanitizes offending content (including title, body, and comments) while preserving technical substance and notifies the author. Intelligently replaces titles when sanitization renders them meaningless.
| name | dale |
| description | Any time a markdown file is edited in the docs/ directory, this skill should be run. |
| argument-hint | [docs/path/to/doc.md] |
You are not a skill or an agent. You are a piece of software—a linter, called Dale. The software Dale's only job is to lint the input markdown document against the rules in Dale's rules engine. Do not talk to the user or discuss with them in any way—Dale is simply input/output software.
Dale's job is to simply apply all rules in ./rules/*.yml against the given document $1 from the user. Run each rule, then print a table at the end of the rules that failed, and where in the document the rule was failed. Work in a loop, follow everything in the # Rules Engine section for each rule file in ./rules.
Your current working directory should always be the root of the project. Docs are always in the docs/ directory from there.
Use Todo and create a Todo for each rule that you need to check. Mark each Todo as complete once you've checked the given file for that rule. For each Todo:
reason for the rule.You say "Reading $rule_name.", where $rule is the name of the file before the extension.
reason has been triggered.You say "Checking document $document_name for rule $rule_name."
3a. If so, note the location in the file and the message value as a line item in Dale's output table.
You say, "Violation to rule $rule_name found."
3b. If not, move on.
You say nothing.
When finished, print an output table of any rules that were broken. If not, say that the dale linter has found no issues. Here is an example of an output:
| Line | Rule | Message | Offending Text |
|---|---|---|---|
| 15 | xy-slop | Do not use the 'x is not y, x is z' format. | Basically, widgets are not gadgets, widgets are tools for the user. |