원클릭으로
clean-code
Clean code principles — meaningful names, small functions, single responsibility, stepdown rule, flat nesting.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Clean code principles — meaningful names, small functions, single responsibility, stepdown rule, flat nesting.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Recognizing context pressure before it degrades output quality.
Writing implementation plans — small testable steps, dependency ordering, upfront risk identification.
Evidence before claims, always — run verification commands and confirm output before making any completion or success claims.
Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate a structured changelog from git history — use when asked to create a changelog, release notes, or summarize what changed between versions/tags/branches.
How to write pikit workflow YAML files — steps, loops, branches, interpolation.
SOC 직업 분류 기준
| name | clean-code |
| description | Clean code principles — meaningful names, small functions, single responsibility, stepdown rule, flat nesting. |
getUserById not getData. isExpired not check.url, id, config).isReady, hasPermission, shouldRetry.calculateTotal, validateInput, sendNotification.A function should do one thing. If you're describing what a function does and use the word "and," it does too much.
Aim for 5-15 lines. Not a hard rule, but long functions almost always contain extractable sub-functions.
Every module/class/function should have one reason to change. If a module handles both parsing and validation, a change to parsing rules forces you to touch validation code (and vice versa).
Ask: "If requirement X changes, how many files do I touch?" If the answer is many, responsibilities are entangled.
Organize code so readers encounter high-level logic first, details later. A file should read like a newspaper article — headline, summary, then details.
// Good: high-level flow is immediately clear
function processOrder(order) {
validate(order);
const total = calculateTotal(order.items);
return submitPayment(order.customer, total);
}
// Supporting functions follow below
function validate(order) { /* ... */ }
function calculateTotal(items) { /* ... */ }
function submitPayment(customer, total) { /* ... */ }
Public/exported functions at the top. Private/helper functions below.
Deeply nested code is hard to follow. Prefer early returns, guard clauses, and extraction.
// Bad: nested
function process(input) {
if (input) {
if (input.isValid) {
if (!input.isProcessed) {
return doWork(input);
}
}
}
return null;
}
// Good: flat
function process(input) {
if (!input) return null;
if (!input.isValid) return null;
if (input.isProcessed) return null;
return doWork(input);
}
If you're indented more than 2 levels, look for an extraction or early return.