---
name: coding-comment-discipline
description: Use for CCC coding or refactor work when agents edit source code and must keep comments concise, operator-language aligned, historically traceable, and modular.
metadata:
short-description: Coding comment and modularity discipline
---
# Coding Comment Discipline
Use this skill for CCC code-specialist work that creates, edits, repairs, or
refactors source code.
## Contract
- Write new or changed comments in the user's language. If the request mixes
languages or the source already has an English comment/log convention, use
the operator-facing response language and keep the source context consistent
unless the operator explicitly asks for another language.
- Keep comments short and easy to understand. Prefer one clear sentence over a
paragraph; avoid restating obvious code.
- Maintain a cumulative top-of-file work log in code files you materially edit:
who, when, and what changed. Use the file's comment syntax around this
logical block, preserve existing log entries, and add one concise entry for
this task.
- Use the operator's top-of-file log block format exactly:
- the log block starts and ends with a separator line of 44 `=` characters;
- each entry uses the fields `date`, `Modifier`, and `task`;
- `Modifier` uses `git config user.name`/GitHub name when available,
otherwise the agent name;
- keep the `task` text short, in the user's/operator's language, and easy to
understand;
- example:
```text
============================================
date : YYYY-MM-DD, Modifier : HoRi0506, task : 짧은 한국어 작업 설명
date : YYYY-MM-DD, Modifier : HoRi0506, task : 다음 누적 작업 설명
============================================
```
- Do not add bulky logs to generated, vendored, lock, minified, or binary-like
files; report the exception in fan-in when a required log is not appropriate.
- Keep files maintainable. Split helpers or modules when a file, function, or
responsibility grows hard to scan, but avoid broad rewrites when a local
extraction or focused helper is enough.
- Keep validation close to the change: update focused tests for comment-policy,
work-log, or modularization behavior when those are part of acceptance.