coding-standard

Name: coding-standard
Author: testdouble

122stars12forks

How to install coding-standard?

testdouble/han/coding-standard

$npx -y skills add testdouble/han --skill coding-standard

Installs into the current project.

Summary

Creates and updates coding standards, conventions, rules, and guidelines for the current project. Use when creating new standards from scratch, converting existing documents into coding standards, or updating existing standards. Does not create architectural decision records — us

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- AGENTS.md: !`find . -maxdepth 1 -name "AGENTS.md" -type f`
5	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
6	- Rules directory: !`find . -maxdepth 4 -type d -path "*/.claude/rules/coding-standards"`
7
8	## Step 1: Determine Mode
9
10	Determine which mode to operate in based on the user's request:
11
12	\| Mode \| When \| Initial Status \| Then \|
13	\|------\|------\|----------------\|------\|
14	\| Creating new \| Building a coding standard from scratch \| `proposed` \| → Step 2 \|
15	\| Converting existing \| User provides an existing document (ADR, etc.) to convert \| `accepted` \| → Step 2 \|
16	\| Updating existing \| Modifying an existing coding standard \| — \| Read the existing coding standard, → Step 3 \|
17
18	## Step 2: Evaluate Appropriateness
19
20	Coding standard documents are not a replacement for automated tooling. Before proceeding, evaluate whether the proposed coding standard falls into one of these categories:
21
22	- Conventions that should be enforced by linters or formatters (variable naming, indentation, whitespace, import ordering, bracket placement, line length, semicolons)
23	- Common language conventions that are well-known or easily discoverable from the language's own documentation and community norms (type declaration style, etc.)
24
25	If the proposed coding standard falls into one of these categories:
26
27	1. Warn the user that this is typically handled by automated tooling or is a well-known language convention, and that documenting it adds maintenance burden without value. Recommend configuring tooling instead.
28	2. Ask the user whether they still want to proceed
29	3. If the user declines, stop — the skill is done
30
31	If the proposed coding standard does not fall into these categories, proceed to the YAGNI check below.
32
33	### YAGNI check
34
35	Apply the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md) alongside the companion evidence rule in [../../references/evidence-rule.md](../../references/evidence-rule.md). A coding standard is worth writing only when the project actually does the thing the standard governs today and the standard solves a real, concrete problem the team is currently hitting. Standards about patterns the project doesn't use yet, "for future flexibility", "best practice says we should…", or symmetry with other standards ("we have one for backend, so we should have one for frontend" when the frontend codebase is a single file) are YAGNI candidates. Acceptable evidence the standard is needed now:
36
37	- The pattern the standard governs is actively used in the codebase today (cite at least three examples), and inconsistency between examples is causing real friction (review churn, bugs, onboarding cost).
38	- A documented incident or recurring code-review finding the standard would prevent.
39	- A regulatory or compliance rule the project actually falls under that requires the convention.
40	- A user-described need ("I keep having to remind people about X").
41
42	If no accepted evidence applies, recommend deferring the standard with the trigger that would justify writing it (a third instance of the pattern lands, a real incident occurs, a recurring review finding accumulates). Surface the recommendation to the user with the override option.
43
44	## Step 3: Discover Project Structure
45
46	1. Retrieve project config: Resolve project config: read CLAUDE.md's `## Project Discovery` section for docs and coding-standards directories; fall back to project-discovery.md; fall back to Glob defaults (`docs/`, `docs/coding-standards/`). Continue without any keys that remain unfound.
47
48	2. Determine the coding standards directory:
49	- If a coding standards directory was found, use it
50	- If only a docs directory was found, create `{docs-dir}/coding-standards/`
51	- If neither was found, create `docs/coding-standards/`
52
53	3. Enumerate existing coding standards: If a coding standards directory was found, use Glob to enumerate existing `.md` files in that directory.
54
55	4. Check existing coding standard format: If existing coding standards were found via Glob, read one to understand the project's existing format. If it uses a different format than the template at [template.md](./references/templ

People who liked this also viewed

6 picks

Type

coding-standard

122stars12forks

View on GitHub

How to install coding-standard?

testdouble/han/coding-standard

$npx -y skills add testdouble/han --skill coding-standard

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Project Context
2
3	- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
4	- AGENTS.md: !`find . -maxdepth 1 -name "AGENTS.md" -type f`
5	- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
6	- Rules directory: !`find . -maxdepth 4 -type d -path "*/.claude/rules/coding-standards"`
7
8	## Step 1: Determine Mode
9
10	Determine which mode to operate in based on the user's request:
11
12	\| Mode \| When \| Initial Status \| Then \|
13	\|------\|------\|----------------\|------\|
14	\| Creating new \| Building a coding standard from scratch \| `proposed` \| → Step 2 \|
15	\| Converting existing \| User provides an existing document (ADR, etc.) to convert \| `accepted` \| → Step 2 \|
16	\| Updating existing \| Modifying an existing coding standard \| — \| Read the existing coding standard, → Step 3 \|
17
18	## Step 2: Evaluate Appropriateness
19
20	Coding standard documents are not a replacement for automated tooling. Before proceeding, evaluate whether the proposed coding standard falls into one of these categories:
21
22	- Conventions that should be enforced by linters or formatters (variable naming, indentation, whitespace, import ordering, bracket placement, line length, semicolons)
23	- Common language conventions that are well-known or easily discoverable from the language's own documentation and community norms (type declaration style, etc.)
24
25	If the proposed coding standard falls into one of these categories:
26
27	1. Warn the user that this is typically handled by automated tooling or is a well-known language convention, and that documenting it adds maintenance burden without value. Recommend configuring tooling instead.
28	2. Ask the user whether they still want to proceed
29	3. If the user declines, stop — the skill is done
30
31	If the proposed coding standard does not fall into these categories, proceed to the YAGNI check below.
32
33	### YAGNI check
34
35	Apply the evidence-based YAGNI rule from [../../references/yagni-rule.md](../../references/yagni-rule.md) alongside the companion evidence rule in [../../references/evidence-rule.md](../../references/evidence-rule.md). A coding standard is worth writing only when the project actually does the thing the standard governs today and the standard solves a real, concrete problem the team is currently hitting. Standards about patterns the project doesn't use yet, "for future flexibility", "best practice says we should…", or symmetry with other standards ("we have one for backend, so we should have one for frontend" when the frontend codebase is a single file) are YAGNI candidates. Acceptable evidence the standard is needed now:
36
37	- The pattern the standard governs is actively used in the codebase today (cite at least three examples), and inconsistency between examples is causing real friction (review churn, bugs, onboarding cost).
38	- A documented incident or recurring code-review finding the standard would prevent.
39	- A regulatory or compliance rule the project actually falls under that requires the convention.
40	- A user-described need ("I keep having to remind people about X").
41
42	If no accepted evidence applies, recommend deferring the standard with the trigger that would justify writing it (a third instance of the pattern lands, a real incident occurs, a recurring review finding accumulates). Surface the recommendation to the user with the override option.
43
44	## Step 3: Discover Project Structure
45
46	1. Retrieve project config: Resolve project config: read CLAUDE.md's `## Project Discovery` section for docs and coding-standards directories; fall back to project-discovery.md; fall back to Glob defaults (`docs/`, `docs/coding-standards/`). Continue without any keys that remain unfound.
47
48	2. Determine the coding standards directory:
49	- If a coding standards directory was found, use it
50	- If only a docs directory was found, create `{docs-dir}/coding-standards/`
51	- If neither was found, create `docs/coding-standards/`
52
53	3. Enumerate existing coding standards: If a coding standards directory was found, use Glob to enumerate existing `.md` files in that directory.
54
55	4. Check existing coding standard format: If existing coding standards were found via Glob, read one to understand the project's existing format. If it uses a different format than the template at [template.md](./references/templ

People who liked this also viewed

6 picks

Type