with one click
comments
// Section-divider comment style with 80-column ruler and mandatory numbered dividers above every function, class, and method declaration.
// Section-divider comment style with 80-column ruler and mandatory numbered dividers above every function, class, and method declaration.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | comments |
| description | Default numbered one-line `―` dividers; paired outer blocks only for very long code sections. |
― divider comments for declarations and logical sections.Use the file's local single-line comment prefix such as // or #.
The full rendered divider line must be exactly 100 characters, including indentation, comment prefix, number, title, one space before the ruler, and repeated ―.
If a title would leave no room for at least three ― characters within 100 characters, shorten the title without changing its meaning.
Default top-level divider:
// 1. Normalize input ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
// ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
// title
// ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
―, not -.1. and child numbers such as 1-1..1-10..Place the comment immediately above the declaration or logical block it describes.
Always keep exactly one empty line immediately above a one-line divider or paired block opening ruler when it follows code or other content.
Do not leave two or more empty lines above a divider.
Do not insert an empty line inside a paired three-line divider block.
When a paired divider block sits directly above code, code starts on the next line.
When a one-line divider sits directly above code, code starts on the next line.
When a top-level divider introduces child comments, one empty line after the divider is allowed.
Comments should explain block purpose, business meaning, boundary conditions, preservation intent, grouping intent, editability rules, or non-obvious constraints. Do not narrate obvious syntax.
If one short internal explanation is truly needed inside a block, use a plain single-line comment. This is secondary; section dividers remain primary.
When writing Korean comments:
prefer concise noun-like or clipped statement-like endings
prefer short, compact wording over full prose sentences
avoid verbose sentence-final phrasing unless the file already strongly uses that tone
Add a comment only when at least one is true:
the user explicitly asked for comments
it is a function, class, or method declaration
a function or block has multiple logical phases
the surrounding file already uses section comments
the business meaning is not obvious from code alone
a boundary or exclusion rule should be visible
Skip comments for tiny obvious code that is not a declaration.