ワンクリックで
code-style
Use when writing or modifying any code. Enforces naming conventions, function design, and code clarity principles.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when writing or modifying any code. Enforces naming conventions, function design, and code clarity principles.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Launch recipe for the daily-writing-friends web app (apps/web — Vite + React + React Router, dev server on http://localhost:5173). Use to build and run the app locally so /run and /verify can drive the real UI. Captures the mandatory nvm node-22 PATH prefix (the default Homebrew node is broken), the dev-server command and port, backend selection (cloud vs local Supabase), and the static gate commands (type-check, tests).
Use after UI/frontend changes — layout, responsive behavior, navigation/routing, or any user-facing flow — to prove it actually works by driving a real headless browser (Playwright) against the running dev server. Asserts behavior (clicks, URL changes, visible text), measures layout (alignment via bounding boxes, overflow via scrollWidth minus clientWidth), captures console/page errors, and saves screenshots. Reach for this whenever "it type-checks and the unit tests pass" does not prove the feature renders and behaves correctly in a browser. Complements verify-runtime (which checks data-flow via dev logs).
Use when writing or modifying page-level layout markup in apps/web — max-width containers, flex rows, vertical spacing — or composing multiple sections on a page. Enforces shared/ui layout primitives (ReadingColumn, Stack, Row) and compound-component slots over scattered Tailwind classes.
Use when the user wants to improve daily-writing-friends production Web Vital scores (LCP/FCP/CLS) by running additional iterations of the local perf harness to drive the overall F2 score higher. Triggers - "web vital 개선", "LCP 줄여", "F2 점수 올려", "harness 한 번 더 돌려", "perf 개선 작업", "perf iteration", "drive score up".
Fetch and compare per-route p75 Web Vitals (LCP/FCP/CLS) from Sentry Discover for the daily-writing-friends production project, with an F2-weighted score and pre/post-deploy diff. Use when the user wants to verify whether performance improved or regressed after a deploy, compare pre/post-merge windows for a PR, identify the worst-performing routes for the next perf push, or sanity-check a Web Vitals claim. Triggers - "web vital 확인해줘", "p75 비교", "회귀 있나", "perf 점수", "이 PR 머지 후 LCP 어떻게 됐어", "sentry에서 가져와".
Use when writing tests for React components or custom hooks that touch the React Query cache, MSW-mocked Supabase, or React Router data-router loaders. Triggers - writing component tests, writing hook tests that need a provider tree, creating MSW handlers, render() + screen assertions, data-fetching component tests, form integration tests, loader/errorElement tests, optimistic-mutation tests. Does NOT cover pure-function unit tests (use the testing skill) or cross-page journeys (use Playwright E2E).
| name | code-style |
| description | Use when writing or modifying any code. Enforces naming conventions, function design, and code clarity principles. |
Code should be self-explanatory. Comments explain WHY, not WHAT.
Each function should do one thing well. Split larger functions into smaller, independent methods.
A function should either:
Never mix abstraction levels in one function body. This is the Single Level of Abstraction (SLA) principle.
// BAD - mixed abstraction levels
function processOrder(order: Order) {
validateOrder(order); // high-level call
const tax = order.total * 0.1; // low-level calculation
await sendConfirmation(order); // high-level call
db.insert('orders', { ...order, tax }); // low-level operation
}
// GOOD - consistent abstraction
function processOrder(order: Order) {
validateOrder(order);
const enrichedOrder = calculateTaxes(order);
await persistOrder(enrichedOrder);
await sendConfirmation(enrichedOrder);
}
Prefer guard clauses or polymorphism over if-else blocks.
// BAD
function getDiscount(user: User) {
if (user.isPremium) {
return 0.2;
} else {
return 0;
}
}
// GOOD - guard clause
function getDiscount(user: User) {
if (!user.isPremium) return 0;
return 0.2;
}
Flag arguments indicate a function is doing more than one thing.
// BAD
function createUser(data: UserData, sendEmail: boolean) { ... }
// GOOD
function createUser(data: UserData) { ... }
function createUserAndNotify(data: UserData) { ... }
// BAD
const d = 7; // days in recovery period
// GOOD
const daysInRecoveryPeriod = 7;
// BAD
getUserCmt(), calcRecReq()
// GOOD
getUserComment(), calculateRecoveryRequirement()
// BAD
eligible, recovery
// GOOD
isEligible, isRecovering, hasPassedDeadline
// BAD
const post = getPosts();
// GOOD
const posts = getPosts();
const hasRequiredPostCount = posts.length >= 2;
const isWithinRecoveryWindow = new Date() <= recoveryDeadline;
const canStartRecovery = hasRequiredPostCount && isWithinRecoveryWindow;
// BAD
if (streak >= 21) { ... }
// GOOD
const GOLD_BADGE_STREAK_THRESHOLD = 21;
if (streak >= GOLD_BADGE_STREAK_THRESHOLD) { ... }
TODO: for known limitations