Labsco
github logo

write-coding-standards-from-file

✓ Official36,200

by github · part of github/awesome-copilot

Analyze existing code files to automatically generate a project coding standards document. Extracts syntax patterns (indentation, naming conventions, commenting style, braces, line length) from one or more files or entire folders to establish baseline standards Detects and optionally fixes inconsistencies across files, flagging deviations from the majority pattern in each category Outputs standards to a new file (CONTRIBUTING.md, STYLE.md, CODING_STANDARDS.md, etc.), README.md insertion, or...

🔥🔥🔥✓ VerifiedFreeQuick setup
🧩 One of 7 skills in the github/awesome-copilot package — works on its own, and pairs well with its siblings.

Analyze existing code files to automatically generate a project coding standards document. Extracts syntax patterns (indentation, naming conventions, commenting style, braces, line length) from one or more files or entire folders to establish baseline standards Detects and optionally fixes inconsistencies across files, flagging deviations from the majority pattern in each category Outputs standards to a new file (CONTRIBUTING.md, STYLE.md, CODING_STANDARDS.md, etc.), README.md insertion, or...

Inspect the full instructions your agent will receiveExpand

This is the exact playbook injected into your agent when the skill activates — shown here so you can audit it before installing. You don't need to read it to use the skill.

by github

Analyze existing code files to automatically generate a project coding standards document. Extracts syntax patterns (indentation, naming conventions, commenting style, braces, line length) from one or more files or entire folders to establish baseline standards Detects and optionally fixes inconsistencies across files, flagging deviations from the majority pattern in each category Outputs standards to a new file (CONTRIBUTING.md, STYLE.md, CODING_STANDARDS.md, etc.), README.md insertion, or... npx skills add https://github.com/github/awesome-copilot --skill write-coding-standards-from-file Download ZIPGitHub36.2k

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, 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.

if ${fetchStyleURL} == true

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

Fetch Links

Coding Standards Templates

"m", "minimal"

Copy & paste — that's it
 ```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.
Copy & paste — that's it

### `"v", verbose"`
Copy & paste — that's it

# 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:

Copy & paste — that's it
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:
Copy & paste — that's it
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.

Copy & paste — that's it