원클릭으로
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 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate documentation for code — use when asked to document a module, generate API docs, create a README for code, or write reference documentation. Triggers the deterministic doc-gen workflow (analyze → generate via documenter agent → write).
Check devkit health — which external CLIs (codex, gemini, gh, rtk, sg, gcli) are installed, which agents are available, which skills are ready to use. Use when asked about devkit health, devkit status, "is devkit working?", "what's installed?", "what devkit capabilities do I have?", diagnosing devkit setup issues, or running /devkit:health. Read-only diagnostic, safe to auto-invoke.
Fan-out PR review that runs BOTH `/devkit:tri-review` AND `/pr-review-toolkit:review-pr` in parallel for maximum coverage, then presents unified results — this skill does not compete with its sub-skills, it delegates to both simultaneously. Use when the user asks for "mega PR review", "mega-pr", "mega review", "full PR review with everything", "both review tools", "maximum coverage review", or explicitly wants every available reviewer looking at a change at once (Claude + Codex + Gemini model diversity PLUS specialized aspect reviewers like silent-failure-hunter, type-design-analyzer, test-analyzer, code-reviewer). Worth the extra cost when: the PR is high-stakes and the user wants every angle covered, or before merging a critical or hard-to-revert change. Do NOT use when the user only wants one review system (use tri-review or pr-review-toolkit:review-pr directly). Do NOT use for routine code review where a single reviewer suffices. This is deliberate overkill for when you want absolutely everything.
Generate a codebase onboarding guide — use when asked to explain this codebase, help understand the architecture, give a tour of the repo, or onboard a new contributor. Triggers the deterministic onboard workflow (analyze structure → architect via researcher agent → write guide).
Full end-to-end PR pipeline — validate → necessity-check → lint (loop) → test (loop) → security scan → doc-check → changelog → create-pr → monitor reviews (loop). Takes a branch from "code done" to "merged" with every gate enforced. Use when the user asks to "submit a PR", "open a pull request", "ship this", "make this PR-ready", "finalize this branch", or wants the full pipeline run end-to-end with CI monitoring and reviewer-comment handling automated. Worth the ceremony when: lint and test gates must pass before the PR opens, docs need syncing alongside code (README, ROADMAP, SKILL.md, workflows), security scan is required, or the user wants reviewer comments automatically classified and responded to. Do NOT use for a quick commit+push+PR without gates — use `/commit-commands:commit-push-pr` for that lighter path. Do NOT use when already mid-PR and just handling existing review comments in isolation. Do NOT use on the main branch or with uncommitted changes — the validate step will block you. This is devkit
| 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.