Skill: style-guide
What I do
I help you maintain a consistent and readable codebase by enforcing coding standards and documentation conventions. I focus on making the code easy for any team member to understand and modify. I ensure that your style guide is a living document that improves the quality of every commit.
When to use me
- When you're setting up a new project and defining its coding standards.
- When you're configuring linters or formatting tools.
- When you're reviewing code for naming and formatting consistency.
- When you're writing documentation or comments.
Core principles
- Automate enforcement, use tools like linters and formatters to catch style issues automatically.
- Naming clarity, choose descriptive names for variables, functions, and files that reveal their purpose.
- Consistent formatting, ensure that all code looks like it was written by a single person.
- Purposeful comments, write comments that explain the "why" rather than the "what".
Patterns & examples
Linter configuration
Use industry-standard tools for automated checks.
- Go, Use
golangci-lint with a comprehensive .golangci.yml configuration.
- JavaScript, Use
ESLint with a shared config like Airbnb or Standard.
Naming conventions
Follow language-specific idioms.
- Go, Use camelCase for internal symbols and PascalCase for exported symbols. Keep names concise.
- JavaScript, Use camelCase for variables and functions, PascalCase for classes and components.
Comment style
Use standard formats for automated documentation.
- Go, Use
godoc style comments for exported functions.
- JavaScript, Use
JSDoc for providing type and purpose information in untyped files.
Import ordering
Organise imports to reduce noise.
- Pattern, Group standard library imports, then third-party libraries, then internal modules. Separate groups with a blank line.
Anti-patterns to avoid
- ❌ Style disagreements over logic, spending too much time arguing about trivial style details instead of meaningful code improvements.
- ❌ Inconsistent names, using multiple naming patterns for the same concept across the project.
- ❌ Useless comments, comments that just restate what the code is doing without providing context.
- ❌ Ignoring linter warnings, allowing linter errors to accumulate until they are ignored by everyone.
KB Reference
~/vaults/baphled/3. Resources/Knowledge Base/AI Development System/Skills/Code-Quality/Style Guide.md
Related skills
clean-code, for broader coding best practices.
static-analysis, for automated quality checks.
documentation-writing, for better comments and guides.
writing-style, for a consistent tone in docs.
1---2name: style-guide-53description: Style guide enforcement and documentation conventions4---5
6# Skill: style-guide
7
8## What I do
9
10I help you maintain a consistent and readable codebase by enforcing coding standards and documentation conventions. I focus on making the code easy for any team member to understand and modify. I ensure that your style guide is a living document that improves the quality of every commit.
11
12## When to use me
13
14- When you're setting up a new project and defining its coding standards.
15- When you're configuring linters or formatting tools.
16- When you're reviewing code for naming and formatting consistency.
17- When you're writing documentation or comments.
18
19## Core principles
20
211. **Automate enforcement**, use tools like linters and formatters to catch style issues automatically.
222. **Naming clarity**, choose descriptive names for variables, functions, and files that reveal their purpose.
233. **Consistent formatting**, ensure that all code looks like it was written by a single person.
244. **Purposeful comments**, write comments that explain the "why" rather than the "what".
25
26## Patterns & examples
27
28### Linter configuration
29Use industry-standard tools for automated checks.
30- **Go**, Use `golangci-lint` with a comprehensive `.golangci.yml` configuration.
31- **JavaScript**, Use `ESLint` with a shared config like Airbnb or Standard.
32
33### Naming conventions
34Follow language-specific idioms.
35- **Go**, Use camelCase for internal symbols and PascalCase for exported symbols. Keep names concise.
36- **JavaScript**, Use camelCase for variables and functions, PascalCase for classes and components.
37
38### Comment style
39Use standard formats for automated documentation.
40- **Go**, Use `godoc` style comments for exported functions.
41- **JavaScript**, Use `JSDoc` for providing type and purpose information in untyped files.
42
43### Import ordering
44Organise imports to reduce noise.
45- **Pattern**, Group standard library imports, then third-party libraries, then internal modules. Separate groups with a blank line.
46
47## Anti-patterns to avoid
48
49- ❌ **Style disagreements over logic**, spending too much time arguing about trivial style details instead of meaningful code improvements.
50- ❌ **Inconsistent names**, using multiple naming patterns for the same concept across the project.
51- ❌ **Useless comments**, comments that just restate what the code is doing without providing context.
52- ❌ **Ignoring linter warnings**, allowing linter errors to accumulate until they are ignored by everyone.
53
54## KB Reference
55
56`~/vaults/baphled/3. Resources/Knowledge Base/AI Development System/Skills/Code-Quality/Style Guide.md`
57
58## Related skills
59
60- `clean-code`, for broader coding best practices.
61- `static-analysis`, for automated quality checks.
62- `documentation-writing`, for better comments and guides.
63- `writing-style`, for a consistent tone in docs.