write-coding-standards-from-file by github/awesome-copilot
npx skills add https://github.com/github/awesome-copilot --skill write-coding-standards-from-file利用文件现有的语法来建立项目的规范和风格指南。如果传入多个文件或一个文件夹,则遍历每个文件或文件夹中的文件,将文件数据追加到临时内存或文件中,完成后将临时数据作为单个实例使用;就像它是制定规范和风格指南所依据的文件名一样。
下面是一组准配置 boolean 和 string[] 变量。处理 true 或其他值的条件在二级标题 ## 变量与参数配置条件 下。
提示的参数有文本定义。有一个必需参数 ${fileName},以及几个可选参数 ${folderName}、${instructions} 和任何 [configVariableAsParameter]。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
${newFileName} 中的每个文件,如果文件不存在,则使用该文件名并 break,否则继续检查 ${newFileName} 中的下一个文件名。[["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]]。## 编码规范模板 下的两个示例模板之一,或使用更合适的其他组合。如果任何变量名称按原样传递给提示,或作为类似但明显相关的文本值传递,则用传递给提示的值覆盖默认变量值。
${useTemplate} 的默认值。值为 [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]]。${fileName}.length > 1 || ${folderName} != undefined${fixInconsistencies} 切换为 false。${addToREADME} == trueREADME.md 中,而不是输出到提示或创建新文件。${createNewFile} 和 ${outputSpecToPrompt} 都切换为 false。${addToREADMEInsertions} == "atBegin"${addToREADME} 为 true,则将编码规范数据插入到 README.md 文件的开头,标题之后。${addToREADMEInsertions} == "middle"${addToREADME} 为 true,则将编码规范数据插入到 README.md 文件的中间,并更改规范标题以匹配 README.md 的构成。${addToREADMEInsertions} == "beforeEnd"${addToREADME} 为 true,则将编码规范数据插入到 README.md 文件的末尾,在最后一个字符后插入新行,然后在新行上插入数据。${addToREADMEInsertions} == "bestFitUsingContext"${addToREADME} 为 true,则根据 README.md 的构成和数据流的上下文,将编码规范数据插入到 README.md 文件的最合适行。${addStandardsTest} == true${createNewFile} == true${newFileName} 的值或可能值之一创建新文件。${outputSpecToPrompt} 和 ${addToREADME} 都切换为 false。${fetchStyleURL} == true### 获取链接 下嵌套的链接获取的数据作为上下文,用于为新文件、提示或 README.md 创建规范、规格说明和样式数据。### 获取链接 中的每个相关项目,运行 #fetch ${item}。${findInconsistencies} == true' 或 ")等相关的语法,并进行分类。${fixInconsistencies} 的状态,要么编辑并修复低计数类别以匹配大多数,要么将临时内存中存储的不一致输出到提示。${fixInconsistencies} == truetypeof ${newFileName} == "string"string,则使用 ${newFileName} 的值创建一个新文件。typeof ${newFileName} != "string"string,而是 object 或数组,则通过应用此规则使用 ${newFileName} 中的一个值创建新文件:
${newFileName} 中的每个文件名,如果文件不存在,则使用该文件名并 break,否则继续下一个。${outputSpecToPrompt} == true${createNewFile} 和 ${addToREADME} 都切换为 false。${useTemplate} == "v" || ${useTemplate} == "verbose"### "v", "verbose" 下的数据作为指导模板。${useTemplate} == "m" || ${useTemplate} == "minimal"### "m", "minimal" 下的数据作为指导模板。${useTemplate} == "b" || ${useTemplate} == "best"${fileName} 提取的数据,使用三级标题 ### "v", "verbose" 或 ### "m", "minimal" 下的数据,并选择最合适的作为编写编码规范数据时的指导模板。${useTemplate} == "custom" || ${useTemplate} == "<ANY_NAME>"${fetchStyleURL} == true根据编程语言,对于下面列表中的每个链接,如果编程语言是 ${fileName} == [<Language> Style Guide],则运行 #fetch (URL)。
"m", "minimal"## 1. 引言
* **目的:** 简要说明为何要建立编码规范(例如,为了提高代码质量、可维护性和团队协作)。
* **范围:** 定义本规范适用于哪些语言、项目或模块。
## 2. 命名约定
* **变量:** `camelCase`
* **函数/方法:** `PascalCase` 或 `camelCase`。
* **类/结构体:** `PascalCase`。
* **常量:** `UPPER_SNAKE_CASE`。
## 3. 格式与风格
* **缩进:** 每个缩进使用 4 个空格(或制表符)。
* **行长度:** 限制每行最多 80 或 120 个字符。
* **大括号:** 使用 "K&R" 风格(左大括号在同一行)或 "Allman" 风格(左大括号在新行)。
* **空行:** 指定使用多少空行来分隔代码的逻辑块。
## 4. 注释
* **文档字符串/函数注释:** 描述函数的用途、参数和返回值。
* **行内注释:** 解释复杂或不明显的逻辑。
* **文件头:** 指定文件头应包含的信息,例如作者、日期和文件描述。
## 5. 错误处理
* **通用:** 如何处理和记录错误。
* **具体:** 使用哪些异常类型,以及在错误消息中包含哪些信息。
## 6. 最佳实践与反模式
* **通用:** 列出要避免的常见反模式(例如,全局变量、魔法数字)。
* **语言特定:** 基于项目编程语言的具体建议。
## 7. 示例
* 提供一个展示规则正确应用的小代码示例。
* 提供一个错误实现的小代码示例以及如何修复它。
## 8. 贡献与执行
* 解释如何执行这些标准(例如,通过代码审查)。
* 提供对规范文档本身做出贡献的指南。
"v", verbose"
# 风格指南
本文档定义了本项目使用的风格和约定。
所有贡献都应遵循这些规则,除非另有说明。
## 1. 通用代码风格
- 清晰优于简洁。
- 保持函数和方法小而专注。
- 避免重复逻辑;优先使用共享的辅助函数/工具。
- 删除未使用的变量、导入、代码路径和文件。
## 2. 命名约定
使用描述性名称。除非是众所周知的,否则避免缩写。
| 项目 | 约定 | 示例 |
|-----------------|--------------------|--------------------|
| 变量 | `lower_snake_case` | `buffer_size` |
| 函数 | `lower_snake_case()` | `read_file()` |
| 常量 | `UPPER_SNAKE_CASE` | `MAX_RETRIES` |
| 类型/结构体 | `PascalCase` | `FileHeader` |
| 文件名 | `lower_snake_case` | `file_reader.c` |
## 3. 格式化规则
- 缩进:**4 个空格**
- 行长度:**最多 100 个字符**
- 编码:**UTF-8**,无 BOM
- 文件以换行符结尾
### 大括号(以 C 语言为例,请根据您的语言调整)
```c
if (condition) {
do_something();
} else {
do_something_else();
}
if (x),而不是 if(x)推荐标签:
TODO: 后续工作
FIXME: 已知的错误行为
NOTE: 非显而易见的设计决策
简短摘要(最多约 50 个字符)
可选的上下文和原理的较长解释。
风格是不断发展的。 通过提出议题或发送更新本文档的补丁来提议改进。
每周安装量
7.6K
仓库
[github/awesome-copilot](https://github.com/github/awesome-copilot "github/awesome-copilot")
GitHub 星标
26.7K
首次出现
2026年2月25日
安全审计
[Gen Agent Trust HubPass](/github/awesome-copilot/write-coding-standards-from-file/security/agent-trust-hub)[SocketPass](/github/awesome-copilot/write-coding-standards-from-file/security/socket)[SnykWarn](/github/awesome-copilot/write-coding-standards-from-file/security/snyk)
安装于
codex7.5K
gemini-cli7.5K
opencode7.5K
cursor7.5K
github-copilot7.5K
amp7.5K
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, loop through each file or files in the folder, appending the file's data to temporary memory or a file, then when complete use temporary data as a single instance; as if it were the file name to base the standards and style guideline on.
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].
${newFileName}, if file does not exist, use that file name and break, else continue to next file name of ${newFileName}.[["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]].## Coding Standards Templates, or use another composition that is a better fit.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.
${useTemplate} default. Values are [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]].${fileName}.length > 1 || ${folderName} != undefined${fixInconsistencies} to false.${addToREADME} == trueREADME.md instead of outputting to the prompt or creating a new file.${createNewFile} and ${outputSpecToPrompt} to false.${addToREADMEInsertions} == "atBegin"${addToREADME} is true, then insert the coding standards data at the beginning of the README.md file after the title.${addToREADMEInsertions} == "middle"${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"${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"${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${createNewFile} == true${newFileName}.${outputSpecToPrompt} and ${addToREADME} to false.${fetchStyleURL} == true### Fetch Links as context for creating standards, specifications, and styling data for the new file, prompt, or README.md.### Fetch Links, run #fetch ${item}.${findInconsistencies} == true' or " for strings, etc., and categorize.${fixInconsistencies}, either edit and fix the low count categories to match the majority, or output to prompt inconsistencies stored in temporary memory.${fixInconsistencies} == truetypeof ${newFileName} == "string"string, create a new file using the value from ${newFileName}.typeof ${newFileName} != "string"string, but instead an object or an array, create a new file using a value from ${newFileName} by applying this rule:
${newFileName}, if file does not exist, use that file name and break, else continue to the next.${outputSpecToPrompt} == true${createNewFile} and ${addToREADME} to false.${useTemplate} == "v" || ${useTemplate} == "verbose"### "v", "verbose" as guiding template when composing the data for coding standards.${useTemplate} == "m" || ${useTemplate} == "minimal"### "m", "minimal" as guiding template when composing the data for coding standards.${useTemplate} == "b" || ${useTemplate} == "best"### "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} == "<ANY_NAME>"${fetchStyleURL} == trueDepending on the programming language, for each link in list below, run #fetch (URL), if programming language is ${fileName} == [<Language> Style Guide].
"m", "minimal" ```markdown
## 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" ```markdown
# 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.
| Item | Convention | Example |
|-----------------|----------------------|--------------------|
| Variables | `lower_snake_case` | `buffer_size` |
| Functions | `lower_snake_case()` | `read_file()` |
| Constants | `UPPER_SNAKE_CASE` | `MAX_RETRIES` |
| Types/Structs | `PascalCase` | `FileHeader` |
| File Names | `lower_snake_case` | `file_reader.c` |
## 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)
```c
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:
```text
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.
```
Weekly Installs
7.6K
Repository
GitHub Stars
26.7K
First Seen
Feb 25, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
codex7.5K
gemini-cli7.5K
opencode7.5K
cursor7.5K
github-copilot7.5K
amp7.5K
97,600 周安装