Write Coding Standards From File
Derive a project coding standards or style guide document from real files already in the repo instead of generic templates.
Overview
Write Coding Standards From File is an agent skill for the Build phase that infers and writes project coding standards from existing repository files you specify.
Install
npx skills add https://github.com/github/awesome-copilot --skill write-coding-standards-from-fileWhat is this skill?
- Required `${fileName}` input; optional `${folderName}` and `${instructions}` to scope analysis
- Loops multiple files or folders into one consolidated style inference pass
- Configurable output targets: CONTRIBUTING.md, STYLE.md, CODE_OF_CONDUCT.md, CODING_STANDARDS.md, and related names
- Optional README insertion modes: atBegin, middle, beforeEnd (default), bestFitUsingContext
- Optional inconsistency discovery and fix passes plus standards test generation flags
- README insertion modes: atBegin, middle, beforeEnd, bestFitUsingContext (default beforeEnd)
- Suggested output filenames include CONTRIBUTING.md, STYLE.md, CODE_OF_CONDUCT.md, and CODING_STANDARDS.md
Adoption & trust: 9.1k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your repo already has implicit style in working code, but you lack a written standards doc new contributors and agents can follow consistently.
Who is it for?
Solo builders formalizing style right after the first meaningful modules land and before opening the repo to collaborators or heavy agent refactors.
Skip if: Greenfield projects with no representative source files yet, or teams that only need a stock linter config with zero editorial guidance.
When should I use this skill?
You need a coding standards document for a project using the coding styles from file(s) and/or folder(s) passed in the prompt.
What do I get? / Deliverables
You get a standards or style markdown artifact (and optional README section) derived from your actual files, with optional inconsistency notes or fixes applied first.
- Coding standards or style markdown file (e.g., CODING_STANDARDS.md or configured name)
- Optional README section with summarized standards
- Optional inconsistency report or applied fixes when those flags are enabled
Recommended Skills
Journey fit
Standards documents are typically authored while the codebase is taking shape in Build, before review gates and contributor onboarding harden. Docs subphase is the canonical home for CONTRIBUTING, STYLE, and CODING_STANDARDS artifacts inferred from live project syntax.
How it compares
Use this generator to capture observed project idioms instead of pasting a generic Google style guide unrelated to your codebase.
Common Questions / FAQ
Who is write-coding-standards-from-file for?
It is for maintainers and solo builders who want coding standards grounded in files that already exist in their repository, including multi-file or folder-wide sampling.
When should I use write-coding-standards-from-file?
Use it during Build while documenting conventions—typically before broad contributor onboarding or before Ship-phase review checklists reference a formal style guide.
Is write-coding-standards-from-file safe to install?
See the Security Audits panel on this Prism page; optional fix passes may edit repository files, so review diffs and disable auto-fix when you only want a draft document.
SKILL.md
READMESKILL.md - Write Coding Standards From File
# 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. ## 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; * fetchStyleURL = true; * findInconsistencies = true; * fixInconsistencies = true; * 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; * 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 the 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"]]`. #### 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. ### `${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 **beginn