安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install write-coding-standards-from-file
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 write-coding-standards-from-file。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

Write Coding Standards From File 会分析明确指定的源文件或范围严格限定的文件夹，以识别项目实际采用的约定，包括缩进、命名、注释、格式和代码结构。它会根据这些观察结果生成量身定制的规范文档，而不是强加通用风格指南。
此技能专为安全、可执行的文档编写而设计，默认排除敏感路径和生成内容，汇总不一致之处，并在使用后删除临时分析文件。作为面向开发者工作流的 Openclaw Skills 之一，它可以根据配置创建新的规范文件、将规范添加到 README，或在提示中返回规范。

应用场景

使用具有代表性的源文件，为新项目或缺少文档的项目制定编码规范文档。
分析范围严格限定的文件夹，整合多个文件中的约定。
识别并汇总缩进、引号、注释、换行和代码结构方面的差异。
在 README 或专门的规范文件中创建或更新项目贡献指南。
为代码审查、新成员入职或可选规范测试准备基准。
使用 Openclaw Skills 在提出更改前记录现有约定。

工作原理

提供必需的 fileName 参数，或选择性指定范围严格限定的 folderName、其他 instructions 和配置覆盖项。
仅检查所请求的输入。分析文件夹时，默认排除配置中指定的敏感、私有、生成、依赖及无关路径。
观察并汇总缩进、命名、注释、条件和函数过程、引号及换行等风格模式。
启用此选项后，将相关发现与关联的语言专属风格指南进行比较，并找出偏离多数模式的情况。
使用所选模板编写规范：详细、精简、最佳匹配或自定义指令。
根据配置，将规范写入新文件、README 或提示中。如有要求，报告不一致之处或创建规范测试。
对多个输入，默认保持只读。修改源文件需要对指定文件取得明确授权并审查拟议的差异；使用后删除临时分析文件。

配置指南

在提示中向此技能提供必需的源文件名。也可以传入范围严格限定的文件夹、指令或配置值，例如 useTemplate、addToREADME 和 addStandardsTest。

SKILL.md 未指定安装命令或 CLI。

在提示中提供文件路径，通过兼容的 AI 编码代理调用此技能。

默认情况下，此技能会创建新的规范文件，并从配置的名称列表中选择第一个可用名称（从 CONTRIBUTING.md、STYLE.md 和 CODE_OF_CONDUCT.md 开始）。将 addToREADME 设为启用，可将规范插入 README.md；或设置 outputSpecToPrompt，在提示中返回规范。使用 useTemplate 选择模板；默认值为 verbose。如需修改源文件，请明确授权指定目标，并在接受更改前审查差异。

数据架构

此技能通过提示参数和配置变量组织输入与输出；SKILL.md 未定义持久数据库或单独的结构化数据格式。
元素 用途
fileName 必需的待分析源文件。
folderName 可选的范围严格限定文件夹，用于汇总分析相关文件。
instructions 可选的项目专属要求或流程。
配置变量 控制输出位置、模板、外部风格指南上下文、不一致项处理、测试及临时文件行为。
规范输出 根据配置生成新的 Markdown 文档、README 章节或提示回复。
不一致项发现 临时工作记忆中保存的简短分类摘要；默认不用于重写源文件。
默认候选文件名按以下顺序检查，直到找到未使用的名称：CONTRIBUTING.md、STYLE.md、CODE_OF_CONDUCT.md、CODING_STANDARDS.md、DEVELOPING.md、CONTRIBUTION_GUIDE.md、GUIDELINES.md、PROJECT_STANDARDS.md、BEST_PRACTICES.md 和 HACKING.md。
默认排除的路径 glob 包括 .git/、node_modules/、dist/、build/、coverage/、.env*、密钥和证书文件、secrets/ 及 private/**。除非明确要求，否则不会保留临时分析文件。

高级特性

可配置输出目的地：创建规范文件；在
README.md
开头、中间、结尾之前或最合适的位置插入内容；或直接输出到提示中。
模板选择支持详细、精简、最佳匹配和自定义指导。
可选的语言专属上下文可从技能中包含的风格指南链接获取。
不一致项检测会对风格差异分类并记录数量，以识别偏离多数模式的情况。
可选的规范测试生成可在规范文档完成后生成测试文件。
安全编辑控制默认只报告不一致之处，而不更改源文件；编辑前必须明确授权并审查差异。
多文件分析会自动优先采用只读行为，并默认禁用不一致项修复。
限定范围的文件选择和可配置的排除 glob，有助于避开机密、私有数据、依赖项、缓存、二进制文件和生成内容。

name: write-coding-standards-from-file description: 'Write a coding standards document for a project using the coding styles from the file(s) and/or folder(s) passed as arguments in the prompt, without modifying analyzed source files unless edits are explicitly requested and confirmed.'

Write Coding Standards From File

Use the existing syntax of the file(s) to establish the standards and style guides for the project. If more than one file or a folder is passed, analyze only the explicitly provided file paths or a narrowly scoped folder. Exclude secrets, private data, environment files, generated output, dependency folders, and unrelated directories by default. Aggregate style observations in temporary working memory instead of copying full source into persistent storage; if a temporary file is required for analysis, remove it immediately after the standards are generated.

Rules and Configuration

Below is a set of quasi-configuration boolean and string[] variables. Conditions for handling true, or other values for each variable are under the level two heading ## Variable and Parameter Configuration Conditions.

Parameters for the prompt have a text definition. There is one required parameter ${fileName}, and several optional parameters ${folderName}, ${instructions}, and any [configVariableAsParameter].

Configuration Variables

addStandardsTest = false;
addToREADME = false;
addToREADMEInsertions = ["atBegin", "middle", "beforeEnd", "bestFitUsingContext"];
Default to beforeEnd.
createNewFile = true;
excludedPathGlobs = [".git/", "node_modules/", "dist/", "build/", "coverage/", ".env*", ".key", ".pem", ".pfx", ".crt", "secrets/", "private/**"];
Exclude these by default when ${folderName} is used unless the collaborator explicitly narrows the request to one of them.
fetchStyleURL = true;
findInconsistencies = true;
fixInconsistencies = false;
newFileName = ["CONTRIBUTING.md", "STYLE.md", "CODE_OF_CONDUCT.md", "CODING_STANDARDS.md", "DEVELOPING.md", "CONTRIBUTION_GUIDE.md", "GUIDELINES.md", "PROJECT_STANDARDS.md", "BEST_PRACTICES.md", "HACKING.md"];
For each file in ${newFileName}, if file does not exist, use that file name and break, else continue to next file name of ${newFileName}.
outputSpecToPrompt = false;
persistTemporaryFiles = false;
Temporary analysis files must be deleted after use unless the collaborator explicitly asks to keep them.
requireEditConfirmation = true;
Source file edits require explicit collaborator approval for the named files and a reviewed diff before acceptance.
useTemplate = "verbose"; // or "v"
Possible values are [["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]].
Selects one of the two example templates at the bottom of prompt file under the level two heading ## Coding Standards Templates, or use another composition that is a better fit.

If custom, then apply per request.

Configuration Variables as Prompt Parameters

If any of the variable names are passed to prompt as-is, or as a similar but clearly related text value, then override the default variable value with the value passed to prompt.

Prompt Parameters

fileName = The name of the file that will be analyzed in terms of: indentation, variable naming, commenting, conditional procedures, functional procedures, and other syntax related data for the coding language of the file.
folderName = The name of a narrowly scoped folder that will be used to extract data from multiple files into one aggregated dataset that will be analyzed in terms of: indentation, variable naming, commenting, conditional procedures, functional procedures, and other syntax related data for the coding language of the files.
instructions = Additional instructions, rules, and procedures that will be provided for unique cases.
[configVariableAsParameter] = If passed will override the default state of the configuration variable. Example:
useTemplate = If passed will override the configuration ${useTemplate} default. Values are [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]].
fixInconsistencies = If passed as true, only edit explicitly approved target files after reviewing the diff.

Required and Optional Parameters

fileName - required
folderName - optional
instructions - optional
[configVariableAsParameter] - optional

Variable and Parameter Configuration Conditions

${fileName}.length > 1 || ${folderName} != undefined

If true, toggle ${fixInconsistencies} to false.

Prefer read-only analysis across multiple inputs and summarize inconsistencies instead of rewriting source files.
${folderName} != undefined
Limit analysis to explicitly relevant files in the requested folder and exclude ${excludedPathGlobs} by default.
Do not scan secrets, generated output, dependency directories, caches, binaries, or unrelated/private folders unless the collaborator explicitly names them.
${addToREADME} == true
Insert the coding standards into the README.md instead of outputting to the prompt or creating a new file.

If true, toggle both ${createNewFile} and ${outputSpecToPrompt} to false.

${addToREADMEInsertions} == "atBegin"

If ${addToREADME} is true, then insert the coding standards data at the beginning of the README.md file after the title.

${addToREADMEInsertions} == "middle"

If ${addToREADME} is true, then insert the coding standards data at the middle of the README.md file, changing the standards title heading to match that of the README.md composition.

${addToREADMEInsertions} == "beforeEnd"

If ${addToREADME} is true, then insert the coding standards data at the end of the README.md file, inserting a new line after the last character, then inserting the data on a new line.

${addToREADMEInsertions} == "bestFitUsingContext"

If ${addToREADME} is true, then insert the coding standards data at the best fitting line of the README.md file in regards to the context of the README.md composition and flow of data.

${addStandardsTest} == true
Once the coding standards file is complete, write a test file to ensure the file or files passed to it adhere to the coding standards.
${createNewFile} == true
Create a new file using the value, or one of the possible values, from ${newFileName}.

If true, toggle both ${outputSpecToPrompt} and ${addToREADME} to false.

${fetchStyleURL} == true
Additionally use the data fetched from the links nested under level three heading ### Fetch Links as context for creating standards, specifications, and styling data for the new file, prompt, or README.md.
For each relevant item in ### Fetch Links, run #fetch ${item}.
${findInconsistencies} == true
Evaluate syntax related to indentations, line-breaks, comments, conditional and function nesting, quotation wrappers i.e. ' or " for strings, etc., and categorize.
For each category, make a count, and if one item does not match the majority of the count, then record a brief inconsistency summary in temporary working memory.
Depending on the status of ${fixInconsistencies}, either output the inconsistencies stored in temporary working memory or prepare a reviewed diff for explicitly approved target files.
${fixInconsistencies} == true
Only edit analyzed source files when the collaborator explicitly requests edits or confirms that edits are allowed for the named target files.
Respect ${requireEditConfirmation} and present or review the generated diff before the collaborator accepts the change.

If explicit approval is missing, toggle ${fixInconsistencies} back to false and report the inconsistencies without modifying files.

${requireEditConfirmation} == true
Before editing any analyzed source file, confirm the exact target files and review the diff with the collaborator.
${persistTemporaryFiles} == false
Keep temporary analysis data only as long as needed to generate the standards output, then remove any temporary files created during the process.
typeof ${newFileName} == "string"

If specifically defined as a string, create a new file using the value from ${newFileName}.

typeof ${newFileName} != "string"

If NOT specifically defined as a string, but instead an object or an array, create a new file using a value from ${newFileName} by applying this rule:

For each file name in ${newFileName}, if file does not exist, use that file name and break, else continue to the next.
${outputSpecToPrompt} == true
Output the coding standards to the prompt instead of creating a file or adding to README.

If true, toggle both ${createNewFile} and ${addToREADME} to false.

${useTemplate} == "v" || ${useTemplate} == "verbose"
Use data under the level three heading ### "v", "verbose" as guiding template when composing the data for coding standards.
${useTemplate} == "m" || ${useTemplate} == "minimal"
Use data under the level three heading ### "m", "minimal" as guiding template when composing the data for coding standards.
${useTemplate} == "b" || ${useTemplate} == "best"
Use either the data under the level three heading ### "v", "verbose" or ### "m", "minimal", depending on the data extracted from ${fileName}, and use the best fit as guiding template when composing the data for coding standards.
${useTemplate} == "custom" || ${useTemplate} == ""
Use the custom prompt, instructions, template, or other data passed as guiding template when composing the data for coding standards.

if ${fetchStyleURL} == true

Depending on the programming language, for each link in list below, run #fetch (URL), if programming language is ${fileName} == [ Style Guide].

Fetch Links

C Style Guide

C# Style Guide
C++ Style Guide

Go Style Guide

Java Style Guide

AngularJS App Style Guide

jQuery Style Guide

JavaScript Style Guide

JSON Style Guide

Kotlin Style Guide

Markdown Style Guide

Perl Style Guide

PHP Style Guide

Python Style Guide

Ruby Style Guide

Rust Style Guide

Swift Style Guide

TypeScript Style Guide

Visual Basic Style Guide

Shell Script Style Guide

Git Usage Style Guide

PowerShell Style Guide

CSS

Sass Style Guide

HTML Style Guide

Linux kernel Style Guide

Node.js Style Guide

SQL Style Guide

Angular Style Guide

Vue Style Guide

Django Style Guide

SystemVerilog Style Guide

Coding Standards Templates

"m", "minimal"

## 1. Introduction
* **Purpose:** Briefly explain why the coding standards are being established (e.g., to improve code quality, maintainability, and team collaboration).
* **Scope:** Define which languages, projects, or modules this specification applies to.

## 2. Naming Conventions
* **Variables:** `camelCase`
* **Functions/Methods:** `PascalCase` or `camelCase`.
* **Classes/Structs:** `PascalCase`.
* **Constants:** `UPPER_SNAKE_CASE`.

## 3. Formatting and Style
* **Indentation:** Use 4 spaces per indent (or tabs).
* **Line Length:** Limit lines to a maximum of 80 or 120 characters.
* **Braces:** Use the "K&R" style (opening brace on the same line) or the "Allman" style (opening brace on a new line).
* **Blank Lines:** Specify how many blank lines to use for separating logical blocks of code.

## 4. Commenting
* **Docstrings/Function Comments:** Describe the function's purpose, parameters, and return values.
* **Inline Comments:** Explain complex or non-obvious logic.
* **File Headers:** Specify what information should be included in a file header, such as author, date, and file description.

## 5. Error Handling
* **General:** How to handle and log errors.
* **Specifics:** Which exception types to use, and what information to include in error messages.

## 6. Best Practices and Anti-Patterns
* **General:** List common anti-patterns to avoid (e.g., global variables, magic numbers).
* **Language-specific:** Specific recommendations based on the project's programming language.

## 7. Examples
* Provide a small code example demonstrating the correct application of the rules.
* Provide a small code example of an incorrect implementation and how to fix it.

## 8. Contribution and Enforcement
* Explain how the standards are to be enforced (e.g., via code reviews).
* Provide a guide for contributing to the standards document itself.

"v", verbose"

```bash
# Style Guide

This document defines the style and conventions used in this project. All contributions should follow these rules unless otherwise noted.

1. General Code Style

• Favor clarity over brevity.
• Keep functions and methods small and focused.
• Avoid repeating logic; prefer shared helpers/utilities.
• Remove unused variables, imports, code paths, and files.

2. Naming Conventions

Use descriptive names. Avoid abbreviations unless well-known.

3. Formatting Rules

• Indentation: 4 spaces
• Line length: max 100 characters
• Encoding: UTF-8, no BOM
• End files with a newline

Braces (example in C, adjust for your language)

```bash
if (condition) {

do_something();
} else {
do_something_else();
}

### Spacing

- One space after keywords: `if (x)`, not `if(x)`
- One blank line between top-level functions

## 4. Comments & Documentation

- Explain *why*, not *what*, unless intent is unclear.
- Keep comments up-to-date as code changes.
- Public functions should include a short description of purpose and parameters.

Recommended tags:

```text
TODO: follow-up work  
FIXME: known incorrect behavior  
NOTE: non-obvious design decision

5. Error Handling

• Handle error conditions explicitly.
• Avoid silent failures; either return errors or log them appropriately.
• Clean up resources (files, memory, handles) before returning on failure.

6. Commit & Review Practices

Commits

• One logical change per commit.
• Write clear commit messages:

Short summary (max ~50 chars)  
Optional longer explanation of context and rationale.

Reviews

• Keep pull requests reasonably small.
• Be respectful and constructive in review discussions.
• Address requested changes or explain if you disagree.

7. Tests

• Write tests for new functionality.
• Tests should be deterministic (no randomness without seeding).
• Prefer readable test cases over complex test abstraction.

8. Changes to This Guide

Style evolves. Propose improvements by opening an issue or sending a patch updating this document.

Bestax 表单构建  
复古电路模型图